From: "Peter Müller" <peter.mueller@ipfire.org>
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 [thread overview]
Message-ID: <b6b873f7-0f3a-a8ea-615d-99d5f9b66817@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 7387 bytes --]
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
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
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
> 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.
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.
If someone else has additional information on this topic, please drop me a line. :-)
Thanks, and best regards,
Peter Müller
next reply other threads:[~2019-12-13 18:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 18:36 Peter Müller [this message]
2019-12-13 22:33 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6b873f7-0f3a-a8ea-615d-99d5f9b66817@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox