Arch Linux

nullpointer

Member

From: Canada

Registered: 2005-04-21

Posts: 8

auth.log

So I was wondering if I should be concerned about this being in my /var/log/auth.log?:

Jul 29 19:46:29 ancient sshd[8081]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:32 ancient sshd[8083]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:35 ancient sshd[8085]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:38 ancient sshd[8087]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:41 ancient sshd[8089]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:47 ancient sshd[8093]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:50 ancient sshd[8095]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:53 ancient sshd[8097]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:56 ancient sshd[8099]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:46:59 ancient sshd[8101]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:01 ancient sshd[8103]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:04 ancient sshd[8105]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:10 ancient sshd[8109]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:16 ancient sshd[8113]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:19 ancient sshd[8115]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:22 ancient sshd[8117]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:25 ancient sshd[8119]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:33 ancient sshd[8125]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:47:36 ancient sshd[8129]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:18 ancient sshd[8160]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:21 ancient sshd[8162]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:24 ancient sshd[8164]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:27 ancient sshd[8166]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:35 ancient sshd[8172]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!
Jul 29 19:48:38 ancient sshd[8174]: reverse mapping checking getaddrinfo for sundaram-13-152-chn.sundarambizserv.com failed -
POSSIBLE BREAKIN ATTEMPT!

This happened just after I turned off password authentication and only use private keys to log into sshd.  What does this mean?  Is this the result of me changing the login method?  Before I was getting a bunch of logs for Failed passwords for invalid users..

soloport

Member

Registered: 2005-03-01

Posts: 442

Re: auth.log

If you're using iptables, already, here's a way to "port knock" your way in and otherwise completely block access to ssh.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:TRAFFIC - [0:0]
:SSH-INPUT - [0:0]
-A INPUT -j TRAFFIC
-A FORWARD -j TRAFFIC
# Accepted
-A TRAFFIC -i lo -j ACCEPT
-A TRAFFIC -s 192.168.0.0/24 -j ACCEPT
-A TRAFFIC -p icmp --icmp-type any -j ACCEPT
-A TRAFFIC -m state --state ESTABLISHED,RELATED -j ACCEPT
# Local services
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
# Port knocking
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH1 -j ACCEPT
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH1 --remove -j DROP
# Use either port 1234 or port 5678 to re-close port
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 5678 -m recent --rcheck --name SSH0 -j SSH-INPUT
-A TRAFFIC -m state --state NEW -m tcp -p tcp -m recent --name SSH0 --remove -j DROP
-A TRAFFIC -m state --state NEW -m tcp -p tcp --dport 1234 -m recent --name SSH0 --set -j DROP
-A SSH-INPUT -m recent --name SSH1 --set -j DROP
# Others
-A TRAFFIC -j DROP
COMMIT

Now, from a remote host, you can run:

telnet yourhost.com 1234
...
^C <== Ctrl-C to break
telnet yourhost.com 5678
...
^C

This will have openned port 22 for the remote IP address.  Now you can ssh to yourhost.com and get a login prompt.

For a more convenient knock, use a bash script:

#!/bin/bash
# requires nmap
# $1 host name or IP address
nmap -p 1234 --host_timeout 201 $1
nmap -p 5678 --host_timeout 201 $1

NOTES:
This technique is IP-based, not just port-based.  In other words, just because you have opened port 22 from work, doesn't mean you can, say, go to a client's office and automatically ssh in.  You will have to port-knock AGAIN from the new location (different IP address).

This is nice because you can open up port 22 from work and leave it open for forever.  Having the port open from work leaves it closed to all other IP addresses.  For example, my main server is open from about a dozen places around town, which I visit on a weekly basis.  (And I have not seen "a bunch of logs for Failed passwords for invalid users" since I began using this technique.)

Use what you need inplace of 192.168.0.0/24 for your LAN.

As you may already know: port 80 is http; port 443 is https.  So add other ports to this section (i.e. above the ssh port-knocking lines) which you may need to support.

Do NOT use 1234 and 5678 as knock ports (these are used for illustration purposes).  Pick something more random (like 1639 and 31649 or something).  Remember to list the second port first -- it's a "state machine".

Remember your router (to the server) has to allow these unconventional ports through, as well.  If they are blocked at the router, your iptables state machine will never see traffic to them.

As the iptables comments indicate, if you want to be paranoid and close the port from a location, all you need do is write to one of the port-knocking ports (e.g. 1234 or 5678). Heck, write to port 23232, if your router allows it through.  Any odd port will do.  The idea is to "reset" the state machine.  (It doesn't work to write to port 80 or port 443, in the above example.)

To close all locations in one fell swoop, simply restart iptables.

CONCLUSION:
Yes, you can use keys to keep creepy things from happening.  However, keys do not block access to port 22.  You WILL have log files filling up, just as you did when failed-passwords were occuring.  It also does not work to simply move ssh to another port, other than port 22.  Your log files will still fill up from the numerous port scanning bots that litter the Intenet.

iphitus

Forum Fellow

From: Melbourne, Australia

Registered: 2004-10-09

Posts: 4,927

Re: auth.log

Just a tip, if the other computer is internal, and you only access it via lan, block port 22 off to users not from your local network range, ie block users not from 192.168.1.x

iphitus

max_sipos

Member

From: Ithaca, NY

Registered: 2004-10-31

Posts: 106

Website

Re: auth.log

You can also use Judd Vinet's port knocking deamon (& client) knockd.

pacman -S knockd

It's easy to configure and you can do crazy things with port knocking.

nullpointer

Member

From: Canada

Registered: 2005-04-21

Posts: 8

Re: auth.log

But shouldn't my disabling password authentication stop people from trying to log in?  Anyway, using iptables gave me an idea so I used iptables to limit the number of connections from the same ip by doing this:

iptables --policy INPUT DROP

iptables --new-chain LOGIN_LIMIT

iptables --append LOGIN_LIMIT -m recent --set
iptables --append LOGIN_LIMIT -m recent --update --seconds 60 --hitcount 3 --jump LOG --log-level 5 --log-prefix "BLOCKED_LOGIN:"
iptables --append LOGIN_LIMIT -m recent --update --seconds 60 --hitcount 3 --jump DROP
iptables --append LOGIN_LIMIT --jump ACCEPT

iptables --append INPUT --protocol tcp --dport 22 -m state --state NEW --jump LOGIN_LIMIT

This should stop anyone from even attempting to connect more than twice per minute.  Port knocking seems interesting but I can't be sure that wherever I'll be when I want to connect to my box isn't blocking a certain outgoing port.

soloport

Member

Registered: 2005-03-01

Posts: 442

Re: auth.log

But shouldn't my disabling password authentication stop people from trying to log in?

It will prevent logins from succeeding.  However, alone it won't prevent access to port 22.  The point of the iptables-based port knocking is to prevent log files from filling up with useless informaiton.

There's also a knockd server you can use.  However, if you're already using iptables, the iptables-based port knocking requires one less package to maintain -- FWIW.

nullpointer

Member

From: Canada

Registered: 2005-04-21

Posts: 8

Re: auth.log

It will prevent logins from succeeding.  However, alone it won't prevent access to port 22.  The point of the iptables-based port knocking is to prevent log files from filling up with useless informaiton.

There's also a knockd server you can use.  However, if you're already using iptables, the iptables-based port knocking requires one less package to maintain -- FWIW.

Hey thanks!  I think I'm going use the port knocking technique in combination with my existing iptables.  That way if someone by chance does happen to open up the port by ending a port scan on the exact port that opens 22, it will at least limit their access to the port at a rate of twice per minute.