RIPv4 security - 44net

22 Sep 2016

I hope that I'm not breaking thread continuity, but I've subscribed
requesting daily batches and don't know how to change it.

...
   As it is UDP
based and relies on source of UDP packets, which is easy to
 spoof, current routing infrastructure is vulnerable to unrestricted
 injecting of 44/8 routes to it's gateways - anybody can send forged RIP
 updates to them.  Here I don't think the situation is that critical. The RIP
updates are
 sent via tunnel, and should be accepted only from the ampr-gw tunnel
 interface. The attacker needs actually to block out original IPIP
 traffic and spoof the IPIP tunnel to get fake RIP data into the network.
 This is a little harder than just sending a bunch of UDP packets to a host.

It's just as hard as decapsulating these packages in ampr-ripd.
There's no need to disturb communication, as IPIP tunnel is not being
established - it's just another IP header one can easily spoof, there's no
authenticity control.

This kind of DoS attack on AMPRnet won't be very interesting, but may be
quite annoying to gateway operators. On the other side, it may result in
sending unsolicited IPIP traffic to random hosts. Firewalling (by
restricting pool of destination hosts for protocol 4) would do the job of
limiting such activity, but on the other hand would be one step back, as
list of gateways would need maintenance by hand.

...
  I really don't see the point of doing that.
Crackers want benefits from
 their work: e-mail collecting, snmp access, spamming, not the glory of
 sending data to a compromised system to which they are the only ones
 having access. And creating a DOS attack like this on an APMPR host is
 nothing interesting. 
So I do. Can't find any other use than a bit creepy SMURF-like DDoS.

...
  So this is a non-issue unless
 there are unassigned subnets floating around in the portal for people to
 grab. 
There's a lot of such subnets. I just got banned for routing one of them
through 192.168.0.1.