ISPs And Router Security 199
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?
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.
Lazyness (Score:1)
Laziness... (Score:1)
You know certain things about what's inside, and what's outside. Network addresses internal to your network should never be acceptable as a source address on packets coming into your external interface, and addresses which are external should not be accepted as sources on the internal interface of your router. Very simple.
Helps both you and the world.
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)
ipchains/iptables? (Score:1)
Re:Some ISPs will (Score:1)
This came up on one of the SecurityFocus [securityfocus.com] mailing lists recently (BugTraq, I think). Performance was one of the key reasons cited for not implementing such a system; economics was the other. Apparently, there are routers out there that lack the powerful (and reasonably fast) ACL routines but are significantly cheaper than their more powerful brethern; some of them are simply older and lack the features of a new router. Either way, it costs significant money to implement a system with ACL checking, and that's money that ISPs would rather spend on something most customers would notice more directly (e.g. more modem racks or more bandwidth)
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)
IP Security ? (Score:1)
I really don't know anything about this: but I would hope someone else could answer.
Would IPv6/IPSEC security alleviate the situation ? Is it envisaged that internal machines may need to 'register' with a border gateway based upon an administrator supplied certificate ? Could this almost eliminate address spoofing problems ?
be wary of this kind of thing (Score:1)
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.
well.. (Score:1)
Limiting to just the addresses in your own range only partially solves the problem if the attacker can still spoof (but then using addresses in your own range). Limiting the addresses per box would seem more appropriate.
Keep in mind, however, that an attacker will usually use a fairly wide range of cracked machines, most of which are with ISPs that have lax security in the first place. It doesn't seem that the problem spots will be the first to get fixed.
- Talence
This can be done (Score:1)
Cisco has a command "ip verify unicast reverse path" or something.
This command breaks multicast under some conditions, but should work for smaller/simpler networks and edgerouters.
There is also the problem of complexity, if you are a transit and/or multihomed AS.
Complexity can also be bad for your throughput in some routers eg. it may force the processor to make routing decisions, which is slow.
And access-lists have to be maintained.
/Anders
Re:The problem is... (Score:1)
I think that the point was just to block packet with a source address unbelievable, like a private one, or one of your own network coming from the outside.
Your proposal is roughly equivalent to : "pull the plug" :-)
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:Some ISPs will (Score:1)
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.
Re:Don't use ACL - sorry, bad mask (Score:1)
Re:ipchains/iptables? (Score:1)
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:Some ISPs will (Score:1)
Re:be wary of this kind of thing (Score:3)
Nothing wrong with a little paranoia, but your statement is just plain illogical.
-pf
Re:Some ISPs will (Score:1)
Ingress filtering (Score:1)
See following RFCs:
http://www.faqs.org/rfcs/rfc2267.html ('98)
http://www.faqs.org/rfcs/rfc2827.html ('00)
Many 'big' ISPs apply that to their leaf connections at the edge routers, smaller ISPs usually don't do that, which is surprising since its actually simpler to do if you are small. (less edge routers
The only problem with such filtering are people who are dual-homed and have asymmetric routing: I.E. Customer has to connections, to ISPs A and B, and may be sending outbound traffic with source-addresses in B through A's connection.
This is legitimate, there are many uses for it:
1. Satellite one-way connections
2. 'overflow' routing
3. load-balancing of outbound traffic
So, ISP has to blow holes in their filters for such customers. (Which we do at customer request).
Step 1 protect yourself (Score:1)
But you should _never_ relay on somebody else for your own security.
It's a bit like skiping looking the door just because there is a police station in town.
Personally I run ipchains on all my (linux)routers and servers and most workstations, if one firewall is cracked, there is at least some security left in the system.
The big win when ISPs start implementing this is that it reduces pointless the trafic on my local connection.
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.
--
Re:Perhaps they should block far more than that. (Score:1)
Re:Lazyness (or lack of understanding?) (Score:1)
Re:ipchains/iptables? (Score:1)
Re:RFC1918 (Score:1)
Re:ipchains/iptables? (Score:1)
Thx for the nfo
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.
Laziness and Cluelessness (Score:1)
We do it. (Score:1)
"Now, I hope and pray that I will, but, today I am still just a bill"
What happens if I can talk to two routers? (Score:1)
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)
How to secure a router (Score:1)
By the way, although it's true that there's some performance impact from filtering, it's not nearly as much as the ISP folklore (and a lot of the posters here) would have you believe. I've turned on filtering on very heavily loaded routers and had it work fine.
Re:Some ISPs do (Score:1)
egress filtering helps alot as well as getting your upstream to filter for you where they have alot more bandwidth. But that raises another question.....
Recently my network was attacked by a script kiddie (he was attacking my irc server). Egress filtering means nothing on a large network. I've been hit many times with over 100mBit of udp traffic from various edu's all having valid source addy's. The problem is that edu's is where alot of nasty DoS attacks originate. Most of the attacking boxes are either hacked unix boxes with poor security, or dorm machines which have been infected with some nice backdoor trojan like sub7 or netbus etc...
So it has a valid source addy. You call the university, they fix the problem until another one pops up. Woopdee doo. The damage has been already been done. Why don't these universities use any sort of traffic shaping on the various legs of thier networks to keep people from maxing thier drain outbound with some sort of DoS attack that is killing an innocent ISP somewhere else in the world ?
You can block all the trojan's default ports, but they can just be resent to them with non standards ports config'd in. And I know of several universites that really need to learn how to keep thier SunOS boxes from getting owned by script kiddies.
Re:This can('t) be done (efficiently) (Score:1)
The reason it breaks with multiple egress points is because of assymetric routing. What "ip verify unicast reverse-path" does is makes sure that the path back to the source goes throgh the same interface as this packet coming in. Since you can have multiple paths back to a source on a core router, this doesn't work.
If you are using the router as a firewall or a bastion host then this works ok.
Re:This would be easy, really. (Score:1)
The simplest solution would be to drop ALL packets on the local network interface for which the source is NOT in the subnet defined for it. In addition, you would also want/need to drop ALL packets on the WAN interface for which the destination is NOT in the subnet defined for the local network.
I would like my 2610/AS5200 to tell me the originating MAC addy/async interface of that packet. Any ideas?
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);
Re:Lazy or Overworked (Score:1)
For detecting possible security holes Nessus [nessus.org] is a good tool to use, and it can be configured by a cron job to automatically pull down revised scripts. It works in conjunction with nmap. Be warned it can take a long time to run - it took me 20 minutes to scan 127.0.0.1.
The worst thing, though, is to rely 100% on security tools. Tools like Nessus rely upon known exploits. Its the unknown ones that cause the real problems.
It's just a waffer thin mint... (Score:1)
However, in my opinion, there are two real culprits to this problem.
Major router vendors are the primary culprit. This option should be on by default on all routers, and require a configuration change to be turned off. If it isn't turned off then every network you route to the outside world is automatically allowed to pass through. If it is turned off, then you just made a concience decision to run in a less secure environment - possibly a very legitimate decision, possibly not.
The secondary culprit, is the lack of concise and well written AUPs that are truly enforced. Ahhh if only it were legal and enforcable to have an AUP that said simply, "We allow no bullshit. And we decide what the bullshit is." But it isn't so write one that works.
Personally, if I were a DSL/Cable provider just starting up, I'd invest heavily in a bunch of decent NID systems and allow the traffic through. My AUP would state that you pay me first and last months DSL rent regardless of whether you are getting service, if you break my AUP. I'm sure all the mommies and daddies out there would be thrilled to find they have no Internet after the NID system found spoofed packets coming from juniors CPU.
Re:The problem is... (Score:1)
Any user that is spoofing a private network ip is probably smart enough to spoof a legitimate source address and bypass whatever ACL is put in place.
Additionally, processing ACLs is costly to hardware resources and would increase ISP infrastructure costs significantly.
I am not advocating pulling the plug on anyone...
Re:Don't use ACL - sorry, bad mask - try again (Score:1)
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.
Re:Some ISP's _do_ block bad IP addresses in route (Score:1)
By the way, that ISP also blocked outgoing packets (to the Internet) that did not have a source IP address that belonged on its network.
UUNET AUP (Score:1)
http://www.us.uu.net/support/usepolicy/
System and network security
Violations of system or network security are prohibited, and may result in criminal and civil liability. UUNET will investigate incidents involving such violations and may involve and will cooperate with law enforcement if a criminal violation is suspected. Examples of system or network security violations include, without limitation, the following:
.
.
.
Forging of any TCP-IP packet header or any part of the header information in an email or a newsgroup posting.
ISP's DO use such access lists (Score:1)
Hard to do (Score:1)
Let's say a script kiddy uses Nmap with the spoof function turned on. How are you going to stop the randomly choosen IP's from entering the network? It will stop someone using it from within your network (and be a shock to that person when they get caught because only one source IP was getting to their intended target).
One thing that I've always wanted to try was to filter traffic based on the addresses contained in the MAPS-DUL. I've never tried it because of concerns for slowing down the network (it is a long list) and pissing people off. The problem is a number of things would break. Things like ICQ would have to go through the main server. It would break multiplayer Rainbow6, PCAnywhere. or any other program that expects a direct connection with another other home uses to work. This might be fine on a limited basis were you can actively control what gets in and out of your network. But on the scale of ISP's.....
If everyone started filtering traffic from within their network to stop spoofed traffic from getting out, then spoofing throughout the internet would drop. But everyone would have to do it.
And like everything else, someone will find a way around it.....
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>
Re:ipchains/iptables? (Score:2)
Yup, I'm quite impressed.
I run a Dell P-133 machine, using an Allied Telesyn AT-1500 on my local LAN and a generic NE-2000 PCI card on my external connection.
With my DSL setup, I have to run PPPoE, so I've got Roaring Penguin's solution, and a fairly good firewall routine.
When I fire up top and then start downloading big files on any one of my Windows clients, I never show more than about 2% CPU useage on the Dell, and most of that is running top.
I've saturated my 10 Mbps Intranet a few times, mostly parking a few video files on the Linux server, and then playing them from the 4 Windows clients scattered throughout my house. Even so, the Dell never peaked out over 5% CPU useage. As long as I stay away from X, there's loads of power and memory for ipchains to do its thing.
of course I am running nice DEC tulip chips and no icky 3com junk, or realtek crud. It's been a while but I believe I could get around 60mbps, maybe higher, but this was also only from one source to one destination.AT-1500s are bus-mastering ISA cards; I wish I could get two of them to run in that same machine, but I've never been able to get two ISA network adapters to run in Red Hat 6.0. Even though they run fine together under Windows 95, I get an "Ieee! Killing interrupt handler!" message when I try to bring up eth1 with the PPPoE driver.
I like the AT-1500s because they've got great LBL factor. ("LBL" = "Little Blinking LED")
LEDs for Link, Collision, TX and RX. Very pretty when my roommates are online.
Anyone know of any good PCI network cards with lots of LEDs? (Scary that it's a prime purchasing criteria, isn't it?)
Handling the problem at the edges (Score:2)
Even many DSL systems use PPP (wierd, but true; newer consumer DSL is IP over PPP over Ethernet over ATM over DSL.) So similar enforcement is permissable there. If you have several IP addresses on the line, PPP has to know it, though, which currently isn't well-supported. But that's an extra-cost option with most DSL vendors anyway.
PPP is CPU-intensive enough that checking the IP address in the PPP server shouldn't be noticed. It's probably better to handle this before the first router than trying to maintain validity tables in the router. Attackers locked down to a range of IP addresses can still use one belonging to someone else as long as it's in the valid block. So the DoS kiddies can still attack; they just have to change their strategy a bit.
Real LANs with WAN connections are another matter, as are the dumber flavors of cable modems.
Or some companies don't listen to consultants (Score:2)
That's why I won't work for Intel, if they treat consultants that way.
RFC 2267 (Score:2)
Internet/routers (Score:2)
Re:be wary of this kind of thing (Score:2)
Why should you be able to forge packets?
Re:okay then... (Score:2)
Could filter out all ICMP (ping, etc.) packets as part of your firewalling ruleset, but that will have other consequences, since ICMP is important to help negotiate a TCP connection when something goes wacky somewhere.
Just make the firewall ruleset watch for fragmented ICMP packets, as well as misformed ICMP packets (ie. the "ping of death").
A floodping just eats bandwidth, sometimes overloading and crashing routers and stuff along the way. Yank your internet connection to make damned sure this doesn't hit the internet, then from a Linux box, type "ping -f 192.168.x.x &" several times, where the x.x is the rest of the local IP address of a Windows box. Watch your ethernet lights, and the collision light on your hub. When I do this, my Windows 95B box slows right down, but it doesn't crash.
A DoS attack usually involves sending a floodping of malformed or fragmented packets, meaning that the system at the other end either experiences buffer over-runs (which, depending on how well the operating system protects memory, may or may not corrupt something else in RAM) or retries in vain to get the other part of the fragmented packets that the other system is sending.
At some point, the buffers either become full or start to over-write their boundaries. The blue screen of death is only around the corner.
BTW, don't take this as gospel, this is my understanding of what happens from burning the candle at both ends as I learn about network security in preparation for administering a webserver at the office.
Re:With large dialpools, doesn't help much (Score:2)
It barely helps at all. Only anti-spoofing individually allocated connections will eliminate this problem entirely, and in a large-ISP environment of multiple dynamic dialpools, that just has to be integrated into the NAS machinery by default. In practice, nothing else is manageable, and nothing else provides the accountability that is needed for abuse control.
Re:Some ISPs will (Score:2)
(Based on a test where we gave a high-end router a bunch of rules and the difference in ping times through it was 2-3ms. Then assuming 5-6 routers per packet trip, that would be configured in such a way... Usually one per ISP and two per backbone.)
Re:Underpowered routers the problem? (Score:2)
Re:Not as easy as you think (Score:2)
Here's an excerpt from access-list 102, applied for ingress filtering on GigabitEthernet0/0/0 (our incoming interface) on the primary router.
Extended IP access list 102
deny tcp 192.168.0.0 0.0.255.255 any (179 matches)
deny tcp 10.0.0.0 0.255.255.255 any (463 matches)
deny tcp 172.16.0.0 0.15.255.255 any (106 matches)
deny udp 192.168.0.0 0.0.255.255 any (20 matches)
deny udp 10.0.0.0 0.255.255.255 any (22 matches)
deny udp 172.16.0.0 0.15.255.255 any (23 matches)
deny udp 169.254.0.0 0.0.255.255 any (6 matches)
deny icmp 192.168.0.0 0.0.255.255 any (88 matches)
deny icmp 10.0.0.0 0.255.255.255 any (80 matches)
deny icmp 172.16.0.0 0.15.255.255 any (2 matches)
Won't see them? Pfft.
Admittedly, this is the router. Not the firewall. But they DO travel over the public internet.
-j
Re:Firewall (Score:2)
yeah, one of those ;-) the one that is actually shipping oc192 ('c' and non-c) interfaces with fullspeed filtering.
Cisco, on the other hand, have trouble with running wirespeed on all ports whether or not they've got an extra work to do
that's the way I hear it, too. cisco's architecture is way too old to scale to today's core needs. they are still primarily software-based; those other two companies you mention have much more modern system design (which uses hardware as the central element in design; not just for acceleration but as a central design theme; ie, not an afterthought.
I know Cisco's kit better than any of their competitors
get to know their competitors. cisco's arch. is yesterday's news. they still own the enterprise (with atalk, vines, etc, etc) but in the core, they are almost irrelevant compared to today's fast kids on the block.
--
Re:Firewall (Score:2)
Can they function with a huge list, or do they break down quickly when you start adding site specifics?
--
Re:PCI NICs w/ lots of blinky LEDs. (Score:2)
Thank you all for responding to that.
I'll certainly check out those, and the other suggestion for the D-Link DE-530.
Not that this has any sort of real relevant use, but my firewall/proxy has a free 5.25" bay, which I'm going to use to mount a hard disk drive. Since it's a 3.5" drive, I'll be using one of those adaptors, and it's got a faceplate.
I've already laid plans to drill a whole bunch of holes into it and have labelled LEDs for eth0 and eth1. Again, not that it's got any practical use, except that it'll make my gateway look really impressive sitting under my fax machine with a zillion blinking lights on it.