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