1

My (linux) server has some fairly simple iptables rules.

iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport https -j ACCEPT
iptables -A INPUT -j LOG
iptables -A INPUT -j NFLOG
iptables -A INPUT -j DROP

ICMP goes unfiltered, but no other uncessessary connections allowed. The NFLOG rule just stores packets into a packet capture fule (pcap). Because syslog got quite spammy, i looked into the details of the packets.

tshark -V -a filesize:1 -r /scooby/doo.pcap (IPs & Ports [replaced])

Frame 1: 52 bytes on wire (416 bits), 52 bytes captured (416 bits)
    Encapsulation type: Raw IP (7)
    [Protocols in frame: raw:ip:gre:ip:udp:data]
Internet Protocol Version 4, Src: [incoming IP] ([incoming IP]), Dst: [my server IP] ([my server IP])
    Version: 4
    Header length: 20 bytes
    Total Length: 52
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
    Time to live: 52
    Protocol: GRE (47)
Generic Routing Encapsulation (IP)
    Flags and Version: 0x0000
    Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: [not my IP1] ([not my IP1]), Dst: [not my IP2] ([not my IP2])
    Version: 4
    Header length: 20 bytes
    Total Length: 28
    Time to live: 64
    Protocol: UDP (17)
User Datagram Protocol, Src Port: [random port1] ([random port1]), Dst Port: [random port2] ([random port2])
    Length: 8

The unsolicited packets are mostly ip:gre:ip:udp packets. The volume of GRE packets - usually multiple per minute - greatly outweights other unsolicited packets (vulnerability scanners / spammers / port scanners). None of the IPs inside the GRE encapsulation have any special meaning to me, just various regular IPs belonging to (exclusively) US-based companies (so, not entirely random addresses).

Why would someone send those GRE packets?

Are there known DoS vulnerabilities related to GRE packets? Is this an attemt to fool misonfigured routers/servers into forwarding the encapsulated packets to their apparent destination? Does the sender try to gather information about the nature of potential GRE tunnels i may have setup?

Bonus: Is the most reasonable reaction really "-j DROP"-ing them?

anx
  • 8,963
  • 5
  • 24
  • 48
  • How many is 'many' what proportion of the total traffic? – user9517 Jan 01 '17 at 17:08
  • Do you have any examples of this traffic? – Michael Hampton Jan 01 '17 at 18:31
  • 1
    Exactly what did you redact? Remember that you should [_avoid redacting_](http://meta.serverfault.com/q/963/126632) if possible, especially in a situation like this, as it will only cause confusion. – Michael Hampton Jan 01 '17 at 20:42
  • 1
    That might be so, and that's an additional reason that I suspect that you have redacted too much and therefore will not be able to get an answer. – Michael Hampton Jan 01 '17 at 20:54
  • 1
    I've been seeing an uptick in these every day across all my internet facing VM's. Not a large amount, but it's probably just some scanner / bot. Unless you have rules that would permit that protocol and something listening for GRE, then no harm. – Aaron Jan 02 '17 at 02:05
  • 1
    [Here](https://isc.sans.edu/forums/diary/More+on+Protocol+47+denys/21867/) is more detail about the uptick in unsolicited GRE traffic. – Aaron Jan 10 '17 at 03:14

1 Answers1

0

According to Rick Wanner (ISC), such traffic was likely connected to the Mirai botnet. He commented on it here & here (thanks, @Aaron) As @Michal Hampton suspected, the addresses contained in the payload are a clue: they appear to match the pseudo random number generator contained in Mirai - though i have been unable to confirm this.

Brain Krebs says his website was downed at least to some degree through GRE spam. The reasoning behind sending GRE (ip/47) as opposed to more traditional DDoS methods is not obvious. Speculation on why GRE is used in DDoS:

  1. bugs in GRE routers that can be abused to either reflect traffic or map otherwise inaccessible network topology
  2. stateful firewalls that include reasonable defaults for icmp/tcp/udp, but choke/misbehave on full pipes of unusual protocols.
  3. bad QoS configuration in routers effectively prioritizing DDoS traffic
anx
  • 8,963
  • 5
  • 24
  • 48