DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:
> On 2006-01-09, integer <can2two@hotmail.com> wrote:
>> 1. The first one is to prevent users from seeing information about
>> processes that are being run under another UID.
>
> The simple answer might be to generate a list of commands that reveal PID
> information and restrict them to the root user, also changing the name
> of root to something else so it's non-obvious which login account may get
> you root access. This will not prevent savvy coders from writing their
> own code, but that also assumes that there will be live users logging into
> the box.

It does also not present anyone with half a clue from getting src.tar.gz
and compiling them by hand. I.e., only the worst script kiddies will
actually be stopped by this if they do not wish to be.

(And while cutting down on access to prevent file copying is annoying,
it's just a little scripting challenge to anything with a bit of a
clue.)

<snip>
>> 3. Generate a random ID for the IP packets as opposed to incrementing
>> them by one. This will prevent remote observers from determining the
>> rate packets are being generated by watching the counter.
>
> OpenBSD also does this natively with PF, using the directive to scrub
> packets to "normalize them", which looks like "scrub in on $interface
> random-id <other directive> <other directive>", etc.

I'm not certain how to interpret this, but for OpenBSD generated packets
pf(4) is not necessary:

See http://www.cert.org/advisories/CA-2001-09.html - OpenBSD randomizes
pretty well by default. (In fact, I'd think modulate state would produce
pretty much the same as just the default.)

Also note that in pf.conf(5), under 'STATE MODULATION', 'some popular
stack implementations' are criticized for exactly this failing, which
strongly suggests OpenBSD does it right.

However, when acting as a firewall, modulate state'ing forwarded traffic
is a good idea.

<snip>
>> 5. Drop SYN/FIN packets
>
> A little too general for me to answer, I'm guessing you mean you want
> to filter out TCP SYN "half-opens" to defend against DDOS and perhaps
> aggressively close open sockets? PF will do all these things. PF has
> a feature called SYN-Proxy, similar to the "SYN-Cookie" concept, that
> makes sure the TCP 3-way handshake completes before passing the socket
> connection to the real host. There are also features to tweak and tune
> the closing of sockets / how long a closing FIN is waited for, etc.

People who ask this question tend to be very happy when told that
OpenBSD can block nmap (via pf's 'OS detection').

>> 6. Enable stealth forwarding. Stealth forwarding passes packets
>> without touching the TTL, so this is useful for hiding firewalls from
>> traceroutes.
>
> I'd debate with you the viability and usefulness of this feature.

I agree with you here; reasons (pretty much the same as yours) upthread.

Joachim