Hi,
On 13 Dec 2019, at 18:36, Peter Müller peter.mueller@ipfire.org wrote:
Hello *,
thanks to very close IPS log monitoring, I stumbled across some packets from RFC 1918 addresses to the public IPv4 address on the ppp0 interface (ADSL connection) of an IPFire machine:
12/09/2019-11:38:23.050370 [Drop] [**] [1:2010935:3] ET SCAN Suspicious inbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.66.1.11:49902 -> 85.XXX.XXX.XXX:1433 12/12/2019-09:30:46.800360 [Drop] [**] [1:2010935:3] ET SCAN Suspicious inbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.145.52:53061 -> 85.XXX.XXX.XXX:1433
This is *very* interesting to see on a DSL connection.
Digging more deeply into the packet filter logs, this seems to happen quite frequently (I guess those both packets above were not logged because the IPS already dropped them; otherwise it would be really alarming):
Dec 8 21:49:14 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.170 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=18456 PROTO=TCP SPT=54261 DPT=5555 WINDOW=60621 RES=0x00 SYN URGP=0 Dec 9 11:01:29 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=10.0.0.8 DST=85.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=29997 PROTO=TCP SPT=30279 DPT=23 WINDOW=6695 RES=0x00 SYN URGP=0 Dec 9 20:52:38 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=10.10.204.161 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=25793 DF PROTO=TCP SPT=2146 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 9 21:22:07 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.120 DST=85.XXX.XXX.XXX LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=60440 PROTO=TCP SPT=48033 DPT=23 WINDOW=57033 RES=0x00 SYN URGP=0 Dec 11 14:29:09 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=30575 DF PROTO=TCP SPT=59055 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:12 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=15843 DF PROTO=TCP SPT=59055 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:13 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=29263 DF PROTO=TCP SPT=58991 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=17475 DF PROTO=TCP SPT=58991 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=17600 DF PROTO=TCP SPT=59050 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:20 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=115 ID=11551 DF PROTO=TCP SPT=59050 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 23:51:27 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=172.16.42.211 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=10682 PROTO=TCP SPT=20479 DPT=80 WINDOW=28891 RES=0x00 SYN URGP=0 Dec 12 16:00:57 fw-01 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=172.21.75.234 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=36323 PROTO=TCP SPT=57273 DPT=9527 WINDOW=39680 RES=0x00 SYN URGP=0
Those will always be dropped. However they are creating a lot of noise.
I initially blamed the (rather small German) ISP of that machine for not dropping bogon traffic at their edge routers. However, the same - hostile? - traffic can also be observed at different locations behind different ISPs (using VDSL here):
Dec 9 23:37:18 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.170 DST=85.XXX.XXX.XXX LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=45421 PROTO=TCP SPT=54261 DPT=5555 WINDOW=60621 RES=0x00 SYN URGP=0 Dec 10 09:44:52 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.100.159 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=2893 DF PROTO=TCP SPT=50188 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:08 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=23895 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:11 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=7772 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:12 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=15452 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=8231 DF PROTO=TCP SPT=52374 DPT=8291 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=8764 DF PROTO=TCP SPT=52374 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:18 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=29653 DF PROTO=TCP SPT=52374 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 11 14:29:21 fw-02 kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=192.168.1.76 DST=85.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=23036 DF PROTO=TCP SPT=52374 DPT=8728 WINDOW=8192 RES=0x00 SYN URGP=0
I am used to see this on cable connections. They use Ethernet and separating clients is slightly more tricky.
Dec 2 21:09:01 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.79.38.29 DST=87.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=3529 DF PROTO=TCP SPT=63955 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 3 09:19:53 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=192.168.254.129 DST=83.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=119 ID=31437 DF PROTO=TCP SPT=52877 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 4 15:04:01 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.6.199.89 DST=87.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=2522 DF PROTO=TCP SPT=59118 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0 Dec 12 13:31:33 fw-03 kernel: INPUTFW IN=ppp0 OUT= MAC= SRC=10.78.21.142 DST=83.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=111 ID=12337 DF PROTO=TCP SPT=59620 DPT=445 WINDOW=8192 RES=0x00 SYN URGP=0
Looking at these log lines, this kind of traffic seems hostile to me as it targets commonly attacked ports such as 22, 23 and 445. I talked to Michael about attack vectors such as injecting traffic from remote IPsec networks (which can also appear on ppp0) the other day, and to his opinion, that is not possible.
For obvious reasons, I am very keen to learn how this traffic is even routable at that place. An ISP support department suggested someone on the same house connection line is injecting traffic, claiming that DSLAM linecard ports usually do not allow DSL subscribers to talk to each other directly, provided the DSLAM operator (which is Deutsche Telekom AG for nearly every location in Germany) filters RFC 1918 traffic.
These are all SYN packets. I suppose they have customers that are leaking internal traffic to the Internet side and the DSLAM is forwarding those packets to a switch somewhere. That switch does not seem to know a MAC address and therefore broadcasts them out on all ports.
That suggests that they do *not* filter any RFC1918 address space. They probably can’t because that is used internally in many networks - because everyone is running out of space.
Either way, this precisely shows why we need a universal switch to drop traffic from and to RFC 1918 (and other) networks on the RED/ppp0 interface of an IPFire machine. As far as I am concerned, this can be done regardless of the blacklist patchset Tim handed in and is not safe to be enabled by default.
Yes, this should be a switch on the firewall options page.
You should consider adding 100.64/? to it which strictly isn’t RFC1918, but the switch should rather say “Block packets from private IP address space on RED”.
If someone else has additional information on this topic, please drop me a line. :-)
Please do not use ipset. A chain that is simply populated when this is enabled is fine.
Ideally try to put this after the connection tracking. You will still see them in the IPS then.
Thanks, and best regards, Peter Müller