18 Sep
2018
18 Sep
'18
3:39 p.m.
Since two days ago someone is scanning the internet for IPIP decapsulation gateways,
hitting our gateway system.
The packets look like this (shortened tshark output):
Internet Protocol Version 4, Src: 35.231.13.238 (35.231.13.238), Dst: 44.137.164.26
(44.137.164.26)
Version: 4
Total Length: 69
Time to live: 236
Protocol: IPIP (4)
Source: 35.231.13.238 (35.231.13.238)
Destination: 44.137.164.26 (44.137.164.26)
Internet Protocol Version 4, Src: 44.137.164.26 (44.137.164.26), Dst: 35.231.13.238
(35.231.13.238)
Version: 4
Time to live: 255
Protocol: UDP (17)
Source: 44.137.164.26 (44.137.164.26)
Destination: 35.231.13.238 (35.231.13.238)
User Datagram Protocol, Src Port: 35261 (35261), Dst Port: 5974 (5974)
Source Port: 35261 (35261)
Destination Port: 5974 (5974)
Length: 29
Data (21 bytes)
0000 74 68 69 73 20 69 73 20 6e 6f 74 20 61 6e 20 61 this is not an a
0010 74 74 61 63 6b ttack
Data: 74686973206973206e6f7420616e2061747461636b
[Length: 21]
The sender is always 35.231.13.238 (a Google cloud customer), the destination is some
random address
(in this case within AMPRnet because the trace was made on a BGP-routed system) and the
payload is an
IPIP packet which contains a UDP packet back towards the sender.
Despite the text in the packet, the sender is obviously looking for traffic coming back at
that UDP port, and
then knows at which addresses on internet they may find systems that decapsulate IPIP
traffic and route it
back to internet. This can then be used to forge source addresses in attacks.
I advise those that run IPIP gateways to configure a firewall that only allows IPIP
traffic from peers that are
listed in the route info distributed in the RIP packets. This can be done with some
scripting, possibly with
the help of "ipset" to keep a set of valid gateway addresses.
Of course as a first fix you can block all traffic from 35.231.13.238, but that address
could change any time.
Rob