Hi, > On 13 Dec 2019, at 18:36, Peter Müller 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