Re: block CodeRed/Nimda at the firewall?

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

Date: Mon, 12 May 2003 11:47:34 +0200

nobodaddy wrote:
>
> 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.

You got a point there. For a nonexisting IP, the host-unreachable will
come not with source IP of the target of the original packet, but rather
the IP of the last router that gave up routing the packet to it's
destination. I don't know if you can somehow make the reject rule reply
with a different source IP.

But in my case, I don't think it would help sending out icmp packets
with source IP of the router outside. My ISP would drop those packets
anyway. However I don't use that rule for incomming packets, it is only
used for outgoing packets which I want to reject in certain cases.

For incomming packets, I only send UDP and TCP packets to the LOGREJECT
chain.

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

Yeah, that is probably the most interesting use of host-unreachable.

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

That does make sense. I drop some of those early in my INPUT chain.
Though I only DROP them in case the source address is from a one of
the subnets I use locally.

My ISP uses class A RFC1918 addresses for some routers and DHCP
servers. My cable modem uses class C RFC1918 addresses. So I decided
to use class B RFC1918 addresses for my localnet. Here is my INPUT
chain:

-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 -j LOGDROP
-A INPUT -d 127.0.0.0/8 -j LOGDROP
-A INPUT -i eth0 -j ACCEPT
-A INPUT -s 172.16.0.0/12 -j LOGDROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -j TCPINPUT
-A INPUT -p udp -j UDPINPUT
-A INPUT -m limit --limit 79/minute --limit-burst 4 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 192.168.100.1 -d 224.0.0.1 -j DROP
-A INPUT -j LOGDROP

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

Interesting, but that doesn't explain why I only see that behaviour
with connection attempts on port 12345 and 27374. On all other ports it
does not happen. 

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

  • 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: IPTABLES configuration [help]
    ... INPUT allow related and established packets and ping packets. ... Delegate TCP and UDP to seperate chains. ... doesn't allow any UDP packets through to the ports. ... LOGDROP just LOG and DROP packets, ...
    (comp.os.linux.security)
  • 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)