[lug] What do you do about hackers (in the current sense of uninvitedobnoxiousintruders)

[D. Stimits]

Bear Giles wrote:
> 
> > > It's normal for all kinds of local authentication.  But anyone asking
> > > for it via the network should be viewed with extreme suspicion.
> >
> > Depends. For NFS, quite a few PAM based auths, and I'm sure more that
> > depend on either a system directory of users (I'm loosely including
> > multiple means of doing this), all access it.
> 
> But they access it locally, on behalf of a remote user.  Either NFS nor
> PAM asks a remote system for its copy of the /etc/passwd file.  The only
> thing even remotely close is NIS, and even NIS should not be distributing
> the ypasswd file to anyone other than the local subnet.

Yes, but I was saying that the file could not be made non-readable, it
would break things. Protection cannot be by means of making the passwd
file inaccessible to anyone but root. One can avoid giving the file out
to remote users, but one cannot avoid making /etc/passwd world readable.

...
> > I don't know of any even semi-modern Linux distros that use root access
> > (of course there is IIS on win that runs as administrator, and plays
> > suid games to make it appear less vulnerable, but has just as many games
> > available to get admin level back).
> 
> I wasn't just refering to the web server.  It's harder to exploit a
> buffer overflow, but it's not impossible.  That's why it's important
> that all services eventually run as non-privileged users and/or in
> sandboxes.

Very true. Unfortunately for IIS, it's rather difficult to avoid having
it not run as the sys admin at its core. You can play games with it, you
can isolate parts of it, but at least some portion is going to run as
sys admin. And the really bad thing about a buffer overflow is that only
one person needs to be smart enough to exploit it, then they publish the
way to do this for all the script kiddies. Take for instance XOR
encryption, it is a joke, you could break it on a calculator, but
someone who doesn't know what it is will never break it. Should there be
a flaw found in MD5 through ipchains via some strange stack overflow,
you can bet that script kiddies without the knowledge to install their
own linux distro will soon be exploiting it due to publishing. With IIS,
digging hard enough will find a sys admin exploit, whereas this is
rather unlikely with Apache running as user "nobody" (I'm not saying it
is impossible, but it is right up there with breaking a well-designed
strong encryption).

> 
> > Actually, a variation on this would be fun. Make it so that fake
> > accounts have passwords that if a dictionary finds it, and someone tries
> > to use it, a network sniffer triggers alarms and traces whatever it is
> > trying to use that name with the unencrypted pass (honeypot?).
> 
> That's skirting "feeding the trolls" - how sure are you that you don't
> have any potential exploits in your honeypot?

I just said it would be fun to set it up to trigger when someone
transmits the name/pass combination. Didn't say it was a good idea. If I
were to do something like that, it wouldn't be on a network with other
machines, but I could still sniff for the attempt to use that name and
account on other networks...the predictability of script kiddies. If you
created the name/pass combo yourself, there is nobody who could know it
without having either cracked it or heard it from someone else who did.

> 
> > I would be highly surprised if the original attacker wasn't themself a
> > cracked machine.
> 
> I agree, but I also know that many sites refuse to believe that they've
> been cracked until presented with indisputable proof.  Hence the comment
> about filling a partition with a bogus /etc/passwd file - it would be
> hard to ignore the fact that you've been cracked in this case.

By the time they have the passwd file, they have at least some exploit
available, and are trying to expand it to a better exploit. If you have
a lot of machines to maintain, it isn't a particularly good thing to set
up your system to use non-standard /etc/passwd files. If you give the
troll a fake one for every web request that wants it, it's true they
have misleading data, but then you also have their attention (I'd rather
just button it up if possible, feed them false data only as a last
resort).

> 
> In contrast, I'm still getting hit with MSTDs from about 10 other cable
> modem users.  If I could somehow track down the owners, I'm sure every
> one of them would insist that their system hasn't been compromised and
> there's no reason for them to take any corrective action.

That's where auth is nice if you make it required for certain things.
They can't claim spoofing, and you can send logs to ISP's. Most ISP's
are in fact capable of understanding that it isn't spoofed at that
point. If I have someone try too hard to get in locally, I do send the
data to their ISP, and it almost always results in extra action; if they
don't, I send it to the upstream provider, and the ISP can't ignore it.
The exception is from foreign ISP's and countries where they really
don't care or too much is hidden. Some of the most interesting attempts
for me came from China; if I send it to their government provider, it
has a 100% effective response. Korea, on the other hand, is close to 0%
effective, regardless of whether it is spam or active cracking attempts.
USA seems somewhere in between, but if followup responses are required,
with a CC copy to someone they don't want to answer to, there is close
to a 100% response in that case. "Resistance is not futile".

D. Stimits, stimits at idcomm.com

> 
> Bear
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug