more ICMP packets than http packets

Likely Nachi (as suggested above).

Do *not* encourage worm writers to envolve their code by simply blocking ICMP (as my retarded provider has done).  

I admit, chicagoan has a point

>By far zombies will be respnsible for this traffic, along with a few script kiddies, and here is the problem.
>ISP's generally don't devote many resources to tracking down this traffic. They don't want to summarily disconnect
>somone and don't have the ability to call everyone with code red or blaster and help them fix it

In my opinion this is a problem with policy.  As an ISP, you have to make the tough decision to disconnect abusive users/networks, and allocate resources to determine who those abusive sites actually are.  I used to work for an ISP, and I know there is always pressure from management asswipes to just make the customer happy, even though you generally wind up fixing problems that are not local to you as an ISP.  If management can wrap their (usually) pea-sized brains around the concept that you might be able to sell *additional* consulting services by offering to fix customer's networks for a fee, you might be able to find a reasonable way out of this painful situation.

Things like this are a good idea:

>Implement  Unicast Reverse Packet Forwarding on all routers. This feature makes sure packets entering an interface pass
>a sanity check to make sure the packet should’ve come in the interface it did based on the packets source and destination
>address and the routers routing information.

The above advice is generally recognized as good networking practice, and helps maintain the health of your network through times of abuse.

Things like this are not:

>Disabling ICMP Redirects
>Disable ICMP-Directed Broadcasts
>Disable ICMP MAsk Replys
>Disabling ICMP Unreachables

ICMP functionality exists for a reason - blindly disabling much of ICMP does nothing but degrade the existing functionality of the network, and encourages worm writers to use another method of reachability/connectivity probing.  Next you'll be telling me to disable SYN/ACK (or maybe SYN) - hey, I'm sure we can get by with UDP workarounds and kludges!

In other words fix the network (disconnect the sickness), rather than breaking the network (in order to produce newer and better sicknesses).

I guarantee my retarded provider will get hit again and again by nastier and nastier malware until such point as they insist on breaking their network so much that it is unusable to me and I have to find another provider (in fact, if I didn't have administrative access to plenty of out-of-network hosts, I'd have dropped them already).  On the other hand, several major universities who have a clue about IT simply isolate and disconnect the source of bad traffic - one you have an automated mechanism in place for identifying and quarantining infected hosts, all that ever needs tweaking is the detection parameters - trying getting the retards in management to understand that is another issue altogether.

Cheers,
-Jon

Is there any legitimate use for directed broadcasts other than enumerating hosts?
I'd be hard pressed to pull that from the standard filter, the potential for abuse is too high.
 IMHO

>Is there any legitimate use for directed broadcasts other than enumerating hosts?

Good call - I overlooked that one above.  I think the general consensus is that no, directed broadcasts don't really serve much useful purpose (especially since many Mickeysoft IP stacks violate the RFC out of the box and don't respond anyway).

Mask replies are probably also safe to block, unless you have some hosts running older remote boot code...  Still, I imagine that a better practice would simply be to restrict them to the local network rather than a complete block.

Redirects seem fairly harmess if kept within the local network (I'm not sure blocking them altogether is a good idea - blocking can make it kind of pesky to reconfigure the network (at least until all those damned DHCP leases expire))

Blocking unreachables (aside from the sanity checks previously mentioned) is simply unforgiveable - aside from adding unnecessary delays to clients attempting to access unreachable hosts, it breaks ping and traceroute feedback (What do all those asterisks mean?  I know what they *used to* mean...)

I apologize - In my tired state (and since my provider is currently doing this) I also thought ICMP echo/reply was in there - I'm glad it's not, since blocking that is simply moronic.

Merry Xmas!
-Jon

My reasoning:

ICMP Redirects: Disabling this will prevent an attacker from redirecting all or part of our network traffic to another destination

ICMP-Directed Broadcasts: Disabling this will stop an attacker from sending an ICMP echo request to an entire network. Thus, limiting any type of discovery.

ICMP Mask Reply: Disabling this will prevent an attacker from mapping out the configuration of our network and routers.

ICMP Unreachables: Disabling this will prevent some scanning methods from obtaining information about open and closed ports

In the begining, when one set up sendmail, it was expected that anyone might use your mail relay, and there was probably anonymous ftp on the same machine. There was an openness and spirit of sharing and cooperation that quickly showed itself to be naivete.

I find it frustrating when I can't traceroute or ping a host when trying to troubleshoot a problem but I also understand the costs of giving script kiddies a target rich environment.
I've read a lot of GIAC practicals over the years and filtering lists have slowly grown to the point where edge routers are virtual black holes, which I think is appropriate for customers, but cripples some important diagnostics when IPS's start to drop these packets on transit routers (and would tick me off as a customer).

I know ISP's are in competition with each other and they're in business to make money, but I think there is a responsibility that goes beyond being purely reactive and as Jon pointed out there may well be a marketing opportunity for consulting in taking a more holistic approach to the problem.

I don't think the filtering approach is 'solving' the problem. I think rate limiting technologies like pacemaker and/or adding a unit dedicated to detecting hostile or abusive activity (and responding to complaints) and communicating with customers is a lot more forward looking.

>ICMP Redirects: Disabling this will prevent an attacker from redirecting all or part of our network traffic to another
>destination

My only concern is that this limits future network flexibility - restricting redirects to within the local net should prevent most attacks, but still maintain the functionality.

>ICMP-Directed Broadcasts: Disabling this will stop an attacker from sending an ICMP echo request to an entire network.
>Thus, limiting any type of discovery.

Not to mention those nasty DDoS ping storms - no argument on this one.

>ICMP Mask Reply: Disabling this will prevent an attacker from mapping out the configuration of our network and routers.

I thought the main concern here was with a DoS attack - network configs can be mapped fairly decently with enough traceroutes (and tcptraceroutes)

>ICMP Unreachables: Disabling this will prevent some scanning methods from obtaining information about open and
>closed ports

That's what an IDS is for - unreachables are very helpful in diagnosing network problems - blocking unreachables means (amongst other things) that it is not possible to determine who to hassle when a particular service (or server) dies (do I call the NOC, or the server admin?).  A properly configured IDS (can you say portsentry?) will block folks who are scanning, but send unreachables back to folks that are not acting maliciously.

I agree customer/edge routers should be configured as anally as possible - however, as chicagoan points out, ISP routers need to be configured with a more delicate touch.

Cheers,
-Jon

I agree, a delicate touch is necessary. And I have to say my perspective is skewed, as I have done configs on edge routers, never an ISPs routers.