From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Observing (malicious?) traffic from RFC 1918 source IP addresses to ppp0 interfaces Date: Fri, 13 Dec 2019 22:33:38 +0000 Message-ID: <0591DFF7-95AE-4690-BD95-C4FAC661DAE2@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3254445030924689306==" List-Id: --===============3254445030924689306== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 13 Dec 2019, at 18:36, Peter M=C3=BCller wr= ote: >=20 > Hello *, >=20 > 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 c= onnection) > of an IPFire machine: >> 12/09/2019-11:38:23.050370 [Drop] [**] [1:2010935:3] ET SCAN Suspicious i= nbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Pri= ority: 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 i= nbound to MSSQL port 1433 [**] [Classification: Potentially Bad Traffic] [Pri= ority: 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 d= ropped 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= =3D18456 PROTO=3DTCP SPT=3D54261 DPT=3D5555 WINDOW=3D60621 RES=3D0x00 SYN URG= P=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=3D2999= 7 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.= 10.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= =3D60440 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= =3D30575 DF PROTO=3DTCP SPT=3D59055 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D15843 DF PROTO=3DTCP SPT=3D59055 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D29263 DF PROTO=3DTCP SPT=3D58991 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D17475 DF PROTO=3DTCP SPT=3D58991 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D17600 DF PROTO=3DTCP SPT=3D59050 DPT=3D22 WINDOW=3D8192 RES=3D0x00 SYN URG= P=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= =3D11551 DF PROTO=3DTCP SPT=3D59050 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D10682 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= =3D36323 PROTO=3DTCP SPT=3D57273 DPT=3D9527 WINDOW=3D39680 RES=3D0x00 SYN URG= P=3D0=20 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 dr= opping > 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=3Dppp0 OUT=3D MAC=3D SRC=3D192= .168.1.170 DST=3D85.XXX.XXX.XXX LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D52 ID= =3D45421 PROTO=3DTCP SPT=3D54261 DPT=3D5555 WINDOW=3D60621 RES=3D0x00 SYN URG= P=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 I= D=3D2893 DF PROTO=3DTCP SPT=3D50188 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN UR= GP=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= =3D23895 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D7772 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN UR= GP=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= =3D15452 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D8231 DF PROTO=3DTCP SPT=3D52374 DPT=3D8291 WINDOW=3D8192 RES=3D0x00 SYN UR= GP=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= =3D8764 DF PROTO=3DTCP SPT=3D52374 DPT=3D22 WINDOW=3D8192 RES=3D0x00 SYN URGP= =3D0=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= =3D29653 DF PROTO=3DTCP SPT=3D52374 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=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= =3D23036 DF PROTO=3DTCP SPT=3D52374 DPT=3D8728 WINDOW=3D8192 RES=3D0x00 SYN U= RGP=3D0=20 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=3Dppp0 OUT=3D MAC=3D SRC=3D10.79.= 38.29 DST=3D87.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D112 ID=3D352= 9 DF PROTO=3DTCP SPT=3D63955 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0 = >> Dec 3 09:19:53 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D192.16= 8.254.129 DST=3D83.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D119 ID= =3D31437 DF PROTO=3DTCP SPT=3D52877 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN UR= GP=3D0=20 >> Dec 4 15:04:01 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.6.1= 99.89 DST=3D87.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D117 ID=3D252= 2 DF PROTO=3DTCP SPT=3D59118 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D0 = >> Dec 12 13:31:33 fw-03 kernel: INPUTFW IN=3Dppp0 OUT=3D MAC=3D SRC=3D10.78.= 21.142 DST=3D83.XXX.XXX.XXX LEN=3D52 TOS=3D0x00 PREC=3D0x00 TTL=3D111 ID=3D12= 337 DF PROTO=3DTCP SPT=3D59620 DPT=3D445 WINDOW=3D8192 RES=3D0x00 SYN URGP=3D= 0=20 >=20 > 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 a= ttack > vectors such as injecting traffic from remote IPsec networks (which can als= o appear > on ppp0) the other day, and to his opinion, that is not possible. >=20 > For obvious reasons, I am very keen to learn how this traffic is even routa= ble at > that place. An ISP support department suggested someone on the same house c= onnection > line is injecting traffic, claiming that DSLAM linecard ports usually do no= t 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 19= 18 traffic. These are all SYN packets. I suppose they have customers that are leaking int= ernal 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 th= erefore broadcasts them out on all ports. That suggests that they do *not* filter any RFC1918 address space. They proba= bly can=E2=80=99t 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 tra= ffic 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 patc= hset 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=E2=80=99t RFC191= 8, but the switch should rather say =E2=80=9CBlock packets from private IP ad= dress space on RED=E2=80=9D. > 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 enable= d is fine. Ideally try to put this after the connection tracking. You will still see the= m in the IPS then. > Thanks, and best regards, > Peter M=C3=BCller --===============3254445030924689306==--