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
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@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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
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@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net