22 Sep
2016
22 Sep
'16
5:02 p.m.
Yes, there are some good points in what Jakub has written.
Password authentication mechanism in RIPv2 is meant to
protect against
accidental misconfigurations and is the only way of configuring ampr-ripd
routing.
Correct, the only use at the moment is to actually validate the RIP
data. But I don't think this could eliminate actual misconfigurations,
unless there are more RIP informations form other sources involved.
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.
And even if this is done, what does the attacker achieve? A redirection
of remote tunnels to a fake endpoint. To do what? To send data to a now
isolated system? To browse its web page from a fake host?
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.
Even so, in such a case, regular firewalling like on a regular internet
host would prevent any malicios activity.
Furthermore, portal.ampr.org allows anybody with valid
email address to
route any 44/8 subnet through any IP address, not only subnets assigned to
account in use. There're no restrictions to do so and it will stay there
and get broadcasted until somebody notice.
This is not true. By registering a
gateway, you can use your assigned
subnet through your registered gateway. But if that subnet is already
assigned to a gateway, you can not assign it to your own gateway without
deassigning it from the old gateway first.So this is a non-issue unless
there are unassigned subnets floating around in the portal for people to
grab. But these are mostly the result of misconfiguration and lack of
knowledge, not the work of an attacker. And it will disrupt only that
specific subnet.
So here we may need some improvement tot to allow e.g. assignements of
national or regional subnets assigned to administrators to regular
users, which are the most likely to float since they are not bound to
any gateway.
So I would say: Let's see how this password thing turns out. We can
always change the password from the current one if needed, and the tools
provide a way to do it on the user side. Making things more complicate
will not help anyone.
Marius, YO2LOJ