How to disable ssh from RED

[pmueller (Peter Müller)]

Hi,

@sxfire01

Whatever i try, the ssh Connection from extern is always reachable if the sshd is running.!

are you testing this from behind your IPFire installation?

Either way, this suspiciously reminds me of that topic:

Unwanted WebGUI access via Internet

For some obscure reason I could access the WebGUI managment console via the internet, even though the ports were not opened to the WAN side, and only set for internal abuse. Ports 81, and 1013 had no entries in the firewall settings either, which means they should be ignored or dropped. Out of the 15 odd boxes I have running, only 3 suffered from this issue, 2 of which were fresh installs with core141 ISO from two months ago, and one of these is a VM. Not all boxes are on the same cores, so I h…

In case there is a scenario where IPFire exposes it’s SSH port to RED by accident, we have got to nail down it and fix the underlying problem. Otherwise, it would be interesting to see the full configuration of your IPFire machine. Please post as much as information as you can.

Thanks, and best regards,
Peter Müller

[sxfire01 (Helmut Pfeiffer)]

Hello Adolf Belka,

In the Firewallsection there are about 220 Rules but no one for Port 222 from RED or *.

Hello Data Morgana,

This would work, but i dont want to make too much extra configs.
And this shouldnt work out of the box.

Hello Peter Müller,

What do you mean with “Behind your IPFire installation”?
I have tested from the Internet (RED-Interface). Sure.
==> That should not work !!

I think there is no special Scenario.
What do you need to see the full configuration.

Thanks

[datamorgana]

Hi Helmut, my workaround would certainly also not be an appropriate solution in the light of a suspected security issue with the IPFire configuration, which is yet to be verified.

[krasnal]

I would suggest you see what Steve Gibson’s ShieldsUp! says about port 222 on your firewall. That is assuming you’re using port 222, of course. I checked mine and it’s “stealth” which is apparently Gibson-speak for blocking unsolicited incoming traffic.

hxxps://www.grc.com/x/portprobe=222

[sxfire01 (Helmut Pfeiffer)]

Hello Data Morgana,

Ok i will fix it on this way for now.
But i want to know why this is working.

Hello krasnal .

1. I can connect to the Firewall from anywhere in the Internet via ssh (Port 222).
2. A Penetrationtest have found the Port.
   => Why i should test it once more? I dont wish the Port is reachable from Internet !!

[pmueller (Peter Müller)]

Hi,

@sxfire01

I can connect to the Firewall from anywhere in the Internet via ssh (Port 222).

this should not happen indeed.

Could you please post the output of the following commands (or DM them to me in case you do not want to make them public):

• iptables -L -n -v -t nat
• iptables -L -n -v -t raw
• route
• ifconfig
• netstat -tulpen

Cc: @troll-op

Thanks, and best regards,
Peter Müller

[pike_it (Pike)]

@pmueller

this should not happen indeed.

Unless a specific rule is written…

[pmueller (Peter Müller)]

Hi,

well, according to OP, there is none - at least none written with that intention in mind.

This is why I am asking for raw information…

Thanks, and best regards,
Peter Müller

[troll-op (Andreas Otto)]

@pmueller … promise it was not me this time… I’ve been good.

sxfire if you don’t have entries in the firewall rules section, did you by any chance create any manuel entries in /etc/sysconfig/rc.local or /etc/sysconfig/firewall.local?

If you created any entries that accept, for example from a country region, it will permit all kinds of things not defined in any iptables for that region. WebGUI becomes accesible, SSH opens up, etc. You get the picture.

Wish you all a lekker evening

[anon87475738]

I checked the log summary and to my surprise found the following:

Remote user logins:

 Negotiation failed:
    no matching key exchange method found
       141.98.10.202: 1 Time
       209.141.58.169: 1 Time
       62.233.50.53: 2 Times
       92.255.85.28: 1 Time

 **Unmatched Entries**
 error: kex_exchange_identification: Connection closed by remote host : 7 Times
 error: kex_exchange_identification: banner line contains invalid characters : 1 Time

After this finding I have used this test: heise Security

The test then showed me a problem (marked red) with SSH and DNS.

I also saw under “Status” “Services” that IPS was no longer running.

After a restart everything is OK again. Also with the above test.
How can this be?

SSH Access was turned on (I had forgotten to turn it off). Now when I have SSH Access on, everything is OK too…, strange…

[anon87475738]

Again!

[bonnietwin (Adolf Belka)]

Presuming that you don’t have any firewall rules opening port 22 up to the red zone and that there are no rules doing something similar in /etc/sysconfig/firewall.local then I would suggest following the input from @pmueller in post 9 in this thread.
https://community.ipfire.org/t/how-to-disable-ssh-from-red/4030/9

[anon87475738]

This is very strange. I don’t have any corresponding firewall rules active. I have now run the network check from heise several times throughout the day. Everything OK. Then I just ran the test again and then again:

Port 22 is probably just not there because I have SSH off. I am sure that port 22 shows up as open when I turn SSH on.

Now I have rebooted IPFire and the test shows everything OK again.

How can this be?

Can you please check that too? Maybe others are affected too and just haven’t noticed?

Netzwerkcheck

[bonnietwin (Adolf Belka)]

Okay I just ran the Heise check and the only result I got was for ports 80 and 443 which is correct because I have a web server there and I have port forward firewall rules to get there.

My ssh was running and port 22 did not show up in the test, also not port 53 for DNS.

My IPFire has been running for 12 days since the last time that I rebooted it.

[anon87475738]

Thanks. Any idea?

[bonnietwin (Adolf Belka)]

I am afraid I don’t have any further ideas at the moment.

[anon87475738]

Maybe reinstall IPFire completely?
Currently everything OK. But tomorrow will certainly come the surprise again.

[anon87475738]

Yesterday around 11 pm I noticed again that port 53 is open. I had SSH off. Otherwise, port 22 would probably also have been open. I also noticed that IPS was disabled again.
I had rebooted IPFire an hour or two before.
After reboot everything was normal again.

How can this be?

Is there a problem with IPFire under certain circumstances and no one but me has noticed it yet?

    iptables -L -n -v -t nat
    iptables -L -n -v -t raw
    route
    ifconfig
    netstat -tulpen

iptables -L -n -v -t nat:

Chain PREROUTING (policy ACCEPT 57184 packets, 3785K bytes)
pkts bytes target prot opt in out source destination
59611 3991K CUSTOMPREROUTING all – * * 0.0.0.0/0 0.0.0.0/0
59611 3991K CAPTIVE_PORTAL all – * * 0.0.0.0/0 0.0.0.0/0
59611 3991K SQUID all – * * 0.0.0.0/0 0.0.0.0/0
59590 3990K NAT_DESTINATION all – * * 0.0.0.0/0 0.0.0.0/0

Chain INPUT (policy ACCEPT 5476 packets, 419K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 4731 packets, 295K bytes)
pkts bytes target prot opt in out source destination
5480 340K NAT_DESTINATION all – * * 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 1072 packets, 71003 bytes)
pkts bytes target prot opt in out source destination
47887 3129K CUSTOMPOSTROUTING all – * * 0.0.0.0/0 0.0.0.0/0
47887 3129K OVPNNAT all – * * 0.0.0.0/0 0.0.0.0/0
47887 3129K IPSECNAT all – * * 0.0.0.0/0 0.0.0.0/0
47887 3129K NAT_SOURCE all – * * 0.0.0.0/0 0.0.0.0/0
47887 3129K NAT_DESTINATION_FIX all – * * 0.0.0.0/0 0.0.0.0/0
47887 3129K REDNAT all – * * 0.0.0.0/0 0.0.0.0/0

Chain CAPTIVE_PORTAL (1 references)
pkts bytes target prot opt in out source destination

Chain CUSTOMPOSTROUTING (1 references)
pkts bytes target prot opt in out source destination

Chain CUSTOMPREROUTING (1 references)
pkts bytes target prot opt in out source destination

Chain IPSECNAT (1 references)
pkts bytes target prot opt in out source destination

Chain NAT_DESTINATION (2 references)
pkts bytes target prot opt in out source destination
0 0 LOG tcp – * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:53 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "DNAT "
0 0 REDIRECT tcp – * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:53
2009 169K LOG udp – * * 192.168.1.0/24 0.0.0.0/0 udp dpt:53 limit: avg 10/sec burst 20 LOG flags 0 level 4 prefix "DNAT "
2009 169K REDIRECT udp – * * 192.168.1.0/24 0.0.0.0/0 udp dpt:53

Chain NAT_DESTINATION_FIX (1 references)
pkts bytes target prot opt in out source destination
0 0 SNAT all – * * 0.0.0.0/0 0.0.0.0/0 mark match 0x1000000/0xf000000 to:192.168.1.1
0 0 SNAT all – * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2000000/0xf000000 to:192.168.2.1
0 0 SNAT all – * * 0.0.0.0/0 0.0.0.0/0 mark match 0x4000000/0xf000000 to:192.168.50.1

Chain NAT_SOURCE (1 references)
pkts bytes target prot opt in out source destination

Chain OVPNNAT (1 references)
pkts bytes target prot opt in out source destination

Chain REDNAT (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all – * red0 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec
46137 3017K MASQUERADE all – * red0 0.0.0.0/0 0.0.0.0/0

Chain SQUID (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp – green0 * 0.0.0.0/0 yy.yy.yy.yy tcp dpt:80
21 1344 REDIRECT tcp – green0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3128
0 0 RETURN tcp – blue0 * 0.0.0.0/0 yy.yy.yy.yy tcp dpt:80
0 0 REDIRECT tcp – blue0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3128

iptables -L -n -v -t raw

Chain PREROUTING (policy ACCEPT 4265K packets, 5969M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1039K packets, 4583M bytes)
pkts bytes target prot opt in out source destination

route

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 1002 0 0 red0
YY.YY.YY.0 0.0.0.0 255.255.255.0 U 1002 0 0 red0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 blue0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 orange0

ifconfig

blue0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.2.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:e0:67:2a:7a:7e txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0x91200000-9121ffff

green0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:e0:67:2a:7a:7d txqueuelen 1000 (Ethernet)
RX packets 2153282 bytes 183168783 (174.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4195981 bytes 5826863231 (5.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0x91100000-9111ffff

imq0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500
ether 56:f4:ff:97:a6:b6 txqueuelen 32 (Ethernet)
RX packets 13250572 bytes 6512138154 (6.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13250572 bytes 6512138154 (6.0 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 46671 bytes 11990116 (11.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 46671 bytes 11990116 (11.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

orange0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.50.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether 00:e0:67:2a:7a:7f txqueuelen 1000 (Ethernet)
RX packets 278954 bytes 51278893 (48.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 312828 bytes 198013770 (188.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0x91300000-9131ffff

red0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet yy.yy.yy.yy netmask 255.255.255.0 broadcast YY.YY.YY.255
ether 00:e0:67:2a:7a:7c txqueuelen 1000 (Ethernet)
RX packets 15943212 bytes 6689500457 (6.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1084823 bytes 136145966 (129.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0x91000000-9101ffff

netstat -tulpen

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 192.168.2.1:3128 0.0.0.0:* LISTEN 0 23793 3942/(squid-1)
tcp 0 0 127.0.0.1:800 0.0.0.0:* LISTEN 0 23794 3942/(squid-1)
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 0 19821 2128/unbound
tcp 0 0 192.168.1.1:3128 0.0.0.0:* LISTEN 0 23791 3942/(squid-1)
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 0 19819 2128/unbound
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 124906 3078/sshd: /usr/sbi
tcp 0 0 192.168.1.1:800 0.0.0.0:* LISTEN 0 23790 3942/(squid-1)
tcp 0 0 192.168.2.1:800 0.0.0.0:* LISTEN 0 23792 3942/(squid-1)
tcp6 0 0 :::81 :::* LISTEN 0 23962 4323/httpd
tcp6 0 0 :::444 :::* LISTEN 0 23966 4323/httpd
tcp6 0 0 :::1013 :::* LISTEN 0 23970 4323/httpd
udp 0 0 0.0.0.0:44527 0.0.0.0:* 23 23778 3942/(squid-1)
udp 0 0 0.0.0.0:53 0.0.0.0:* 0 19818 2128/unbound
udp 0 0 0.0.0.0:67 0.0.0.0:* 0 23505 4291/dhcpd
udp 0 0 yy.yy.yy.yy:68 0.0.0.0:* 0 24800 4031/dhcpcd: [netwo
udp 0 0 192.168.50.1:123 0.0.0.0:* 0 23476 4209/ntpd
udp 0 0 192.168.1.1:123 0.0.0.0:* 0 23474 4209/ntpd
udp 0 0 yy.yy.yy.yy:123 0.0.0.0:* 0 23472 4209/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 23470 4209/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 23465 4209/ntpd
udp 0 0 0.0.0.0:514 0.0.0.0:* 0 17951 2088/syslogd
udp6 0 0 :::123 :::* 0 23462 4209/ntpd

[anon87475738]

Port 53 (DNS) was open again. IPS was also switched off.
What is going on?

I’m afraid I have to use another firewall distribution (even though I like IPFire). Maybe I’ll also reinstall IPFire first.

[anon42188109]

I ran the Heise Security test and it checked my public ip. It reported back “Gratulation, der Test hat keine Probleme gefunden,” which means no problems found. My firewall is core 162, x86_64, ssh is open for 17 days now. I suggest you reinstall ipfire.