Re: user not in passwd launching attacks

mattdorais@xxxxxxxxx wrote:
Hi, I have limited experience with Linux security so I'm hoping
someone can help me. We had a complaint that there were attacks being
launched from one of our servers (Ubuntu OS). I did a "lsof -i" as
root and sure enough saw pages & pages of processes by this user
launching attacks. Before killing the processes I tried deleting the
user but I always got an error saying that he's not in the /etc/passwd
file (which he is not). Every google search I did said to delete a
user, delete them from the /etc/passwd file (quite frustrating!). I
was able to finger this user's account. So my question is, how do I
delete a user's account if they're not in the passwd file?

Just FYI I have blocked access to this server via firewall so it will
no longer be a problem but I'd still like to know how to delete a user
like this.

You need to check policy to see if legal action is a possibility, if so
you need an expert to work on your system. Otherwise, you can ignore
the problem and wipe the system. That too requires some expertise
as there may be boot sector viruses, HPA or DCO hidden disk areas
(for AT disks anyway), and even flashed BIOS malware. It is
often better/cheaper to pretend it is time for a hardware refresh
anyway and scrape the suspect system completely.

Wiping the system without fixing the security problem that
led to the attack will leave your hosts vulnerable to another
attack. If you don't fix the problem re-installing the system
won't help, you'll be attacked again. If the server didn't
have logs enabled for you to examine, you may really need to
hire an expert or your other hosts will be at risk too.

If you want to investigate on your own (did I mention you should
probably hire an expert?) then here's some brief advice:

Most attacks today are done by script-kiddies, who leave
traces of their activities in the log files and elsewhere.
Serious attackers won't leave such traces for a novice
investigator to find, but it can't hurt to look before
wiping the disk or throwing it out.

Boot using a CD-ROM live distro and use it's tools to examine
your password and group files, log files, etc. Check the md5
sum for commands such as ls, ps, who, etc., with known good
values from a similar system. Check the reported size of
the disk and filesystems, and look for gaps or hidden disk

Check the network logs to determine when the attack started,
and then examine the relevant host log file entries to see
what happened at that time.

Use pwck on the suspect password and shadow files. This should
show any bad entries, however if your system was hacked the
user name showing in lsof may have been faked.

Look for weak passwords with some tool such as John the Ripper.

Try to figure out how the intruder got into your system. Are
you running insecure versions of software? Do you have
insecure configurations of servers such as permitting
unrestricted uploads via FTP, WebDAV, etc.?

In any case you should keep the network egress packet filters
in place. Be sure all your hosts have all available security
patches applied. Turn off un-needed services and disable
or remove dormant user accounts. Look for cron and at
jobs that don't belong. Remove un-needed software that could
aid an attacker, such gcc. Enable available security features
of your systems.

Get some books on securing a Linux system, there are many
(including a few good ones. :-) Make time in your work
schedule for reading and practicing. And monitoring the
systems you're responsible for.

Good luck!


Relevant Pages

  • Re: Changes in IDS Companies?
    ... Things like port scans and DoS attacks very often ... >> If people are running insecure web servers, ... when people don't update their patches at ... > downplay the vulnerability to save face, so admins even if they are trying ...
  • RE: Hacking to Xp box
    ... If the firewall doesn't block ICMP, ... you need to find some vulnerability that could be exploited to run ... > restricts most of the attacks that use anonymous connections. ... > login pages, dynamic content etc. Firewalls, SSL and locked-down servers ...
  • Re: Blocking attacks from spoofed IP addresses
    ... cause a _Self_ Denial Of Service attack. ... Defeating Denial of Service Attacks ... of our DMZ servers, and had source IPs from our public DNS servers. ... Web services are on your port 80 and/or 443, ...
  • RE: Changes in IDS Companies?
    ... In any ID implementation tuning of the device to reduce false alarms is ... necessary flexibility to drop some user specified attacks while only ... >> Pretty sad state of affairs, when people don't update their patches at ... >>> only lazy admins get their servers broken into), ...
  • RE: Hacking to Xp box
    ... restricts most of the attacks that use anonymous connections. ... nessus found port 135 139 ... Audit your website security with Acunetix Web Vulnerability Scanner: ... login pages, dynamic content etc. Firewalls, SSL and locked-down servers ...