syn flood control, and other tcp/ip stack security features
MMS26
folks,
this is probably going to come across as rather random by i am
evaluating openbsd as a pltform for doing some rather specific
and dedicated security type things. i am also coming from a heavily
bsdi influenced background so some rather weak analogies are being
drawn on my part. on an advocacy note, for whatever that is worth,
i am strongly urging an obsd solution to these particular problems...
syn flood defence:
going through the cvs log info i noticed that TCPCOOKIES support
has been yanked. however, i couldnt find any mention of any alternative
being included ( eg. IOS style tcp intercept, or bsdi style syncache
- i think its fairly similar to what exists under netbsd ). is there any
and if so is there a mechanism for configuring it runtime ( eg. sysctl
mib style values, etc. ) or is a recompile necessary?
spoofed source address detection/prevention:
is there anything similar to ip source checking ala:
"A route to the source of these packets must exist, and they must have
arrived on the interface specified in this route. Packets that do
not meet this criterion will be discarded."
fragmentation attack defenses:
i know obsd ships with ipfilter ( so many excellent things in one place ),
but was wondering if there is any rfc1858 style defense other than a
"block all short/frag" style rule? if so can this be tweaked runtime?
path mtu:
similar to the above, is there any method for disabling path mtu and
hardwiring a mss runtime?
thanks,
MMS26
Theo de Raadt
> has been yanked.
tcp cookies do not work. there are two models.
one model assumes that a syn packet can be sent in the opposite
direction -- the answering of this syn packet indicates the existance
of the other endpoint, and thus permits the connection to go on. that
is the code that was deleted. it is obvious that in a modern
more-filtered world it cannot work.
the other model is what linux does. basically it sends the syn, and
forgets about the existing syn, to save space. if i recall things
correctly, this actually means that linux believes the ip options in
the first post-syn packet. that's not really conforming.
> however, i couldnt find any mention of any alternative
> being included ( eg. IOS style tcp intercept, or bsdi style syncache
> - i think its fairly similar to what exists under netbsd ). is there any
> and if so is there a mechanism for configuring it runtime ( eg. sysctl
> mib style values, etc. ) or is a recompile necessary?
we have a random/tail drop algorithm for dropping excessive syns,
which seems to work pretty acceptably. we also have various values
which can be tweaked to change maximum queue lengths. unfortunately
our code still generates a large data structure when the first syn
is received.
> spoofed source address detection/prevention:
>
> is there anything similar to ip source checking ala:
>
> "A route to the source of these packets must exist, and they must have
> arrived on the interface specified in this route. Packets that do
> not meet this criterion will be discarded."
we have nothing like that. i do not see the purpose.
> fragmentation attack defenses:
>
> i know obsd ships with ipfilter ( so many excellent things in one place ),
> but was wondering if there is any rfc1858 style defense other than a
> "block all short/frag" style rule? if so can this be tweaked runtime?
no idea.
> path mtu:
>
> similar to the above, is there any method for disabling path mtu and
> hardwiring a mss runtime?
path mtu is disabled by default -- we do not have any such code. path
mtu is just so subvertable. however, we will eventually have to
impliment some really paranoid path mtu code.
Ian Darwin
> "A route to the source of these packets must exist, and they must have
> arrived on the interface specified in this route. Packets that do
> not meet this criterion will be discarded."
Vaguely similar, not requiring the route to exist, but considerably
more flexible: ipf.8. The example files for ipfilter (which you mentioned)
say this (in /usr/share/ipf/firewall.1) and much more besides:
# Block any inherently bad packets coming in from the outside world.
# These include ICMP redirect packets and IP fragments so short the
# filtering rules won't be able to examine the whole UDP/TCP header.
#
block in log quick on ppp0 proto icmp from any to any icmp-type redir
block in log quick on ppp0 proto tcp/udp all with short
#
# Block any IP spoofing atempts. (Packets "from" our network
# shouldn't be coming in from outside).
#
block in log quick on ppp0 from 192.168.4.0/24 to any
block in log quick on ppp0 from localhost to any
block in log quick on ppp0 from 0.0.0.0/32 to any
block in log quick on ppp0 from 255.255.255.255/32 to any
(Of course ppp0 is your outside, and the 192.168.4 is your inside IP netaddr).
Ian
Michael Shalayeff
this example, but i see no reason not to block 'em
cu
--
paranoic mickey (my employers have changed but, the name has remained)