> > Message: 2 > Date: Sun, 20 Jul 2014 06:16:00 -0700 (PDT) > From: Rich Shepard <[email protected]> > Subject: [PLUG] SELinux Audit Report > To: [email protected] > Message-ID: <alpine.LNX.2.11.1407200611480.28801@localhost> > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > While logwatch.pl is still not being run from root's crontab, my manual > running this morning starts with a log report I've not before seen: > > --------------------- Selinux Audit Begin ------------------------ > > **Unmatched Entries** (Only first 10 out of 713 are printed) > type=1326 audit(1405757401.043:10184): auid=4294967295 uid=33 gid=33 > ses=4294967295 pid=16637 comm="sshd" sig=31 syscall=102 compat=0 > ip=0xb73dd922 code=0x0 > type=1326 audit(1405757404.968:10185): auid=4294967295 uid=33 gid=33 > ses=4294967295 pid=16639 comm="sshd" sig=31 syscall=102 compat=0 > ip=0xb7383922 code=0x0 > > This looks to be reports of attempts to crack the network via sshd, yet > these attempts are also found in the sshd section: > > --------------------- SSHD Begin ------------------------ > > Disconnecting after too many authentication failures for user: > admin : 103 Time(s) > root : 610 Time(s) > > Failed logins from: > 61.174.50.235 (235.50.174.61.dial.wz.zj.dynamic.163data.com.cn): 153 > times > 61.174.51.196 (196.51.174.61.dial.wz.zj.dynamic.163data.com.cn): 297 > times > 61.174.51.204 (204.51.174.61.dial.wz.zj.dynamic.163data.com.cn): 40 > times > > What is the selinux audit telling me and how do I recognize when I need > to > respond to something in there? > > Rich > > -- Rich, this looks to me like pretty standard script kiddie brute force > attacks on a public facing SSH server.
Figuring out what and how to respond to is going to be mostly a personal learning experience that is going to depend on your personal security needs and administrative overhead, that is the time and energy you're willing to put in. In this case, if you have a strong password that you feel confident won't be cracked by dictionary attacks, then there isn't anything more you have to do, However, there are tools you can use to reduce the amount of time and energy you expend on such activity. DenyHosts and Fail2Ban are two such tools that come to mind. 1. DenyHosts *DenyHosts* is an open source log-based intrusion prevention security script for SSH servers was written in* python* programming language that intended to run by Linux system administrators and users to monitor and analyzes SSH server access logs for failed login attempts knows as *dictionary based attacks* and *brute force attacks*. The script works by banning *IP* addresses after set number of failed login attempts and also prevent such attacks from gaining access to server. DenyHosts Features 1. Keeps track of */var/log/secure* to find all successful and failed login attempts and filters them. 2. Keeps eye on all failed login attempts by user and offending host. 3. Keeps watch on each existing and non-existent user (eg. *xyz*) when a failed login attempts. 4. Keeps track of each offending user, host and suspicious login attempts (If number of login failures) bans that host *IP* address by adding an entry in */etc/hosts.deny* file. 5. Optionally sends an email notifications of newly blocked hosts and suspicious logins. 6. Also maintains all valid and invalid failed user login attempts in separate files, so that it makes easy for identifying which valid or invalid user is under attack. So, that we can delete that account or change password or disable shell for that user. 2. Fail2Ban *Fail2ban* is one of the most popular open source intrusion *detection*/ *prevention* framework written in *python* programming language. It operates by scanning log files such as*/var/log/secure*, */var/log/auth.log* , */var/log/pwdfail* etc. for too many failed login attempts. Fail2ban used to update *Netfilter/iptables* or *TCP Wrapper’s* hosts.deny file, to reject an attacker’s *IP* address for a set amount of time. It also has a ability to unban a blocked IP address for a certain period of time set by administrators. However, an certain minutes of unban is more enough to stop such malicious attacks. There's also a couple of other things you can do to seriously reduce the number of brute force login attempts to your SSH Server. One is to use a different port# other than the standard port# that the SSH server listens on. Another one is to disable password logins and to only use SSH keys instead. And lastly you can specify the ip address(es) that login attempts will be allowed from. You should be able to find ample how-tos on the interwebz for doing all three of these. Hope that's helpful. Cheers, Mike Cheers, Mike _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
