Re: Uh-oh. Cracked allready. I think...
Kjetil Kjernsmo <kjetil.kjernsmo@astro.uio.no> writes:
> Thanks for all the responses.
>
> I realize it's pretty bold trying put a box on the net without having
> extensive admin experience beforehand. But I think I'm learning fast, and
> I hope I'll be able to do it without placing any burden on the rest of
> the net. That is, except for you guys... :-) Your help is greatly
> appreciated!
We do our best :)
> >Well if something's got on there that you don't remember installing, can
> >I have some of what you're taking? ;)
>
> Hehe... I was sooooo sure it would be at least one copy of Star Wars II,
> but no... ;-) There's nothing here... I've walked through the whole disk,
> and I can't find anything of any size that I don't know what is. Whatever
> it is, it has to be rather small...
Unfortunately, the only way to examine all the files on the disk/s is to
reboot the box off clean r/o media (read: rescue CD), mount them r/o, and
examine them by hand.
You're highly unlikely to find something with trojanned binaries and/or a
kernel module sitting there intercepting syscalls saying "we're not
listening on port NNNN" and "oh look, an exec() call to ps, use ps.fake
instead" - all 3 of which are possible these days.
> >It's at this point that you should start debugging what's really
> >listening on your box from what a scanner says you are. I suggest you
> >nmap yourself to see what ports you really have open, and compare
> >against
> > netstat -plant | grep LIST
> >(here's your first potential clue: if netstat complains about `-p', it's
> >been trojanned.)
>
> It complained about -p when I wasn't root...
Nah, when you're root if the option completely isn't understood then you've
got problems. (I mention this only because it was the first thing that gave
a cracked box away to me.)
> OK. This is what nmap says, launched from my workstation:
> Port State Service
> 22/tcp open ssh
> 25/tcp open smtp
These are generally safe - especially in Testing.
> 53/tcp open domain
OK, what version of what are you running for this?
> 80/tcp open http
> 110/tcp open pop-3
> 111/tcp open sunrpc
Portmapper (111) is an absolute liability - I flatly refuse to run it on
any public-facing box, and it must *never* be externally visible.
> 137/tcp filtered netbios-ns
> 138/tcp filtered netbios-dgm
> 139/tcp filtered netbios-ssn
You're running samba then?
> 6346/tcp filtered gnutella
Hang around, it's "filtered"? That means it never replied to nmap but there
were other ports that did - the mixture of responses means nmap "knows"
this port is dropping responses.
I think you have an anomaly, myself.
> So, the suspicious gnutella port isn't in the latter. I don't know what
> kdm is doing there, BTW. I unselected X and desktop in the initial
> tasksel. There seems to have been installed some X stuff nevertheless,
> but neither KDE nor kdm has ever been installed on this box.
Ah, good you said that. It's not "kdm" necessarily, it's because it's the
first port to which a non-privileged app may bind, >=1024. (See why the
next one is 1025...)
> So for netstat:
> pooh:~# netstat -plant | grep LIST
> tcp 0 0.0.0.0:1024 0.0.0.0:* LISTEN 209/rpc.statd
> tcp 0 0.0.0.0:1025 0.0.0.0:* LISTEN 236/rpc.mountd
> tcp 0 0.0.0.0:139 0.0.0.0:* LISTEN 218/inetd
> tcp 0 0.0.0.0:110 0.0.0.0:* LISTEN 218/inetd
> tcp 0 0.0.0.0:111 0.0.0.0:* LISTEN 123/portmap
> tcp 0 0.0.0.0:80 0.0.0.0:* LISTEN 6586/apache
> tcp 0 217.77.32.186:53 0.0.0.0:* LISTEN 194/named
> tcp 0 127.0.0.1:53 0.0.0.0:* LISTEN 194/named
> tcp 0 0.0.0.0:22 0.0.0.0:* LISTEN 285/sshd
> tcp 0 127.0.0.1:953 0.0.0.0:* LISTEN 201/lwresd
> tcp 0 0.0.0.0:25 0.0.0.0:* LISTEN 218/inetd
>
> (slightly reformatted to fit better)
(reformatted better still ;)
I'd not worry about that lot myself. Unless I've missed something, it's not
obviously different from the nmap results, is it?
> >Next, if you've got a socket listener or 6346 (IIRC, the most frequently
> >used gnutella port), try telnetting into it and see what banner, if any,
> >it presents.
>
> Nope, nothing...
> pooh:~# telnet 217.77.32.186 6346
> Trying 217.77.32.186...
> telnet: Unable to connect to remote host: Connection refused
> to be sure.
That's promising. And it didn't turn up in netstat, just when you used a
particular box to do the nmap?
Does the port come and go over time at all?
> >At some stage you should probably run _chkrootkit_ on the blighter, too.
>
> Yeah, I've done that several times. chkrootkit was described in "Securing
> Debian", so I installed it before moving it, but only ran it just after I
> saw the gnutella port. Nothing detected.
OK. It's not a complete guarantee as it uses potentially-tainted tools, but
it pushes the odds more in your favour.
> >Do you have an original AIDE database from immediately after it was
> >installed?
>
> Uh, don't think so. I installed snort, but didn't take the time to play
> with it. I thought that would do the job too... Can I get the required
> information from the snort install...?
Nope, snort is for dynamic logs of dodgy packets going by. AIDE is like
tripwire - stores a database of crypto hashes for files in the filesystem,
so you compare the database nightly and see what's changed of interest.
> >> I tried to set the suggested PermitRootLogin for ssh to
> >> no, but ssh gave me some messsage that I thought meant it did't
> >> recognize it.
> >
> >That's weird. Try running an sshd from a terminal, to read /etc/ssh/*,
> >and see if you get any syntax errors there.
>
> Yeah, I got something weirder now...:
> pooh:/etc/ssh# /usr/sbin/sshd -f /etc/ssh/ssh_config
> /etc/ssh/ssh_config: line 19: Bad configuration option: ForwardX11
> /etc/ssh/ssh_config: line 24: Bad configuration option: FallBackToRsh
> /etc/ssh/ssh_config: line 31: Bad configuration option: IdentityFile
> /etc/ssh/ssh_config: line 36: Bad configuration option: PreferredAuthentications
> /etc/ssh/ssh_config: terminating, 4 bad configuration options
>
> What could be wrong about e.g.:
> ForwardX11 yes
Erm, that's a little bit weird.
| StrictModes yes
| X11Forwarding yes
| X11DisplayOffset 10
| AllowTcpForwarding yes
I think you're somehow using an old sshd_config with a proto2-enabled sshd.
Or a non-free ssh against openssh. Possibly.
[snip md5sum]
>
> They are OK.
Good. OK, in that case, you might want to double-check a few others as
well:
| c29daf1d9fe836053e9f4f0a67a7a94e /usr/sbin/chkrootkit
| c0f2f541bcce2394cb026cfa4ccb5c38 /bin/ps
| d017f214341677d56ec242a8916f8f45 /usr/bin/top
| a5c720b6776331b9695d9a1f4f5c2194 /bin/ls
| f998091a416e9dca4879218cae269bb8 /bin/fuser
> ><http://www.cert.org/tech_tips/win-UNIX-system_compromise.html>.
> >
> >First assess whether you really have been breached; if you have, you
> >*must* reformat, reinstall, update all packages, firewall, install an
> >IDS (aide) and nIDS (snort) - but take a forensic last-minute backup
> >before you do.
>
> Well, yeah, Istill don't know if I've been breached, after all, it is
> only the gnutella entry in the nmap I do from my workstation, but then,
> better safe than sorry...
You probably haven't been had just yet. You should keep an eye the
incoming/outgoing traffic, though; I thought I saw a utility for analysing
how many hosts/ports a box contacts over time recently, which will help.
Set up snort and AIDE as a matter of urgency too - I won't promise that
this is not after the horse has bolted, but I think you're probably OK at
the moment. But you won't be if you go on with portmap and dns dangling
around all over the place, nor will you be aware what's going off if you
don't start firewalling things properly and keep a close eye on your IDS.
HTH,
~Tim
--
<http://spodzone.org.uk/>
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: