SEO

1. The first one is to prevent users from seeing information about
processes that are being run under another UID.

2. Enable the concept of blackholing. This is so RST packets don't
get sent back in response to closed ports. This helps to block port
scans.

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.

4. Disabling ctrl+alt+del so somebody can't walk up to your box and
reboot the server.

5. Drop SYN/FIN packets

6. Enable stealth forwarding. Stealth forwarding passes packets
without touching the TTL, so this is useful for hiding firewalls from
traceroutes.

> 1. The first one is to prevent users from seeing information about
> processes that are being run under another UID.

You can modify ps, top source code. Of course is not a perfect
solution.

> 2. Enable the concept of blackholing. This is so RST packets don't
> get sent back in response to closed ports. This helps to block port
> scans.

You can use pf to make this.

> 3. Generate a random ID for the IP packets as opposed to incrementing
> them by one.

Ehm , I think that OpenBSD just make this.

> 4. Disabling ctrl+alt+del so somebody can't walk up to your box and
> reboot the server.

What the difference to reboot console from ctrl+alt+del or
power off , reset with key, cut the power cable?

> 5. Drop SYN/FIN packets

You can use pf

> 6. Enable stealth forwarding. Stealth forwarding passes packets
> without touching the TTL, so this is useful for hiding firewalls from
> traceroutes.

I don't know how to make this with open.

Newbie <newbie@newbie.it> wrote:
>> 1. The first one is to prevent users from seeing information about
>> processes that are being run under another UID.
>
> You can modify ps, top source code. Of course is not a perfect
> solution.

Alternatively, search the misc@openbsd.org archives for a more
comprehensive patch.

>> 6. Enable stealth forwarding. Stealth forwarding passes packets
>> without touching the TTL, so this is useful for hiding firewalls from
>> traceroutes.
>
> I don't know how to make this with open.

Configure your firewall as a bridge.

Joachim

> Configure your firewall as a bridge.

Is not the same thing. I've made a brutal patch to hiding
it from traceroute:

in ip_input.c:

if (ip->ip_ttl <= IPTTLDEC) {
icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, dest, 0);
return;
}

I've comment out this row and the following row

ip->ttl -= IPTTLDEC;

In the ip_forward subroutine.
I don't know which kind of problems this modify can have on
the tcp/ip stack. Maybe can be destruptive. Anyway i use it.

We can set a sysctl variable to enable/disable it.




>
> Joachim

Newbie <newbie@newbie.it> wrote:
>> Configure your firewall as a bridge.
>
> Is not the same thing. I've made a brutal patch to hiding
> it from traceroute:
>
> in ip_input.c:
>
> if (ip->ip_ttl <= IPTTLDEC) {
> icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, dest, 0);
> return;
> }
>
> I've comment out this row and the following row
>
> ip->ttl -= IPTTLDEC;
>
> In the ip_forward subroutine.
> I don't know which kind of problems this modify can have on
> the tcp/ip stack. Maybe can be destruptive. Anyway i use it.
>
> We can set a sysctl variable to enable/disable it.

Well, at the very least, it will make routing loops rather destructive.
After all, the TTL field is there for a reason.

If you want to do this, I'd set min-ttl, personally. It doesn't break
quite as much, and usually works as well. (After all, very few systems
will send packets which arrive at your firewall with a TTL lower than,
say, 16; and very few people will wait that long for their traceroute to
return.)

And simply configuring as a bridge, while decidedly not the same thing,
does work in most practical circumstances. If you're doing NAT, it makes
little sense to try and hide the firewall; and if you are not altering
anything, a bridge works just fine. (There are some issues with, for
example, FTP, though.)

Joachim

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.

>> 2. Enable the concept of black-holing. This is so RST packets don't
> get sent back in response to closed ports. This helps to block port
> scans.

OpenBSD does this natively with PF, and I believe it is the default
behavior of the PF firewall. You can give your PF configuration the
directive "set block-policy drop" for silent non-RFC operation.

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

> 4. Disabling ctrl+alt+del so somebody can't walk up to your box and
> reboot the server.

I believe this has to be added into the console configuration via the
wsconsctl command to enable the CTRL-ALT-DEL reboot. If you're truly
paranoid, you could compile a kernel without keyboard support - the
boot loader would still allow you to use a keyboard, but then not the
running kernel once booted. If you wanted to boot into a maintenance
mode, you could carry a floppy or some other media, including an
alternate kernel on the disk, to boot from that contains keyboard
support.

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

>> 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. There
are other ways to detect a firewall is in play, such as packet latency,
and while TTL masking is a useful feature, it does foul some basic RFC
operations of TCP/IP. Toss operating a routing protocol, or any
multicast out once you use a feature like this (chances are, you're not
using either a routing protocol or multicast, however). If you're really
wanting this feature, I wouldn't hack the code up, I'd build a
transparent bridge with PF, and filter. This is a current, industry
accepted way of achieving a firewall that doesn't act like an IP router
or end-point to filter traffic. You'll find a lot more support for this
type of configuration than asking questions after compiling a custom
kernel / feature.

In general, read the PF man pages, and notes about tweaking PF for your
desired performance goals. I'm a big fan, and I doubt you'll find a more
flexible, easy-to-use firewall-in-an-OS anywhere. Those notes can
help contribute to you scaling a machine correctly for your needs. If
you're going the PC way on your project, don't scrimp on the NIC's -
spend the money to get good quality NIC's so you don't run into
performance issues. I typically buy NIC's for firewall or production
interfaces and use the on-board NIC for management or backup.

Hope this helps a bit, and good luck with your project.

-DMFH

----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

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

On 2006-01-16, jKILLSPAM.schipper@math.uu.nl <jKILLSPAM.schipper@math.uu.nl>
wrote:

> DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:

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

Absolutely - assuming a compiler will always be on hand for users to user,
which would always be the case with PERL on the system. I got that idea
from my old days of SunOS 4.1.3_U1, making menu systems for users and trying
to prevent shell escapes.


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

I think we're talking about two different features here perhaps? I was
referring to the random IP ID generator in PF, and I think you're
talking about the state modulation function, which indeed doesn't need
PF and is a part of the IP core of OpenBSD - where a strong, random
ISN (Initial Sequence Number) is generated for TCP/IP sockets, instead of
the brain-dead way other OS's do it, like adding +10 to the last, etc.
This prevenets "man-in-the-middle" attacks to some degree, etc., etc.

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

I've never quite used this, but I have considered using it on my mailer to
automagically drop what must be bogon MTA's coming from Windows desktop
systems that probably are SPAM trafficers - what's your opinion?


----
__| |_ __ / _| |_ ____ __
dmfh @ / _` | ' \| _| ' \ _ / _\ \ /
\__,_|_|_|_|_| |_||_| (_) \__/_\_\
----

DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:
> On 2006-01-16, jKILLSPAM.schipper@math.uu.nl <jKILLSPAM.schipper@math.uu.nl>
> wrote:
>
>> DMFH <dmfh@n0spam.dmfh.cx.spamn0t> wrote:
>
>>>
>>> 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.)
>
> Absolutely - assuming a compiler will always be on hand for users to user,
> which would always be the case with PERL on the system. I got that idea
> from my old days of SunOS 4.1.3_U1, making menu systems for users and trying
> to prevent shell escapes.

Neat, I didn't know perl had a syscall interface.

But ultimately, it's much easier to just compile on another system and
copy the binary. There are a near-infinite number of amusing hacks to
get the file copied, anyway.

(Of course, if you have access to cat, dd, or pretty much any editor,
no hacks are necessary.)

>> 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.)
>
> I think we're talking about two different features here perhaps? I was
> referring to the random IP ID generator in PF, and I think you're
> talking about the state modulation function, which indeed doesn't need
> PF and is a part of the IP core of OpenBSD - where a strong, random
> ISN (Initial Sequence Number) is generated for TCP/IP sockets, instead of
> the brain-dead way other OS's do it, like adding +10 to the last, etc.
> This prevenets "man-in-the-middle" attacks to some degree, etc., etc.

Oh, I understand now. Sorry.

Still, if you're talking about random-id, isn't that part of the default
OpenBSD stack, too?

>> People who ask this question tend to be very happy when told that
>> OpenBSD can block nmap (via pf's 'OS detection').
>
> I've never quite used this, but I have considered using it on my mailer to
> automagically drop what must be bogon MTA's coming from Windows desktop
> systems that probably are SPAM trafficers - what's your opinion?

I've heard it used in that way. Blocking *all* Windows traffic is a bit
much - after all, there are Exchange servers that are not sending spam,
or not only sending spam - but I've been contemplating dropping all
Windows hosts, as well as the better part of the world, into a rule that
sends them to spamd first.

I often see passive detection abused as a security feature. While
stopping nmap has some value, in that it might make scanning you
sufficiently difficult that a casual attacker will move on to
lower-hanging fruit, it does not in any way prevent someone from
scanning your network and finding out anything that nmap can find out.
Or hacking the nmap source to use a different TTL or somesuch (I don't
know how much difference is necessary to stop p0f from recognizing nmap,
but I imagine it wouldn't be that much.)
And casual attackers are not likely to be that big a danger to
moderately well-secured network, anwyay.

However, while stopping 90% of all attackers is near-useless - after
all, the 90% of attackers stopped by such a trick is likely to be the
90% that don't succeed in anything but generating a couple of logs -
stopping 90% of spam before it even enters the system - or even 50% - is
rather neat.

All in all, I'd be wary of absolutely dropping any mail - there are some
weird setups out there, and while there is no reason to accept the truly
broken ones, there are valid reasons for running a Windows mailserver at
home - but I'm quite willing to inconvenience anyone who tries running a
Windows mailserver at home a little.

Joachim