Re: block CodeRed/Nimda at the firewall?

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 05/11/03


Date: Sun, 11 May 2003 09:48:18 +0200

nobodaddy wrote:
>
> (NB it's not clear to _me_ that DROP is necessarily less
> bandwidth-intensive, seems it mostly saves some upstream at the price of
> some downstream)

I agree with that.

>
> Which packets (if any) _would_ you DROP? When would you use "reject-with
> [type]"? Which types?

tcp-reset -- My rules looks like this:

-A LOGDROP -m limit --limit 1/minute --limit-burst 42 -j LOG --log-prefix "iptables DROP: "
-A LOGDROP -j DROP

-A LOGREJECT -m limit --limit 1/minute --limit-burst 42 -j LOG --log-prefix "iptables REJECT: "
-A LOGREJECT -p tcp -j REJECT --reject-with tcp-reset
-A LOGREJECT -p udp -j REJECT --reject-with icmp-port-unreachable
-A LOGREJECT -j REJECT --reject-with icmp-host-unreachable

-A SLOWLOGREJECT -m limit --limit 15/minute --limit-burst 10 -j LOGREJECT
-A SLOWLOGREJECT -j LOGDROP

-A LOGACCEPT -j LOG --log-prefix "iptables ACCEPT: "
-A LOGACCEPT -j ACCEPT

>
> Wouldn't the approach vary between a private home box on dialup or DHCP,
> and a network running public services?
>
> Perhaps this is a good characterization of the issue (?):
>
> http://www.ale.org/archive/ale/ale-2002-04/msg00076.html
> <quote>
> Typically, you want to reject a packet that you received because it was
> an honest mistake by the sender. You want to drop a packet, because it
> was sent by someone attempting something malicious and you don't want to
> provide them any insight into your network protection scenario. The big
> question is, how do you tell the difference? :)
> </quote>
>
> I can't seem to find anything definitive on this other than the two threads
> alluded to, just little tidbits (like REJECTing AUTH requests on port 113).
> A good link would be appreciated (as would thoughts, comments, etc). This
> has been bugging me for awhile.

In the particular case we are talking about a worm which does not
clearly fit into one of the two described scenarios. Expect the
owner of the source box to be clueless, whatever answer you send
he doesn't learn anything. If would be perfect if you could send
an answer that would make him realize the box was compromised, but
I don't know what answer that would be. So the purpose really is
just to decrease the amount of your own resources being used, and
secondly to increase the amount of his resources being used. Not
that I see why anybody would have a problem with resources being
used by Nimda/CodeRed attacks, they are frequent, but not that
frequent.

As for the question about when to REJECT and when not to, I say
REJECT except in the very few cases where you can document a
reason not to. I have a few ports where I DROP instead of using
REJECT because my logs revealed that the RST packets was ignored,
and the SYN was retransmitted anyway.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);


Relevant Pages

  • Access-lists vs null routes for BOGONs
    ... I've implemented BOGON filtering in access-lists for years along side ... moving my BOGON filtering to null routes to save resources. ... a packet than it would to match it against an ACL. ...
    (comp.dcom.sys.cisco)
  • Re: NDIS Passthru, hold back a packet
    ... >> Then, after copying the original packet to your local packet, ... >> immediately complete the original packet back to NDIS. ... you must never free any resources passed to your NDIS driver. ...
    (microsoft.public.development.device.drivers)