Auditing for unauthorized access attempts with the auth.log file (LINUX)

Hello All,

If you are running a linux based webserver or any type of server as a best practice is to view any unauthorized access attempts against your server this can give you an insight as to if your server is being bruteforce attacked or if someone within your network is attempting to gain access to you server

there are many ways of doing this but for this post I will show you how to see this information in the AUTH.LOG file

the auth.log file is located in /var/log/auth.log this file logs authorization success and failures and reports the remote IP if the attempt from the network as well as the username being used

here is a sample output

Nov 24 11:17:01 CRON[9076]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 24 11:17:01 CRON[9076]: pam_unix(cron:session): session closed for user root
Nov 24 11:21:03 sshd[9079]: Did not receive identification string from 220.226.6.44
Nov 24 11:29:58 sshd[9080]: Invalid user bob from 107.20.246.150
Nov 24 11:29:58 sshd[9080]: input_userauth_request: invalid user bob [preauth]
Nov 24 11:29:58 sshd[9080]: pam_unix(sshd:auth): check pass; user unknown
Nov 24 11:29:58 sshd[9080]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ec2-107-20-246-150.compute-1.amazonaws.com
Nov 24 11:30:01 sshd[9080]: Failed password for invalid user bob from 107.20.246.150 port 55032 ssh2
Nov 24 11:30:01 sshd[9080]: Received disconnect from 107.20.246.150: 11: Bye Bye [preauth]
Nov 24 11:30:02 sshd[9082]: Invalid user john from 107.20.246.150
Nov 24 11:30:02 sshd[9082]: input_userauth_request: invalid user john [preauth]
Nov 24 11:30:02 sshd[9082]: pam_unix(sshd:auth): check pass; user unknown
Nov 24 11:30:02 sshd[9082]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ec2-107-20-246-150.compute-1.amazonaws.com

The above is an output from a public webserver as we can see from the log an access attempt from 107.20.246.150 using the username john

Viewing this log regularly can help you build proper firewall rules if you happen to see many access attempts from a specific network or a specific IP

you could also create a small script that can email you this log periodically that would be helpful I suppose

Until next time
stay secure !

Site Maintenance

Hello Everyone!

For the next couple of days you may see the site go up and down I am in the middle of doing some system upgrades and updates

I will also be posting more videos and posts to my blog and am thinking of a new theme

Thank you !

sean

DNS amplification attack …. What is it ?

Latley we have been seeing in the security news of a newer type of attack called ” DNS amplification attack” or what was know as a SMURF attack

How does it work ?

The attack works when a attacker finds a open dns server that accpets look ups from outside its network (aka misconfiguration) and spoofs the udp request to the DNS server to make it appear as it has originated from another IP for example

Attackers computer 1.1.1.1 send a DNS lookup to a misconfigured DNS server 2.2.2.2 but spoofs the source ip address to be of victims computer 3.3.3.3 the lookup data and traffic then get send to the victims computer which amplifies the amount of traffic as a lookup may bey about 30-60 bytes of data but a response to a dns lookup is larger

see in this example you run the following command

dig google.ca

gives you the following response

;; Query time: 52 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 13 02:02:34 2013
;; MSG SIZE rcvd: 75

we see the received size of the request is 75 byte request so the original request traffic has now been amplified because the response traffic is greater than the source traffic

Mitigation …

Due to the nature of this attack there are only a few mitigation techniques and there is not a all in one solution

1.) One way that has been suggested is to filter DNS request from the untrusted network ( RED network ) to your internal LAN if you are not host a public DNS server you should be able to block and or filter DNS requests from entering your network you can do this either on your edge router or have your provider do this for you

2.) Black hole network

Another way you can mitigate this attack is having a separate segment on your network with a edgde router with a configure null interface you can through a routing protocol that can move the victims ip address to the non-production network

see example below

Screenshot from 2013-08-13 02:27:03

3.) Use webservices such as cloudfire which have networks that are built to protect webservers from DDOS attack now this only helps for attacks agains your webserver and not your LAN

4.) You can look over RFC 2827 with respect to ingress filtering

5.) Internet providers can employ source address verification using URF ( Unicast reverse path forwarding)
You can see this article which is great explanation on what can be done on the ISP side http://www.sanog.org/resources/sanog8/sanog8-ip-spoofing-akinori-maz.pdf

6.) Also another mitigation step would be to rate limit the amount of requests per ip to the dns server if the requests become more the allotted then the request should be dropped and or blocked

What can DNS server admins do ?

1.) Rate limit DNS responses to a single ip
2.) if you are not running a pubic dns server deny access from outside your network by using access-lists etc
3.) regularly tests your dns servers for security holes
4.) Use best practices for server management

In summary DNS amplification attacks can be a heavy hitter attack as the amount of eigress traffic that can be generated from only a small amount of ingress traffic is amazing

Until next time
Stay secure !