[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [edgar@monteparadiso.hr: server problems- strange portsa nd processes]



>
> Hello.
> After changing some settings for a domain in Apache it couldn't be
> started again. The error message said:
>
> "Starting web server: Apache2(98)Address already in use: make_sock:
> could not bind to address 0.0.0.0:8056
> no listening sockets available, shutting down
> Unable to open logs
>
> We couldn't find any problems and we rebooted the machine. Then Apache
> worked fine. But, after changing again some settings in apache and
> restarting the web server we had the same problem.
>
> Then we went to see what's on that port:
> netstat -lnp | grep '0.0.0.0:8056'
>
> and the result was:
>
> tcp        0      0 0.0.0.0:8056            0.0.0.0:*
> LISTEN     13337/flood
>
> What was that flood? After killing the process apache worked fine.

But were you not curious why it was trying to bind to a port other
than 80?

> A few days ago there were some problems on the server. we couldn't ssh
> to it, the network card was in promiscous mode (it seems it was
> attacked). Could it be that somone cracked it? The logs are clean.
> It's a Debian Sarge with a 2.4.27-2-686 generic kernel image.

Your machine almost certainly has been hacked, and the sshd that is/was
running is/was trojaned. You must now treat all accounts used to ssh
into or out of that machine as having their passwords no longer secret.
Take that machine off the network now. Change passwords everywhere
for all accounts that exist on that machine without delay. Anytime that
sshd is acting funny, you must consider the likelihood that you have
been rooted. Anytime that a network card is in promiscuous mode
that is a sure sign that a script kiddie has had free run of the machine.
Then, that means that everything on the same segment of the LAN
may have also been sniffed, especially if you are using a hub instead
of switched ethernet.

I would bet that the 'clean logs' are cleaner than they should be. The signs
are things like when you run the 'last' command, logins are not shown from
prior to the compromise. Other logs will probably have gaps in them.

Probably their is a rootkit running and hiding processes, and some of
the system binaries have been replaced. So, another set of likely symptoms
are 'top', 'ps', 'ls', 'netstat' segfault or are installed more than one place.
Some new shutdown, startup, and chron scripts may be present.

Some rootkits do not get along well on Debian, and depending on how
persistant and knowledgeable your cracker was they may have given
up before they got very far.

It is extremely difficult to trust anything on a machine after it has been
compromised, some would say it is impossible. The usual litany
of recommended actions are along the lines of:

1. Take the machine off the network now.

2. Check other machines on the same network for signs of compromise.

3. If you must preserve data or logs, remove the disk(s) and examine them
by either booting from known clean media, or placing them in another machine.
Avoid mounting the disk(s), use dd with the input as the device name to
do backups or preserve log files.

4. Some advise not shutting down, unplug power instead.

5. If there is any desire to get law enforcement involved, pull power and
do not attempt any forensics yourself.

6. Personally, I myself have attempted (sucessfully) to first ascertain
what ip address range I need to null route at a border gateway router
before powering off, but get the machine off the network first.

And more, lots more.
http://www.debian.org/doc/manuals/securing-debian-howto/ch-after-compromise.en.html

Good luck



Reply to: