Slashdot Log In
ISPs And Router Security
Posted by
Cliff
on Mon Jul 24, 2000 06:57 AM
from the would-this-break-something? dept.
from the would-this-break-something? dept.
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?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Some ISPs will (Score:3)
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.
Perhaps they should block far more than that. (Score:2)
They should block far more than that. They have an IP range. Anything going out with a source that's not in the IP range should be blocked, imho.
Bad ACL's (Score:4)
The problem is... (Score:2)
Additionally most ISP's want their resources to be widely available. If you can't get your mail from both home and work because the ISP blocks access from your work ip address (on a frame-relay or dsl connection) you will most likely not want to continue doing business with that ISP.
Most routers do have ACL's that limit telnet access to certain ip's or subnets. Only a poorly configured router would allow telnet access to the router from any ip address.
-josh
Some ISPs do (Score:2)
At least one of the ISP I worked for rejected packets with private or internal addresses as their sources coming from outside on the border routers.
A good citizen ISP should even filter its dialup pool to reject forgeries from its customers. It's called ingressfiltering and is the most reliable way of getting rid of those smurf and other various DoS attacks.
Re:Some ISPs will (Score:3)
RFC1918 (Score:2)
Camaron de la Isla [flamenco-world.com] 'When I sing with pleasure, my
This would be easy, really. (Score:2)
A second alternative is to have a check on the modem/ISDN/DSL lines, to ensure that the address on the packet is equal to the one assigned the device on that line.
Last, but not least, for only a little extra complexity, use authentication, such as IPSEC or SKIP.
Re:Perhaps they should block far more than that. (Score:3)
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);
Same reason that the DDOS attacks aren't blocked (Score:2)
The problem is that ISPs don't want to slow down their connection by a few bits/second, and they don't want to do that. Slow connections mean fewer customers which means less money.
Re:Some ISPs will (Score:5)
Re:RFC1918 (Score:2)
The more shit you filter, the slower things get. In the core of the big backbones, you can't slow things down or everybody suffers.
Even just filtering RFC 1918 packets is controversial, especially since the RFC doesn't even recommend it, just pronounces it "reasonable".
Go read Shawn's message, and you'll see from the traceroute he included that some pretty big folks leak this crap out into the 'net.
As for the little guys, your average Cisco 2501 would self-destruct if you tried to filter everything that's not from your blocks.
--
Re:ipchains/iptables? (Score:2)
and 155 mbps isn't the fastest there is. my ex-employer had a 655Mbps connection (they are an isp, among other things). i don't think any pc could saturate that connection without _very_ fancy extra hardware.
Don't use ACL (Score:4)
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.
Firewall (Score:2)
What sort of security *is* important on a router? I would've thought that a router would be relatively benign, but can't (once compromised) it provide a gateway to ip spoofing, source and destination address spoofing, packet sniffing, and ip source routing? (and denial of service attacks, of course, we won't forget those!) Why else secure a router if you've got a secure firewall?
Lazy or Overworked (Score:2)
I deal with security incidents all day. Every admin that I talk to that has been rooted or is being used as an amp start always say: "I should have..." And, they are right, they should have, but they didn't. Admins need to have some plan for security.
Quick and dirty list of security tips:
Re:Some ISPs will (Score:4)
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
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:Firewall (Score:3)
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?! (Score:4)
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 (Score:3)
Nothing wrong with a little paranoia, but your statement is just plain illogical.
-pf
Not as easy as you think (Score:2)
One of the problems I see with your theory of blocking out all private addresses (for those of you keeping score at home, that's 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x) is that you won't see these addresses trying to come in through your firewall (if you've built it right) as often as you'd think. With Network Address Translation (NAT) and Port Address Translation (PAT), you'll see the public IP addresses of these hosts being attacked more often than not. The ability of any given script kiddie to modify the TCP header will complicate this, but without prior knowledge of your network it's a hit and miss attack. For all they know, you could be running any combination of subnetted private and/or public IP addressing schemes behind your firewall.
The best defense against these attacks is a good ACL on a solid firewall platform. Block incoming traffic from private addresses, but be sensible and put internet accessible hosts on a DMZ. For general internet use, select one public IP address from your pool of public IP addresses and use PAT.
The info above was typed out haphazardly and may not make sense, but after working with Internet security in a myriad of environments, the best advice I can give you is that if even if you THINK you understand it, you should still seek consult (the more eyes the better). I would go into more detail, but unfortunately I have to go set up a firewall for a client :)
Yes, there's a reason... (Score:2)
However, I would say the biggest reason is that this kind of filtering can eat a *lot* of processor cycles on your router. These routers are not cheap, so you tend to buy the least you can get away with.
Also, the packet by packet comparison necessarily slows down traffic. Not a big deal for a small line, but when you're dealing with multiple OC-3's, people get a little antsy about a 10% performance decrease.
--
Routing and security (Score:5)
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.
Re:Some ISPs will (Score:2)
In order to survive a DoS the ISP must have spare bandwidth. I wonder how much that costs? If 90% implemented these measures imagine the savings for ISP's
Many ISP do (Score:2)
Re:Some ISPs will (Score:2)
Which would you prefer, a more secure Internet or a faster Internet? Of course, we'd all like both but if you could only pick one, which would it be? If you value performance over security, then would ignore the ACLs and just hope for the best. If you value security over performance, you'll impose the ACLs and just improve performance over time as you upgrade your network equipment.
Besides, there are technologies that exist (both proprietary and standards-based) for improving the performance of packet-forwarding, even with ACLs - for example, Cisco IOS-based routers could use NetFlow or CEF (Cisco Express Forwarding); other platforms should investigate MPLS (Multiprotocol Label Switching) for reducing the routing decision load from their layer 3 infrastructure and keep packets flowing at layer 2 speed.
Don't have a NetFlow, CEF or MPLS-capable router? Then perhaps you don't forward sufficient traffic to worry about the ACL load in the first place; after all, if every edge ISP imposed ACLs to reduce IP spoofed packets from leaving their networks, there would be no need to perform additional filtering/ACLs in the network core (where most traffic exists).
Think about it - performance isn't really an issue at all; if you have the numbers to prove that it is an issue, then you should really consider upgrading your equipment because you're ripping off your customers. Don't trade on FUD - either prove that it's a performance problem or impose the ACLs and help kiss a lot of DoS problems "good-bye".
ACL's on Routers (Score:4)
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....
Possible problems (Score:2)
It seems that some networks (including @home) are too cheap to assign an external IP to all of their routers, so when traffic goes through their network, the routers routing it have internal IP addresses (which are not noticed unless you do a traceroute or just ping with a low TTL set).
Example: try tracert'ing a few IPs in the 24.112.51.* (@home) range.
-- Sig, 120 chars --
Your friendly neighborhood mIRC scripter.
if (ismoderator(reader)) hidecomment(this);
Some ISP's _do_ block bad IP addresses in routers! (Score:2)
Now, the question in my mind is whether the effort we made (to secure the networks from spoofing attacks) was typical or atypical of reasonably-sized ISP's? (When I started at this ISP, they had two T1's to one backbone provider; now they have four DS3's to four different backbone providers...)
More details (Score:2)
The original question (without Cliff's comments) is actually why ISPs don't ensure that outgoing packets from their internal networks are indeed sourced from their IP range.
For example, if I'm an ISP who has (to use a popular range ...) 24.226.0.0/255.255.0.0 , I would add a firewall entry that outgoing packets are denied if they are not from 24.226.0.0/16 (same netmask as above, incidentally).
For multiple source IP ranges (including private network addresses), this can be extended by making an ipchains output filter to allow packets going into the network (they've already passed the input and forward filters) and packets sourced from your IP ranges, then deny'ing the rest. Don't forget to add IP spoofing filters to your input chain.
Final note: I actually do administer a network and am doing this. I've turned on logging on those spoofed packets of course, to see if I'm denying anything that shouldn't be, but it works quite well.
Can't get there from here (Score:2)
The conclusion was that RFC1918 suggests that ISP's prevent reserved addresses from being forwarded, but does not require filtering.
"should take measures" != "MUST NOT"
Also, any packet based ACL is simply impractical on core routers, except for the very fastest (like Juniper M40). Sure, they use ACL's temporarally to fix/debug problems, but leaving them there full time would degrade performance unacceptably.
Re:Some ISPs will (Score:2)
What if you were to check randomly, 5 or 10 percent of the time? I don't think there's an equivalent to ninja pressure point of death skills that will allow someone to 0wn your system with two or three packets, so this should still be enough to alert you but not enough to kill performance.
- Michael Cohn
With large dialpools, doesn't help much (Score:2)
Consequently, at best they'll anti-spoof aggregated blocks, but even that can be impossible to do when the IP address allocation is fully dynamic as it has to be for really big ISPs, especially those that are virtualized into more than one branded product that must operate in disjoint dialpool spaces but using the same dialin hardware. And even where aggregated anti-spoofing is posssible, it does not provide full accountability --- you can nail the DoS to an ISP, but that's all, which doesn't help when DDoS attacks are synchronized to appear from multiple ISPs simultaneously.
As a result, until the NAS/RAS/HomeGateways etc do their own per-connection anti-spoofing, there will always be opportunity for attackers to randomize their source addresses to some degree. The problem at the moment is that there appears to be virtually no anti-spoofing on dialpools at all in practice, and that's real bad.
Re:Cos they don't know better?! (Score:2)
The problem lies with the many ISPs who can't or will not hire competent network admins to maintain the routers after I get them set up.
When I get the routers set up for the first time, the routers closest to the edges will have ACLs conforming to the industry best practices mentioned in RFC2827, and will drop RFC1918 packets. The core routers have only minimal ACLs to prevent security problems such as telnet and SNMP. Core routers are not the place to do heavy filtering, since they are usually overburdened.
When I leave, there is always documentation for the normal netAdmins to pick up where I left off. But many times I've gone back to client sites and found nothing has been touched since I was last there. If there are new admins, they are usually so clueless they don't touch anything the "high paid" consultant implemented. Even when there are comments to them about things to be changed.
Education is the biggest problem right now. The training courses cost too much, and the content can't keep up with all the advances over the last few years. I've spent over US$10,000 of my own money in the last 2 years just keeping my own skills up to date. I don't really expect every Net Admin to do the same, but their employers should be forcing them into at least a few classes each year.
All the routers in an ISP need to be reviewed on a regular basis, and carefully audited for each expansion. But most ISPs are so low margin they just get some high school dropouts to help out and hope for the best. Only when their upstream provider threatens them do they call me back for a quick audit and fix job.
the AC
Re:be wary of this kind of thing (Score:2)
-pf
Re:Can't get there from here (Score:2)
I think it's only a matter of time before an ISP gets sued out of business for allowing forged packets onto the network. If I'm the victim of a DoS attack whose source addresses at least belongs to the true originating ISP, I can probably get things cleaned up in less than an hour. If the source is forged, it might take me days. Do the math on a busy ecommerce site being down for days instead of hours.
No matter what excuses people make, the only beneficiary of allowing forged source addresses onto the net are crackers and script kiddies. If your router can't handle the load, buy a bigger one.
Here is what the "Big Boys" do (Score:2)
Many of the engineers who run the biggest networks work very closely with Cisco to develop, implement and document new features in IOS. Here is a Cisco document which explains how an ISP should implement these features:
http://www.cisco.com/warp/public/707/EssentialIO Sfeatures_pdf.zip
Right idea, wrong implementation (Score:3)
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:Some ISPs will (Score:3)
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.
Re:Some ISPs will (Score:2)
I myself want an ISP that doesn't filter too much, I'd rather be in charge myself, but I want them to do their job first, dropping packets that aren't intended for their network, let alone being passed on to me. That frees more bandwidth for my pr0n downloads, or whatever.
Re:No security I've seen stops DDoS attacks. (Score:4)
Re:Firewall (Score:3)
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...
--
Re:Laziness... (Score:2)
Re:Underpowered routers the problem? (Score:2)
There is a way to do this without burning up all the CPU. In an access-list, the more netblocks you have, the more filter rules you have, and each one bogs down the CPU more an more. The correct solution is different than an access-list. But it needs to be coded directly into IOS and the interface processors.
The logic for this borrows from routing. When a packet arrives on an interface, it will eventually be routed by means of looking up the destination address in the routing tables (and route-maps where configured). What needs to be done first is to use the source address of the packet and do a lookup in the route table. But instead of selecting the best route (lowest metric) just compare the arriving interface with the interface of any valid outgoing route that would be used if the source were a destination. If it matches up, let the packet go on. If not, drop it on the floor.
Once implemented, it would be just a matter of turning it on. Actually, this feature should be on by default. Someone once told me that this feature did exist, but they couldn't say what the command for it was.
Re:Possible problems (Score:2)
Actually I noticed that too. And it's not the modems themselves that have private IPs, it's 3 or 4 hops down the line. I noticed problems when I tried to give my own local domain 10.X addresses and did a traceroute. What can be done about this?
Re:Reserved IP's are the tip of the iceberg. (Score:2)
Re:Cos they don't know better?! (Score:2)
To much load on router? (Score:2)
1)at what point does the slow-down from checking packet headers meet the slow-down from transmitting spoofed packets?
2)Is there any way to do an imperical study to track some statistics?
Re:Cos they don't know better?! (Score:2)
Re:be wary of this kind of thing (Score:2)
But, I fail to understand the problem. Private IP addresses don't belong on the Internet, right?
So, if they don't belong there, they're there either because of an error (ie. plugged Internet connection into the wrong ethernet card on my Linux firewall/router) or because of a malicious attempt to take advantage of a potential security hole.
In either case, there's no legitimate reason why you'd want 192.168.x.x to be on the greater 'net, right?
I'm still a Linux newbie, and I'm still new to the power and responsibility my Linux firewall/router gives me that Windows doesn't. But filtering out all external packets claiming to be from my internal LAN was one of the very first things I did in implementing my firewall; even if I only copied the scripts off a How-To and modified them for my needs.
Speaking of which, how do I set up hosts.deny and hosts.allow to allow all telnet (bad, I know, but I'll never log in as root remotely; I promise) and http requests to my webserver into my LAN? <grin>