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
18 Sep
18 Sep
4:14 p.m.
Mikrotiks can use the address list wich gets created from the rip packets from the ampr
gateway
Ruben - ON3RVH
On 18 Sep 2018, at 21:40, Rob Janssen
<pe1chl(a)amsat.org> wrote:
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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
20 Sep
20 Sep
2:21 a.m.
It is also a good idea to block forwarding from/to AMPR interfaces other
than your own internal 44 network.
On 18.09.2018 22:39, Rob Janssen wrote:
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
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2254
days inactive
2256
days old
2 comments
3 participants
participants (3)
-
Marius Petrescu -
Rob Janssen -
Ruben ON3RVH