ISPs And Router Security

IPvNOT asks: "With all the script kiddies and distributed denial of service tools that spring up each week, there is an increasing use of spoofed network addresses. It would seem logical to me, to help control some of the problem, for ISP's to install a simple access control list (ACL) entry that blocks all packets that do not contain an address within their 'internal' network. How hard would this be to implement on a large scale? Would ISPs implement this?" I would think that an ISP would be able to block and drop anything they receive from the outside if its IP address starts with '192.168.', '127.' or '10.', and there are several others that can be screened for -- are there reasons that ISPs don't do this?

Comments

Some ISPs will

[grahamsz]

But if you start applying further checks to every packet then the network will surely start to slow and in such a competitive world isps dont want that.

In addition even if 90% of isps can be persuaded to implement it, there are enough that will disregard it and the attacks will surely continue.

Re:Some ISPs will

[FattMattP]

In addition even if 90% of isps can be persuaded to implement it, there are enough that will disregard it and the attacks will surely continue.

Yeah, but if you are lucky enough to get 90% of them to implement this, then it probably wouldn't be hard to refuse traffic to/from the other 10% until they lceaned up their act. Getting that first 90%, though. That'd be tough.

Re:Some ISPs will

[villeww]

See RFC2827 , which describes the Best Current Practice for doing Ingress Filtering. Just the thing needed to block most of the DDoS attacks.

Re:Some ISPs will

[DeeDee]

Performance is one thing , security another .

If you are talking about routing and networking , a lot of universities are checking these matters and have come up with some interesting tools to handle it . For example Merit (www.radb.net) has sponsored a research to auto-configure the most used routers (Cisco , Bay , Juniper , Gated ) based on a RFC-defined database (RPSL). These tool create access-lists that will allow you to filter routing updates based on prefix filters, as paths etc. Here you also filter any reference to RFC1918 , called martians.
On The major NAPS in the states these configs become to big for prefix lists and security will have to be based on as-path lists ... however it STILL DOES THE TRICK. From our experience using these techniques does not decrease the performance but increases the security. From a mangement perspective, as these tools are auto-updated , this is also very acceptable..

If we are talking about ISP serverfarms , then they should be punished for not using spoof alerts on their firewalls.. it is not difficult and is one of the first things you learn on a security course..

Re:Some ISPs will

[WNight]

This happens *all* the time. Friends of mine admin a fairly large ISP (multiple OC3, 50k users, etc) and they tell me that they and other admins blackhole a lot of sites on an informal basis...

They maintain their own database of spammers and use it as well as checking over MAPS and ORBS lists, they MD5 mail bodies, checking for duplicates and when they get an identical message being sent to more than ten users from an unknown address, a human looks at it before it gets forwarded. (Usually it's spam, sometimes it's a new mailing list.)

Similarly, if there's a local ISP that's been used for spam, or attacks, they simply drop all traffic from it. On the off chance that something at that one ISP is wanted by customers, they set up a filtering proxy, or such, as appropriate, to allow just certain things through.

And they've done it with large national ISPs too.

The users don't know why a site is unreachable and the internet is too chaotic for them to be able to tell.

And really, what's the difference if a site is down because it crashed, or because it's so insecure it's a hazard? In either case, badly configured/run ISPs don't talk to the rest of the net for long.

Bad ACL's

[arberya]

Many ISP's see ACL's as processing overhead on their border routers. Most of this may be due to badly designed ACL's. Reserved addresses (such as the 10.x.x.x,...,192.168.x.x and any hosts from within the network should be blocked ( it is unlikely that traffic coming into your network should have an ip from within your network as it's source ip) We had some high processor utilisation on our border router and after looking at our ACL's, have reduced the utiliztion by 30%. Quality not Quantity is the key.

Re:Perhaps they should block far more than that.

[Quietust]

Which is what my ISP does already; any traffic coming from inside with an IP not within 169.207.*.* gets dropped and returns an error packet to the sender. Likewise, anything coming into the ISP marked as coming from one of their IP ranges should be blocked (a packet coming from (for example, if I'm on a LAN with a firewall facing the outside and my IP is 192.168.0.1, I should not be getting packets from 192.168.0.2 through the firewall since that address is already behind it).
Sadly, the only thing that prevents other ISPs (and universities, by far the worst) from doing this is sheer lazyness or ignorance.

-- Sig, 120 chars --
Your friendly neighborhood mIRC scripter.
if (ismoderator(reader)) hidecomment(this);

Don't use ACL

[bwalling]

route 10.0.0.0 0.0.0.255 nul0

Create a nul interface (many routers support this) and update your routing tables to route RFC1918 into the nul interface. Easier and better than using an ACL.

Obviously, this is not always feasible. Many cable/DSL ISPs use RFC 1918 addresses for the Cable/DSL modem devices (there is DHCP option 82 to distinguish whether the request came from the customer's PC or their cable modem). So, you'd have to let the traffic get all the way to your border router before stopping it.

Re:Firewall

[Syberghost]

You can't firewall the backbone. There's not a firewall on the planet that could handle the full output of an OC-192, even if you blocked hardly anything.

Plus, anything you choose to block is something that somebody else won't blocked.

Unless you want to replace all the current big iron backbone routers with multi-million-dollar superclusters, and thus have your dialup internet access cost you $1,000 a month, this can't happen with current technology.

Some filtering can be done, and not enough is done, but it can't all be filtered, and it can't be firewalled in the core.

Firewalling belongs on the edges.

--

Cos they don't know better?!

[Cef]

Unfortunately a lot of ISP network roll-outs are done by people with very little IP network experience, or by "high paid" consultants.

The people without network experience are somewhat excused, but they should have gotten someone to look it over, and actually try some sort of penetration tests. They'd probably find a lot more wrong with it than routing non-routable IP's.

The consultants don't tend to bother unless asked, as it adds to their already high workload, plus they most likely think "I'm not getting paid enough to do that as well!". Some even just assume that the routers won't even route this sort of traffic unless told to.

A lot of routers don't help in this situation either. The training courses and/or materials for setting them up in many cases are rather badly written, don't cover a huge number of setup scenarios, and usually don't even bother to bring up these sorts of things at all.

On top of all this, you get things like the Managing Director of the company connecting a modem up to his PC and dialling out to his home account cos the connection to the net through the filewall is too slow (which is actually cos someone is trying to launch a DOS attack on your firewall), and then someone gets to his local files cos of some piece of software that he shouldn't have on the laptop in the first place.

Regardless, even if they did block the non-routable IP's, you should still "trust no one" and block whatever you can. If it's connected to the outside world, then there is a possibility that somehow, you could lose out.

The only way to truely protect your data is to grind up your hard drive into powder, magnetize it all, then heat it into a liquid. Cool and grind it up again, scatter it into the wind, and just HOPE entropy does the rest.

Re:be wary of this kind of thing

[pingflood]

I take it passwords on accounts are a bad thing, too? This is just a security measure and doesn't infringe on anyone's rights, unless you believe that the script kiddies have some sort of fundamental right to launch DDOS attacks.

Nothing wrong with a little paranoia, but your statement is just plain illogical.

-pf

Routing and security

[Gondola]

I worked at a major internet provider for over 2 years, and when I left I was Senior Network Engineer, with only the head of the engineering department above me, and above him was the CTO. We had over a dozen POPs (Points of Presence), and OC3 lines strung from MAE East to MAE West and many points between, and OC12's being installed. So, let's assume I can speak slightly to this issue.

With a major provider, your hardware is going to be big enough (BFR, GRF, etc) to handle 60,000+ routes AND do adequate security filtering. Don't accept the RFC'd routes in, and don't propogate them. Period. Don't accept internal routes from external sources. These are simple rules any major provider *can* handle if they can handle a full routing table. We're talking edge routers.

Smaller providers who are multi-homed and that lease dialups wholesale are a problem, though. Their dialups have IPs that don't belong to them. They often don't have the expertise to configure their ACLs correctly, and leave gaping holes in their security. Sometimes we'd scan our customers' routers with SNMP probes and find a lot of default SNMP passwords for read *AND* write access to their router, and we'd let them know to button up their router. One of our routers would occasionally get flooded with extra routes from a customer (we had lousy filtering) and the resulting flood of traffic would kill the customer's router. The first sign of this would be the customer's line going down. We were understaffed and used several different kinds of routers, so ACL's varied slightly between platforms because of the way they had to be written.

My point is that you need three things for merely minimal security (just by IP blocks):

Hardware: a router with enough CPU and enough RAM
Expertise: engineers that know how to write ACLs for the IOS you're using
Priority: your engineers have to have the time to actually sit down and get the ACLs updated on all the routers correctly

Unfortunately, I don't think there are many providers that have all of these.

ACL's on Routers

[TBC]

From experience, on the edge of the network, there is NO reason for a packet to come into the network that is not part of your address space. Edge is defined as a single-homed connection with no transit capability. We have a packet filter on our edge routers as well as our core multi-homed router to deny traffic with a source address that doesn't match one of our class-C's.

The problem with doing this on a Cisco is that it requires the CPU to observe the header of each packet going out, rather than have the interface DMA the packet to the destination interface. During the last big round of DDOS attacks, (January-February) we say many ISPs try to put filters in their core routers. The result was a 4x+ increase in CPU usage in the routers, and a router crash in a lot of cases.

We saw BGP traffic increase by over 10x as these routers came up and down all across the Internet. We have our core router set up to log faked ingress packets, and you wouldn't believe how many packets we see. Also be aware, it's not always a DDOS attack that causes spoofed packets. We see misconfigured windows boxes leak the Microsoft Ethernet addresses out PPP, misconfigured firewalls leaking internal addresses, etc. We see no issues with filtering these packets since there isn't a way for those packets to get back to us anyway, and it takes up more of our outgoing bandwidth...

Best bet is to filter as close to the edge as you can. For companies that sell bulk-dialup, their access servers can be configured to filter packets not on their address pools. The routers serving those modem pools could filter on the addreses for that data-center. Cable providers could filter based on the IP addresses assigned to that cable head-end. If we can filter right up to the edge of the transit-network, DDOS should be a thing of the past....

Right idea, wrong implementation

[Plasmic]

I completely agree: null routes are the easiest way to ensure that you don't allow RFC 1918 ingress or egress traffic. Here's the key paragraph from the RFC:

Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks.

However, your subnet mask (as is the correction you posted) is goofy, although it makes a nice wildcard mask. Let's give the Cisco kids out there some useful syntax that they can cut-and-paste into their routers (as long as they're in privileged exec/enable mode):

ip route 10.0.0.0 255.0.0.0 null0
ip route 127.0.0.0 255.0.0.0 null0
ip route 172.16.0.0 255.240.0.0 null0
ip route 192.168.0.0 255.255.0.0 null0

Re:No security I've seen stops DDoS attacks.

[logicTrAp]

The point is that if every ISP filtered outgoing packets to make sure that they came from legitimate IP addresses, while it may not stop DOSes, it would at least make it a LOT easier to shut down the offending sites since they couldn't lie about where they were coming from. Currently when you get DOSes, it requires a hellish amount of effort from the backbone providers if you want to try to figure out where the (spoofed) packets are coming from.

Re:Firewall

[TheGratefulNet]

You can't firewall the backbone. There's not a firewall on the planet that could handle the full output of an OC-192, even if you blocked hardly anything.

uhm - incorrect. the current best-of-breed routers (core routers) CAN filter at full oc192 speeds. I won't mention names, but its not cisco; its one of their competitors...

--