Re: Firewall stateful handling of ICMP packets
Personal view: This was a problem when filtering Nachi while it pinged networks to their knees. Sometimes I wonder if there is any legitimate reason to allow pings from users at all. If the user really needed to use ping, that is, if they were in a position to do anything about the results of the ping tests, then they would know enough to use traceroute in UDP mode or some other tool. There are lots of other useful ICMP types to handle all the other ICMP needs, but ping seems to be something that was created for the convenience of a kind of user that is effectively extinct in todays Internet. ICMP echo is unique among ICMP types in that it is the only one that elicits it's own response. What I mean by this is that source-quench, <foo>-unreachables, and others are all generated by hosts and routers in response to relatively stateful traffic. There is nothing that echos do that SNMP (I know, I know) and traceroute don't accomplish in a more controlled fashion, no? It would kill alot of DDoS attacks and render their zombie networks useless, retire legacy backdoors and viruses, up the ante for network management tools, and slow down some virus propagation substantially. ICMP echos are a bit of a hack and, quite literally, noise, and I wonder if it may be time to consider unofficially retiring them using filters. -- Jamie.Reid, CISSP, jamie.reid@mbs.gov.on.ca Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324
"Sean Donelan" <sean@donelan.com> 12/03/03 05:12pm >>>
You could drop ICMP packets at your firewall if the firewalls properly implemented stateful inspection of ICMP packets. The problem is few firewalls include ICMP responses in their statefull analysis. So you are left with two bad choices, permit "all" ICMP packets or deny "all" ICMP packets.
Jamie Reid wrote:
Personal view:
This was a problem when filtering Nachi while it pinged networks to their knees.
Well, it was at least the "last straw".
Sometimes I wonder if there is any legitimate reason to allow pings from users at all. If the user really needed to use ping, that is, if they were in a position to do anything about the results of the ping tests, then they would know enough to use traceroute in UDP mode or some other tool.
Personally, I like Rob Thomas (cymru) stance on ICMP filtering as given in http://www.cymru.com/Documents/icmp-messages.html. This allows pings and PMTU-relevant unreachables. Granted there have been a few hacker toys that use ICMP echo-reply or other esoteric ICMP type codes to communicate with their "slaves", but this could be alleviated to some extent with "stateful" ICMP (almost an oxymoron). The Nachi pings can be stopped by vendor C using policy routing but has a side effect of grabbing some unintended packets (Windows traceroute, I think). If you can devise a method to see if the ICMP payload is a load of 0xaa's then you've narrowed it down to a science, but AFAIK vendor C can't do that (well, maybe an IDS appliance with a custom signature). You can gain "some" additional protection by rate-limiting ICMP (in the Nachi ping case) and/or UDP (SQL Slammer, etc), and TCP intercept for synflooding. Not perfect, but every little bit helps. Jeff Kell University of Tennessee at Chattanooga
Jamie Reid wrote:
Personal view:
This was a problem when filtering Nachi while it pinged networks to their knees.
Sometimes I wonder if there is any legitimate reason to allow pings from users at all
ICMP echos are a bit of a hack and, quite literally, noise, and I wonder if it may be time to consider unofficially retiring them using filters.
If every ISP rate limited icmp's on ingress (from customers and net) to some reasonable rate (I use 2Mbps), then you protect the net from attack impacts, have no impact on customers during normal times, and break nothing essential during times of attack (as opposed to, say, SYN rate limiting, which just lowers the bar for an attacker.) Of course, this assumes that the equipment can do such policing in hardware, or with negligible impact... Totally filtering ICMP echoes would raise lots of user hackles...
The problem with ICMP is that it is ICMP today. What will it be tomorrow? It'll aways be putting out fires, controlling packet floods matching whatever signature. One solution is to get away from unlimited bandwidth. Once there is a cost associated to having a PC source Nachi or Welchi traffic, customers will learn to be more concerned and educate themselves. The cost doesn't have to be moneytary. Progressive rate limiting could be used, where traffic gets pinched as the allowed traffic per time slot is consumed. Adi
On 3 Dec 2003, at 22:53, Adi Linden wrote:
One solution is to get away from unlimited bandwidth. Once there is a cost associated to having a PC source Nachi or Welchi traffic, customers will learn to be more concerned and educate themselves. The cost doesn't have to be moneytary. Progressive rate limiting could be used, where traffic gets pinched as the allowed traffic per time slot is consumed.
Live example of how well monetary pinching works in New Zealand -- there have been cases of people receiving $15,000 monthly phone bills which are mainly comprised of ADSL traffic charges. So, the traffic charges stop the rogue traffic, by sending customers bankrupt, but only about a month or so after the fact. Punishing high-traffic users by progressive traffic shaping sounds more effective, although the implementation sounds potentially hairy. Joe
On Wed, 3 Dec 2003, Joe Abley wrote:
Live example of how well monetary pinching works in New Zealand -- there have been cases of people receiving $15,000 monthly phone bills which are mainly comprised of ADSL traffic charges. So, the traffic charges stop the rogue traffic, by sending customers bankrupt, but only about a month or so after the fact.
Did news stories about this get other people in New Zealand to fix their computers, apply patches, use anti-virus? Or were were lots of stories about the "evil" telco ruining grandmothers and orphans? and the telco eventually waived the charges? Toll charges do encourage PBX owners and cordless phone makers to improve the security of their products? Most cordless phones (unlike WiFi) now have automatic authentication between the handset and base (not encryption, just authentication). Most PBX's block outside to outside phone connections (the telephone version of proxy/relay) by default now. If ISPs charged customers $0.000001/email message, would it cure spam or would the spammers just continue to use third-party victims to spam and there would be lots of news stories about grandmothers and orphans getting huge ISP bills? IANAL, but many spammers are already breaking a law by using victim machines without authorization; but would law enforcement be more likely to do something if the victims now had a $50,000 bill from their ISP due to the unauthorized traffic?
On 4 Dec 2003, at 11:02, Sean Donelan wrote:
Toll charges do encourage PBX owners and cordless phone makers to improve the security of their products?
I think exploits on PBXes which result in multi-thousand dollar fradulent toll charges being racked up are so common as to not even be newsworthy. Joe
If ISPs charged customers $0.000001/email message, would it cure spam or would the spammers just continue to use third-party victims to spam and there would be lots of news stories about grandmothers and orphans getting huge ISP bills? IANAL, but many spammers are already breaking a law by using victim machines without authorization; but would law enforcement be more likely to do something if the victims now had a $50,000 bill from their ISP due to the unauthorized traffic?
There will always be crooks and victims. But if becoming a victim actually has real world consequences it is much more likely that people will try not to become a victim. I am not talking about sending bills for some outrageous amount due to excess bandwidth used. Instead cut off when a certain bandwidth threshold has been exceeded. If the bandwidth was used purposely and legitametly, buy more bandwidth, otherwise fix your PC. Adi
All, I'm in the process of morphing my company into generalized corporate email outsource agency. The sales pitch: the average (1000+ user) company is finding it difficult-to-impossible to run their own email server. Just do away with the problem, and give it to me. The last couple of months in particular have been total hell. Spam-producing worms have been enabling individual spammers to leverage 10,000 unwitting DSL/cable users to cream my servers. In coming up with the business plan, I'm betting on this being a universal problem. To that end, I'd like to hear about people's experiences. I'm particularly interested in a couple of results: 1) Is my experience common? That is, do others find it excruciatingly painful just to operate a simple corporate email server? 2) What's working for people who are trying to address spam (and other problems, like email-borne virii, SMTP exploit scans, etc)? As I develop the business, I'm going to have to come up with a way to solve this problem. I'm thinking that I'll have to sign one or more partner companies that specialize in spam protection. I'd love to find a company that was down-to-earth and honest. And, especially, a company that is not investor-driven. If anyone has recommendations, please let me know. I've been following the spam threads over the past couple of months, but I haven't been able to distill solid recommendations out of them. If I end up with private responses, I'll summarize back to the list. Thanks, Doug
Adi Linden wrote:
I am not talking about sending bills for some outrageous amount due to excess bandwidth used. Instead cut off when a certain bandwidth threshold has been exceeded. If the bandwidth was used purposely and legitametly, buy more bandwidth, otherwise fix your PC.
This only works if the guy next door is not selling UNLIMITED 512kbps connection for the same amount of $$ than your limited one. (assuming you would actually be telling your customers about it, if you wouldn´t then they would not fix their PCs) According to my experience, annoyance (slower speed) is not enough to make Joe User to do things immediately. Only when you severely limit the utility of a connection, they´ll start doing the right things. Pete
On Wed, 2003-12-03 at 22:09, Jamie Reid wrote:
This was a problem when filtering Nachi while it pinged networks to their knees.
I think the problem was exasperated by the fact that some ISP's responded by blocking _all_ ICMP. Its bad enough that this killed their own ability to see if their hardware was up or down, it also amplified traffic as ICMP errors were no longer returned (due to retransmits and now being prime address space for spoofing).
Sometimes I wonder if there is any legitimate reason to allow pings from users at all.
This all comes down to the SLA. For home users, you can probably get away with it. For business level connections, "not knowing" and killing the service can have financial repercussions. Of course we're talking about addressing a symptom, not a problem. The "problem" is not ICMP Type 8's, the problem is systems that are unprotected and users that can't figure out when the box has been whacked. Personally, I was bummed that my all Linux/BSD network could not use Type 8's because my upstream was filtering them due to Windows boxes getting whacked with Nachi. A couple of other people mentioned rate limiting. That is probably the best option. Of course supporting it can drive up hardware costs.
If the user really needed to use ping, that is, if they were in a position to do anything about the results of the ping tests, then they would know enough to use traceroute in UDP mode or some other tool.
Could be UDP is blocked while type 8's are not. Could be they are on a Windows box which uses type 8's for tracing rather than UDP.
There are lots of other useful ICMP types to handle all the other ICMP needs, but ping seems to be something that was created for the convenience of a kind of user that is effectively extinct in todays Internet.
There are a *ton* of companies out there that monitor system up status via Type 8's over the Internet. I'm not saying its a good idea or that there are not other options. Just that it would break a ton of business models if it goes away.
ICMP echo is unique among ICMP types in that it is the only one that elicits it's own response.
What about subnet mask request? time stamp request? Information request? There are probably others as well.
There is nothing that echos do that SNMP (I know, I know) and traceroute don't accomplish in a more controlled fashion, no?
EEEK! SNMP opens up a point of accessing code running on the device. As for traceroute, if all I'm interested in is the endpoint, I've generated a ton of unnecessarily traffic. Given an average 15 hop distance between Internet hosts, that would be 90 traceroute packets to do the job, Vs. Ping only needing 2. Sure I can tweak the start and stop hop count (actually Windows does not let you set the min starting hop) to drop this quantity, but how many users are going to bother?
It would kill alot of DDoS attacks and render their zombie networks useless,
I seem to remember we said the same thing about killing Smurf amplifier networks. The black hats just changed tactics and started whacking a ton of hosts. Killing Type 8's will not cure "the problem", as the problem is totally capable of mutating into something that will still be effective (like SYN flooding). HTH, C
participants (9)
-
Adi Linden -
Chris Brenton -
Doug Luce -
Jamie Reid -
Jeff Kell -
Joe Abley -
Petri Helenius -
Sean Donelan -
Steve Francis