# Intruder logs via SSH in my serve, I cant stop him

## linuxholgi

Hi guys,

my webserver was hacked and I found several ROOTKITs installed.

T0rn v8

ShKit

Showtee

At least I was able to find some information about T0rn v8 and removed/repaired anything which was mentioned by tutorials and chkrootkit. Before somebody start, Yes - I have to format the system to be safe. But thats impossible for me, lack of time and mapower. When I look at the traces he left, I don't get the impression of a very smart hacker.

Anyway, he managed to make my server connect to an SSH port on a system he specified. Everytime when I reboot "he's back". I am unable to locate the file, containing his ssh key or the mechanism making this possible. All binaries, including SSH, have been re-installed. He seems to use a different ssdh than me:

My /var/log/security

```
Nov  9 14:42:30 server sshd[20329]: Server listening on :: port 22.

Nov  9 14:42:30 server sshd[20329]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.

Nov  9 14:42:35 server sshd[21673]: Accepted publickey for root from 122.255.108.146 port 51732 ssh2

Nov  9 14:42:35 server sshd[21673]: pam_unix(sshd:session): session opened for user root by (uid=0)

```

And what netstat -atn tells me:

```
tcp        0      0 :::22                       :::*                        LISTEN

tcp        0      0 ::ffff:202.75.62.188:22     ::ffff:122.255.108.14:51732 ESTABLISHED

```

To prevent that, I though iptables might be of help. So I added some rules top keep the bad guy out:

```
Chain INPUT (policy ACCEPT)

target     prot opt source               destination

REJECT     all  --  122.255.108.0        anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

REJECT     all  --  anywhere             122.255.108.0       reject-with icmp-port-unreachable
```

But doesn't matter if I use DROP or REJECT. After a reboot, the SSH connection is back. Killing the TCP connection didn't work using tcpkill which complains about an "unknown layer" error. 

So my system is open, I can't do anything. Any suggestion to keep him out immediately? I need time for the backups and setting up a plan for re-setup/move.

Holger

----------

## ToeiRei

The best thing would be doing a fresh install as you don't know what happened. The intruder could have manipulated everything.

Things that help for buying you some time:

ps axfu (show processes)

netstat -anp (show open connections AND their programs)

Rei

----------

## hxpurnama

First of all, unplug the machine out of the network. There's no point of fixing the car while the car is still running.

Try to install rootkit detection such as app-forensics/chkrootkit or app-forensics/rkhunter. Use another gentoo machine to download all the source and dependencies.

Do you made backups to your ssh configurations? If so, make sure you make a clean install of openssh (delete the /etc/ssh directory, then use the newly created one)

Check the authorized_keys of your root account (usually in /root/.ssh/authorized_keys).

The attacker could be use another path of authorized_keys. Refer to your original sshd_config.

Delete all the lines, except the one you CERTAINLY RECOGNIZE from your other machine. If you in doubt for that key lines, you can make a new RSA key again with ssh-keygen, and make sure you make a longer key (eg, 2048 bit).

After you reinstall your openssh, consider to use the AllowUsers option to explicitly allow only the selected user who can ssh to this box, and disable the PermitRootLogin. Then restrict only some limited user that you trust who can su to root. 

Also consider to install a SSH brute-force detection such as app-admin/denyhosts.

----------

## linuxholgi

Thank you for your replies, some of the mentioned things I did already. Unfortunately I have to administer the system from remote, its not located in a place where I have access to. 

I will investigate SSH again and replace all keys/configuration. To disable root logins is a good point, do this immediately.

The hacker comes from Korea, always the same network. When I would be able to block his range, he wouldn't have the opportunity for new hack attemps.. My problem seems to be his IP address, with an ipv6 placeholder "::ffff:". When I try to add this IP to iptables including the ::ffff: it just throws an error. Googled for that since 2 hours and just found one posting on a site, where I have to pay for the solution.

Any suggestions from you how I can block him? Thats all I get and the bare IP doesnt work to block him

bash-3.2# iptables -I INPUT -i venet0 -s ::ffff:122.255.108.14 -j REJECT

iptables v1.3.5: host/network `::ffff:122.255.108.14' not found

Try `iptables -h' or 'iptables --help' for more information.

Holger

----------

## Akkara

Once you get owned, depending how thorough a job they did, there might not be much you can do without physical access to the machine.

Try blocking *everything* with iptables and allow only the ip(s) you come in through, and the gateway and dns ips.  Then investigate and fix.  You can never be 100% sure except after a complete re-install.

If even ip-blocking doesn't work (and they may well have hacked iptables), you or someone will need access to the box.  If you can't do it, try getting someone to insert a live-CD and reboot for you.  Then take it from there.

----------

## krinn

1/ instead of blocking him, block anyone except you: why trying to target just his IP with your open box, anyone could use the gap he made to hack you. 

2/ don't trust your tools, now that your box is hack any tools you are using is unsafe and can lie about the info they provide you.

If you really lack time as you said, use a stage4 to backup the server, backup others data you need and clean anything then go to a fresh install. This way you will keep your settings... or could look out what happened latter.

----------

## Hu

If I recall correctly, that style address shows up when the server is listening on IPv6, the client connected on IPv4, and the IP stack bridged the difference using a section of the IPv6 address space reserved for IPv4.  A check of IPv6 on Wikipedia agrees.

----------

