[PLUG] . SELinux Audit Report (Rich Shepard)

Mike C. mconnors1 at gmail.com
Mon Jul 21 06:32:08 UTC 2014


>
> Message: 2
> Date: Sun, 20 Jul 2014 06:16:00 -0700 (PDT)
> From: Rich Shepard <rshepard at appl-ecosys.com>
> Subject: [PLUG] SELinux Audit Report
> To: plug at pdxlinux.org
> Message-ID: <alpine.LNX.2.11.1407200611480.28801 at 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



More information about the PLUG mailing list