Re: IPF question

[Rémi Guyomarch <rguyom_(_at_)_321_(_dot_)_net>]

On Mon, Oct 30, 2000 at 12:14:01PM +0800, mimic_(_at_)_dvorak wrote:
> Hi,  does anybody can recommend a good set of rules to block TCP SYN flood
> attacks on OpenBSD IPF?  I have append a few lines that were logged by
> ipmon, I would like to knows what that means and how to defend my machine
> form such attacks.  Thanks folks.

None of those logs looks like SYN floods.
And I don't know a way to stop SYN floods automatically. Once you got
the IP / range of IPs flooding you, add a line "block in quick proto
tcp from <bad_guy> to you port = <bla> flags S/SA" and you should be fine.

(I sanitized a bit your logs)
> 13:06:08.963843 xl0 @0:2 b 202.156.29.146 -> 202.156.1.22
> PR icmp len 20 56 icmp 3/3 for
> 202.156.1.22,53 - 202.156.29.146,2905 PR udp len 20 13056 OUT

> 13:06:12.935563 xl0 @0:2 b 202.156.29.146 -> 202.156.1.21
> PR icmp len 20 56 icmp 3/3 for
> 202.156.1.21,53 - 202.156.29.146,21876 PR udp len 20 13056 OUT

> 13:06:13.965626 xl0 @0:2 b 202.156.29.146 -> 202.156.1.22
> PR icmp len 20 56 icmp 3/3 for
> 202.156.1.22,53 - 202.156.29.146,42218 PR udp len 20 13056 OUT

Those logs represent blocked outbound icmps 'port-unreachable'.
Someone on your internal net (202.156.29.146) is trying to ask
something to two nameservers, but :
- the reply from the nameservers came too late, the internal client
already gave up and sent back a 'port unreachable' to the nameservers.
- and your ipfilter doesn't process icmps properly and reject them
even if you have 'keep state', or you didn't use 'keep state' on the
corresponding outbound rule.

> 14:09:17.314436 xl0 @0:2 b 157.130.5.54 -> 202.156.29.146
> PR icmp len 20 56 icmp 3/1 for
> 202.156.29.146,27531 - 205.228.29.126,33119 PR tcp len 20 10240 IN

ms-gw.customer.ALTER.NET is trying to inform 202.156.29.146 that the
host 205.228.29.126 is unreachable (icmp 3/1 == host unreachable).
ms-gw.customer.ALTER.NET thinks that 202.156.29.146 tried to connect
or send something to 205.228.29.126 on port 33119/tcp. This may be
someone trying to hack 205.228.29.126, spoofing his real IP as yours.
Or this may be completely bogus, since it seems a bit strange for
ms-gw.customer.ALTER.NET to route something for NETBLK-MSTAN128,
Morgan Stanley & Co. Inc.

> 14:09:17.416277 xl0 @0:2 b 172.25.80.182 -> 202.156.29.146
> PR icmp len 20 56 icmp 11/0 for
> 202.156.29.146,19185 - 151.132.73.91,54177 PR tcp len 20 10240 IN

icmp 11/0 == time exceeded / Time to Live exceeded in Transit
172.25.80.182 (yuck, private address space) is trying to inform
202.156.29.146 that it failed to transmit something to 151.132.73.91
on port 54177/tcp. It's probably a badly configured router (because of
the RFC1918 address) and your packet got caught in a routing loop (TTL
exceeded).
Your filter rejected this icmp, either because :
- the client timed-out waiting for an answer from 151.132.73.91,
closed its side of the socket, ipfilter then deleted its state and
later refused the icmp because it wasn't part of an established (and
now closed) session.
- the icmp is totally bogus

> 14:09:18.1843569 xl0 @0:2 b 202.95.96.49 -> 202.156.29.146
> PR icmp len 20 56 icmp 3/1 for
> 202.156.29.146,11381 - 171.196.69.87,5402 PR tcp len 20 10240 IN

Same thing, but the error came from 202.95.96.49 and you tried to send
something to 171.196.69.87 on port 5402/tcp.

> 14:09:18.2030837 3x xl0 @0:2 b 55.54.2.3 -> 202.156.29.146
> PR icmp len 20 56 icmp 5/1 for
> 202.156.29.146,64168 - 132.130.69.26,45322 PR tcp len 20 10240 IN

A bit more interesting. The host 55.54.2.3 (NET-RCAS2, Army National
Guard Bureau) warns you that it isn't the right router for the host
132.130.69.26 (NETBLK-NG-CONC5, Army National Guard Bureau) and send
you a packet which should contain the right router to send something
to 132.130.69.26. The packet which triggered the error was something
you tried to send to 132.130.69.26 on port 45322/tcp.
This ICMP was rejected because :
- your internal host 202.156.29.146 didn't tried to communicate from
port 64168 to 132.130.69.26 on port 45322/tcp for the last 5 days or
closed its side of the socket a bit early.
- it's completely bogus you can't be sure that an ICMP is comming from
the host it claims to come from.
- the 'keep state' ipfilter code specifically doesn't let
icmp-redirects pass through an established 'state', since someone can
do weird and bad things with spoofed icmp-redirect aimed at you.

-- 
Rémi