From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Observing (malicious?) traffic from RFC 1918 source IP addresses to ppp0 interfaces Date: Fri, 13 Dec 2019 18:36:00 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7066180608211852320==" List-Id: --===============7066180608211852320== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 con= nection) of an IPFire machine: > 12/09/2019-11:38:23.050370 [Drop] [**] [1:2010935:3] ET SCAN Suspicious in= bound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Prio= rity: 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 in= bound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Prio= rity: 2] {TCP} 192.168.145.52:53061 -> 85.XXX.XXX.XXX:1433 Digging more deeply into the packet filter logs, this seems to happen quite f= requently (I guess those both packets above were not logged because the IPS already dro= pped them; otherwise it would be really alarming): > Dec 8 21:49:14 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.170 DST=3D85.XXX.XXX.XXX LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D= 18456 PROTO=3DTCP SPT=3D54261 DPT=3D5555 WINDOW=3D60621 RES=3D0x00 SYN URGP= =3D0=20 > Dec 9 11:01:29 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.0= .0.8 DST=3D85.XXX.XXX.XXX LEN=3D44 TOS=3D0x00 PREC=3D0x00 TTL=3D51 ID=3D29997= PROTO=3DTCP SPT=3D30279 DPT=3D23 WINDOW=3D6695 RES=3D0x00 SYN URGP=3D0=20 > Dec 9 20:52:38 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.1= 0.204.161 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D112 ID= =3D25793 DF PROTO=3DTCP SPT=3D2146 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URG= P=3D0=20 > Dec 9 21:22:07 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.120 DST=3D85.XXX.XXX.XXX LEN=3D44 TOS=3D0x00 PREC=3D0x00 TTL=3D51 ID=3D= 60440 PROTO=3DTCP SPT=3D48033 DPT=3D23 WINDOW=3D57033 RES=3D0x00 SYN URGP=3D0= =20 > Dec 11 14:29:09 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 30575 DF PROTO=3DTCP SPT=3D59055 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:12 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 15843 DF PROTO=3DTCP SPT=3D59055 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:13 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 29263 DF PROTO=3DTCP SPT=3D58991 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 17475 DF PROTO=3DTCP SPT=3D58991 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:16 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 17600 DF PROTO=3DTCP SPT=3D59050 DPT=3D22 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:20 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D115 ID=3D= 11551 DF PROTO=3DTCP SPT=3D59050 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 23:51:27 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D172.= 16.42.211 DST=3D85.XXX.XXX.XXX LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D54 ID=3D= 10682 PROTO=3DTCP SPT=3D20479 DPT=3D80 WINDOW=3D28891 RES=3D0x00 SYN URGP=3D0= =20 > Dec 12 16:00:57 fw-01 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D172.= 21.75.234 DST=3D85.XXX.XXX.XXX LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D= 36323 PROTO=3DTCP SPT=3D57273 DPT=3D9527 WINDOW=3D39680 RES=3D0x00 SYN URGP= =3D0=20 I initially blamed the (rather small German) ISP of that machine for not drop= ping bogon traffic at their edge routers. However, the same - hostile? - traffic c= an also be observed at different locations behind different ISPs (using VDSL here): > Dec 9 23:37:18 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.170 DST=3D85.XXX.XXX.XXX LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID=3D= 45421 PROTO=3DTCP SPT=3D54261 DPT=3D5555 WINDOW=3D60621 RES=3D0x00 SYN URGP= =3D0=20 > Dec 10 09:44:52 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.100.159 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D112 ID= =3D2893 DF PROTO=3DTCP SPT=3D50188 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URG= P=3D0=20 > Dec 11 14:29:08 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 23895 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:11 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 7772 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:12 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 15452 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 8231 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:15 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 8764 DF PROTO=3DTCP SPT=3D52374 DPT=3D22 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D= 0=20 > Dec 11 14:29:18 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 29653 DF PROTO=3DTCP SPT=3D52374 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 11 14:29:21 fw-02 kernel: DROP_INPUT IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.= 168.1.76 DST=3D85.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D116 ID=3D= 23036 DF PROTO=3DTCP SPT=3D52374 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 2 21:09:01 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.79.3= 8.29 DST=3D87.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D112 ID=3D3529= DF PROTO=3DTCP SPT=3D63955 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0=20 > Dec 3 09:19:53 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.168= .254.129 DST=3D83.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D119 ID=3D= 31437 DF PROTO=3DTCP SPT=3D52877 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=20 > Dec 4 15:04:01 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.6.19= 9.89 DST=3D87.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D117 ID=3D2522= DF PROTO=3DTCP SPT=3D59118 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0=20 > Dec 12 13:31:33 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.78.2= 1.142 DST=3D83.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D111 ID=3D123= 37 DF PROTO=3DTCP SPT=3D59620 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0= =20 Looking at these log lines, this kind of traffic seems hostile to me as it ta= rgets commonly attacked ports such as 22, 23 and 445. I talked to Michael about att= ack 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 routabl= e at that place. An ISP support department suggested someone on the same house con= nection 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. Either way, this precisely shows why we need a universal switch to drop traff= ic from and to RFC 1918 (and other) networks on the RED/ppp0 interface of an IPFire m= achine. As far as I am concerned, this can be done regardless of the blacklist patchs= et Tim handed in and is not safe to be enabled by default. If someone else has additional information on this topic, please drop me a li= ne. :-) Thanks, and best regards, Peter M=C3=BCller --===============7066180608211852320==--