Possible Breakin Attempt

ArthurDent · 12-17-2006, 09:21 AM

I have just upgraded from Fedora Core 5 (FC5) to FC6 and I had not quite got around to setting up SSH (but I had left the port forwarded on my router). I assumed that FC6 would be pretty secure out-of-the-box.

This morning I found these entries in my root logwatch email:

Code:

 sshd:
    Authentication Failures:
       root (201.63.218.114): 83 Time(s)
       unknown (201.63.218.114): 8 Time(s)
    Invalid Users:
       Unknown Account: 8 Time(s)

and:

Code:

--------------------- SSHD Begin ------------------------


 SSHD Killed: 1 Time(s)

 SSHD Started: 3 Time(s)

 Failed logins from:
    201.63.218.114 (201-63-218-114.customer.tdatabrasil.net.br): 83 times

 Illegal users from:
    201.63.218.114 (201-63-218-114.customer.tdatabrasil.net.br): 8 times


 Received disconnect:
    11: Bye Bye : 90 Time(s)

 **Unmatched Entries**
 reverse mapping checking getaddrinfo for 201-63-218-114.customer.tdatabrasil.net.br failed - POSSIBLE BREAK-IN ATTEMPT! : 91 time(s)

 ---------------------- SSHD End -------------------------

I imediately updated my /etc/ssh/ssd_config by adding the following lines:

Code:

IgnoreRhosts yes
IgnoreUserKnownHosts no
PrintMotd yes
StrictModes yes
RSAAuthentication yes
PermitRootLogin no
PermitEmptyPasswords no

and by changing "passwordAuthentication yes" to "passwordAuthentication no"

The question is: Have I done enough?

I have never - to my knowledge - had a direct attack before. How can I tell if he was actually successful in the end. Had he, perhaps, gained access in the past when I was running with FC5 and was just trying to get back in again?

Am I just paranoid?

Thanks for your help and support.

Mark

introuble · 12-17-2006, 10:01 AM

Quote:

The question is: Have I done enough?

*Enough* for what? To have a secure system? To secure SSHD? One could say that it's never enough, no matter what you do.

jschiwal · 12-17-2006, 10:02 AM

It was probably a script kiddie running a brute force script. You can change the port that ssh listens on as well. Also, if you are the only user who logs in using ssh, add your username to a "AllowUsers <username(s)>" entry. This will disable all login attempts using other usernames. You can edit hosts.allow and host.deny so only connections from certain hosts are allowed.

Look in the auth or messages log and examine which ssh lines say accepted. Of course a hacker would edith the log. Run a rootkit scanner such as chkrootkit. Use the "rpm -V --all" command will verify packages and print out info if it detected any changes. Some changes were done by you of course. If a common command such as ls or cp fails the verification, then investigate further.

ArthurDent · 12-17-2006, 10:12 AM

Thanks chaps, I'll get onto it right away:

Quote:

Use the "rpm -V --all" command will verify packages and print out info if it detected any changes. Some changes were done by you of course.

Of course the trouble is I just installed FC6, (the day before yesterday) and I have been madly installing and uninstalling RPM's so there will be a lot to wade through... and I haven't got round to installing chkrootkit yet either.

Anything else I should do?

Thanks very much for your help. Much appreciated...

Mark

jschiwal · 12-17-2006, 04:37 PM

The rpm -V -all command will just print out lines for files that are altered in some way, contents or permissions, etc. Having just installed fc6 may be a benefit because you will probably not have make as many changes.

rpm -Vv -all (the small v is for verbose) would give you a line of output for each installed file. Now that one would be a lot to wade through. )

If this is a fresh install, and especially if you don't have your data installed yet (such as database tables), it may be quicker and safer to assume the worst and reinstall from scratch. This is a judgement call. Once a hacker can get root access, he can alter commands and logs. However here, there doesn't seem to be an effort to cover up, so if your root password was strong enough he may have given up and moved on. ( Or that is what he wants you to think and the ssh attacks are left in the logs as a RedHerring. ) I don't think that a script kiddie would be that clever.

As I understand it, the majority of successful attacks on a secured server are done using Social Engineering rather than a brute force attack. Here I am talking about targeted corporate espionage attacks.

I don't think that I mentioned it before. Make sure that your ssh server only allows ssh-2. Do not allow a fallback on ssh-1.
Use
Protocol 2
Don't use
Protocol 2,1

Gethyn · 12-17-2006, 04:54 PM

If you're getting a lot of brute-force attempts, you could also try installing DenyHosts. I expect Fedora has a package for it.

ArthurDent · 12-17-2006, 05:16 PM

Thanks jschiwal - much appreciated,

I checked, and my sshd_config is set to "Protocol 2". The only things I am not sure about are:

a) I have a line that says "UsePAM yes" (I've obviously changed it at sometime in the past because the original "UsePAM no" line is simply commented out above (something I usually do when I change a config setting - or has someone else changed it?) is this right? Would it be a good idea for me to post my whole sshd_config?

b) You mentioned

Quote:

add your username to a "AllowUsers <username(s)>" entry.

I have no such entry in sshd_config. Is that where it goes? Is the syntax simply "AllowUsers fred" and do I have to change any other settings to "deny" others? (It is only me that logs in via ssh).

I tried "rpm -V -all" but it listed *thousands* of entries - literally every single rpm it seems - as being changed since prelinking - whatever that is, so I gave up on that... here is just a snippet:

Code:

prelink: /usr/lib/libpt_linux_x86_r.so.1.10.1: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/lib/libpt_linux_x86_r.so.1.10.1
prelink: /lib/security/pam_krb5/pam_krb5_storetmp: at least one of file's dependencies has changed since prelinking
S.?.....   /lib/security/pam_krb5/pam_krb5_storetmp
prelink: /usr/bin/afs5log: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/afs5log
S.5....T   /usr/share/icons/hicolor/icon-theme.cache
prelink: /usr/bin/chage: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/chage
prelink: /usr/bin/faillog: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/faillog
prelink: /usr/bin/gpasswd: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/gpasswd
prelink: /usr/bin/lastlog: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/lastlog
prelink: /usr/bin/newgrp: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/bin/newgrp
prelink: /usr/sbin/chpasswd: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/chpasswd
prelink: /usr/sbin/groupadd: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/groupadd
prelink: /usr/sbin/groupdel: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/groupdel
prelink: /usr/sbin/groupmod: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/groupmod
prelink: /usr/sbin/grpck: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/grpck
prelink: /usr/sbin/grpconv: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/grpconv
prelink: /usr/sbin/grpunconv: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/grpunconv
prelink: /usr/sbin/newusers: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/newusers
prelink: /usr/sbin/pwck: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/pwck
prelink: /usr/sbin/pwconv: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/pwconv
prelink: /usr/sbin/pwunconv: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/pwunconv
prelink: /usr/sbin/useradd: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/useradd
prelink: /usr/sbin/userdel: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/userdel
prelink: /usr/sbin/usermod: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/sbin/usermod
prelink: /usr/lib/libruby.so.1.8.5: at least one of file's dependencies has changed since prelinking
S.?.....   /usr/lib/libruby.so.1.8.5

Thanks Gethyn - I will look into DenyHosts - In the meantime I have blocked the attackers IP at the router - but I suspect it was a hijacked IP anyhow - but it made me feel better...

Thanks again to all...

Mark

jschiwal · 12-17-2006, 07:26 PM

Yes, just add the line "AllowUsers fred" for example. The ssh_config and sshd_config files have there own man pages:
man 5 ssh_config

I'm not certain about the UsePAM option. I don't think that it short circuits the use of public/private keys. I think it controls the access to the bash shell itself, as if you were logging into a vt on the machine locally. I am using it. There is an /etc/pam.d/sshd file which controls the behavior. I'm not an expert in PAM so it may be advised to increase the level of logging so you understand the process that takes place when you log in remotely.

If you always log in from a fixed number of hosts, using AllowHosts instead of DenyHosts may deny all other hosts. I think it would be better to utilize the TCP-wrappers file for this; i.e. /etc/hosts.allow and /etc/hosts.deny. You can have a global deny all policy but allow only what you want to in /etc/hosts.allow. You can control individual services making the policy for ssh even more restrictive than the generic policy.
See the "man 5 hosts_access" for details.

Also, if this isn't a personal server, I would recommend keeping a 3-ring binding of notes so others can see what changes you made later. As well as a reminder for yourself incase you forgot a particular item changed. This should also help when you set up another server.

jschiwal · 12-17-2006, 07:48 PM

I don't think that PAM short circuits the key exchange process but adds the normal shell login authorization on top of the connection exchange. I'm not a PAM expert, so it may be a good idea to increase the logging level and log in remotely yourself. Then examine the log to see what process occurred. I have PAM enabled. There is a /etc/pam.d/sshd that controls the behaviour.

I don't like the changed dependency info you posted. Maybe this means that you updated these since rebooting, however unless you find out it is OK, I would play it safe and reinstall.

I tried the rpm verify command myself. I have a lot of missing '/dev/' entries which isn't a problem, so running 'rpm -V -all | grep -v '/dev/' produces a much shorter list. Most of the items are "*rc" and "*.conf" configuration files.

It may be better using ssh's built-in tcp_wrappers support and use /etc/hosts.allow and /etc/hosts.deny to define the blacklisting host policy. Also, it is usually better to have a "deny all except" policy. That way the same hacker can try from another host and still be denied access. You can have an entry for ssh, allowing even finer control. For example, you would never expect someone to try to login from the nameserver unless it was comprimised. So either only allowing certain hosts, or adding exceptions to a policy that allows local hosts might help prevent attacts from comprimised local hosts as well. You can read through "man 5 host_access" for details on configuring /etc/hosts.allow and /etc/hosts.deny.

Good Luck!

jschiwal · 12-17-2006, 08:49 PM

Sorry for the double posting. After I tried to post my response, I ended up on a report abuse page and I didn't realize it got posted anyway.