Re: Observing (malicious?) traffic from RFC 1918 source IP addresses to ppp0 interfaces

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 8691 bytes --]

Hi,

> On 13 Dec 2019, at 18:36, Peter Müller <peter.mueller(a)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