Re: block CodeRed/Nimda at the firewall?

From: nobodaddy (nobodaddyNO_at_SPAMinbox.lv)
Date: 05/11/03 

Date: Sun, 11 May 2003 18:29:58 GMT

Thanks for the meticulous reply.

Kasper Dupont wrote:

> nobodaddy wrote:
<snip>
>> Which packets (if any) _would_ you DROP? When would you use "reject-with
>> [type]"? Which types?
>
> tcp-reset -- My rules looks like this:
<snip, thnx!>

This is the RFC compliant behavior, right? Per

http://www.faqs.org/rfcs/bcp/bcp60.html

<quote>
TCP uses the RST (Reset) bit in the TCP header to reset a TCP
connection. Resets are appropriately sent in response to a
connection request to a nonexistent connection, for example. The TCP
receiver of the reset aborts the TCP connection, and notifies the
application [RFC793, RFC1122, Ste94].
</quote>

I note that the default iptables REJECT behavior is "icmp-port-unreachable".

At this point I'm wondering how stealthy "DROP" really is. Consider, what
exactly is the behavior when attempting to connect to a non-existent IP
address? Eventually the packet finds its way to the owner of the netblock;
then what? The server returns "host unreachable" (or "net unreachable").
Right? So a really sharp blackhat could take his packets drop off into the
void as a sign in itself. Of course, very few crackers have that much of a
clue.

Seems to me at this point that the stealthiest response would be
"--reject-with icmp-host-unreachable", which in your rulset is the the last
rule in your LOGREJECT chain, applied to icmp traffic (or anything else
that gets that far):

-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

>> Wouldn't the approach vary between a private home box on dialup or DHCP,
>> and a network running public services?

Simply REJECTing with "host-unreachable" seems attractive at first glance
for the home box; but silly, as my IP will be rcvd by the bad guy anyway!
And totally non-RFC-compliant, to boot.

Seems "host-unreachable" would really only be appropriate for a standalone
firewall on a public net doing NAT, to protect the "inner sanctum".

<snip>
> 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

As D Stussy mentioned, DROPing packets that are addressed to reserved
netblocks (10.0.0.0/8, etc) seems to make sense.

> 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.

Maybe because

http://www.faqs.org/rfcs/bcp/bcp60.html
<quote>
2.3. Sending Resets as a Congestion Control Mechanism

                       ...Possibly in response to the use of resets as
   a congestion control mechanism, several popular TCP implementations
   immediately resend a SYN packet in response to a reset, up to four
   times.
</quote>

Thanks again. 

-- 
The other day a dog peed on me.  A bad sign.
- H.L. Mencken

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues
    ... I'll be able to run some more basic tests tomorrow to see some results, but want to wrap my head around what's actually logically meant to be happening based on adjustments, etc. [I suspect this'll do nothing for the UDP issue, but at least I might be able to pipe some TCP traffic] ... Little packets with ip lengths of 28-29 bytes seem to do the most damage. ... UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). ...
    (freebsd-performance)
  • tcp hostcache and ip fastforward for review
    ... this patch contains three things (to be separated for committing): ... - removes ip route cache in ip_input.c (locking much easier) ... - removes most (tcp specific) metrics from rtentry metrics ... - fixes wrong goto in tcp_input.c which sends two RST packets ...
    (freebsd-current)