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.

TEXT.htm (3.59 KB)

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 ICMP Packet Filtering v1.2. 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

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

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

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?

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