thr3ads.net - freebsd security - openssh concerns [Oct 2009]

If this information is useful, please help other people find it:
Share via:

johnea

2009-Oct-02 00:30 UTC

openssh concerns

Hello,

Sorry if this is dumb as ditch water but I just felt like I should ask.

I'm been running an independent host here for the last 5 years with
the usual toaster services:
http, smtp, and imap all using ssl and ssh for remote login.

I installed sshgaurd after dealing with the incessant brute force crack
attempts.

Lately I've been under ssh attack by a botnet with hundreds of IPs.

The thing that concerned me is an entry I saw in netstat showing
my system connecting back to a machine that was attempting to log
in to ssh.

This is where I may be a braindead noob, but is that normal?

Does the ssh server establish a socket to a client attempting login?

The details from netstat are below along with a bunch of other info
that seemed relevant.

Thank you so much for considering my question and for your work
on the FreeBSD project.

johnea

~~~~~~~~~~~~~~~~~~~~~~ issue information ~~~~~~~~~~~~~~~~~~~~~~
atom# openssl version
OpenSSL 0.9.8e 23 Feb 2007
atom# uname -a
FreeBSD atom.johnea.net 7.1-RELEASE-p6 FreeBSD 7.1-RELEASE-p6 #0: Tue Jun  9
16:26:47 UTC 2009    
root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

from netstat:

tcp4       0      0 atom.60448             host154.advance.com.ar.auth 
TIME_WAIT
tcp4       0      0 atom.ssh               host154.advance.com.ar.37833 
TIME_WAIT

from auth.log:

The same IP as above:
Oct  1 15:51:56 atom sshd[84887]: warning: /etc/hosts.allow, line 37: can't
verify hostname: getaddrinfo(host154.advance.com.ar, AF_INET) failed

Other example entries from auth.log:
Oct  1 13:45:55 atom sshd[82209]: error: PAM: authentication error for root from
222.211.93.81
Oct  1 13:47:14 atom sshd[82252]: error: PAM: authentication error for root from
217.77.72.115
Oct  1 13:47:29 atom sshd[82266]: error: PAM: authentication error for root from
60.170.80.198
Oct  1 13:48:23 atom sshd[82271]: error: PAM: authentication error for root from
201.26.169.150
Oct  1 13:49:11 atom sshd[82279]: error: PAM: authentication error for root from
200.36.249.22
Oct  1 13:50:11 atom sshd[82291]: error: PAM: authentication error for root from
80.152.227.160
Oct  1 13:50:47 atom sshd[82300]: error: PAM: authentication error for root from
80.108.8.74
Oct  1 13:51:38 atom sshd[82311]: error: PAM: authentication error for root from
58.60.106.119
Oct  1 13:52:27 atom sshd[82371]: error: PAM: authentication error for root from
200.36.249.22
Oct  1 13:53:21 atom sshd[82378]: error: PAM: authentication error for root from
74.218.172.158
Oct  1 13:54:05 atom sshd[82384]: error: PAM: authentication error for root from
220.248.9.163
Oct  1 13:54:55 atom sshd[82394]: error: PAM: authentication error for root from
58.60.106.199
Oct  1 13:56:31 atom sshd[82419]: error: PAM: authentication error for root from
222.128.48.222
Oct  1 13:57:22 atom sshd[82472]: error: PAM: authentication error for root from
83.65.166.74
Oct  1 13:58:20 atom sshd[82482]: error: PAM: authentication error for root from
81.244.253.110
Oct  1 13:59:02 atom sshd[82492]: error: PAM: authentication error for root from
76.12.185.151
Oct  1 13:59:49 atom sshd[82505]: error: PAM: authentication error for root from
200.41.97.213
Oct  1 14:00:00 atom newsyslog[82517]: logfile turned over due to size>100K

Oct  1 15:50:58 atom sshd[84875]: error: PAM: authentication error for root from
74.56.151.159
Oct  1 15:51:56 atom sshd[84887]: warning: /etc/hosts.allow, line 37: can't
verify hostname: getaddrinfo(host154.advance.com.ar, AF_INET) failed
Oct  1 15:51:58 atom sshd[84887]: refused connect from 200.51.40.154
(200.51.40.154)
Oct  1 15:52:49 atom sshd[84943]: warning: /etc/hosts.allow, line 37: can't
verify hostname: getaddrinfo(static.khi77.pie.net.pk, AF_INET) failed
Oct  1 15:52:49 atom sshd[84943]: refused connect from 221.120.201.71
(221.120.201.71)
Oct  1 15:53:43 atom sshd[84955]: error: PAM: authentication error for root from
196.211.146.154
Oct  1 15:54:30 atom sshd[84964]: error: PAM: authentication error for root from
74.239.115.130
Oct  1 15:55:18 atom sshd[84990]: warning: /etc/hosts.allow, line 37: can't
verify hostname: getaddrinfo(mail.iesmos.ru, AF_INET) failed
Oct  1 15:55:19 atom sshd[84990]: refused connect from 217.147.21.166
(217.147.21.166)
Oct  1 15:55:53 atom sshd[84994]: error: PAM: authentication error for root from
80.152.227.160
Oct  1 15:57:39 atom sshd[85042]: error: PAM: authentication error for root from
124.232.131.156
Oct  1 15:58:32 atom sshd[85048]: error: PAM: authentication error for root from
83.65.166.74
Oct  1 15:59:12 atom sshd[85062]: error: PAM: authentication error for root from
218.204.223.214
Oct  1 16:00:01 atom sshguard[83827]: Got exit signal, flushing blocked
addresses and exiting...
Oct  1 16:00:01 atom sshguard[85089]: Started successfully [(a,p,s)=(4, 420,
1200)], now ready to scan.
Oct  1 16:00:03 atom sshd[85092]: warning: /etc/hosts.allow, line 37: can't
verify hostname: getaddrinfo(adsl3-pool

Stef Walter

2009-Oct-02 02:59 UTC

head link

openssh concerns

johnea wrote:> tcp4       0      0 atom.60448             host154.advance.com.ar.auth 
> TIME_WAIT
> tcp4       0      0 atom.ssh               host154.advance.com.ar.37833 
> TIME_WAIT
Your machine is, for some reason, connecting to the ident service on the
remote machine. This isn't done by default by openssh, as far as I know.

Cheers,

Stef

Garrett Wollman

2009-Oct-02 03:00 UTC

head link

openssh concerns

<<On Thu, 01 Oct 2009 17:13:55 -0700, johnea <me@johnea.net> said:
> The thing that concerned me is an entry I saw in netstat showing
> my system connecting back to a machine that was attempting to log
> in to ssh.
> Does the ssh server establish a socket to a client attempting login?
The SSH protocol does not, but you appear to be using "TCP wrappers"
(/etc/hosts.allow) configured in such a way that it make an IDENT
protocol request back to the originating server.  This is rarely
likely to do anything useful and should probably be disabled.
> tcp4       0      0 atom.60448             host154.advance.com.ar.auth 
TIME_WAIT
"auth" is the port number used by the IDENT protocol.

-GAWollman

olli hauer

2009-Oct-03 12:20 UTC

head link

openssh concerns

>> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>> provides a 
>> reasonably useful list of ports NOT to choose for an obscure ssh
>> port.
>
> In practice, you have no choice but to use someting like 443 or 8080,
> because corporate firewalls often block everything but a small number
> of
> ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and
> 8080
> go through a transparent proxy)
This may work if the firewall does only port and no additional protocol
filtering. For many products used in corporate envirion it is even
possible to filter ssh v1, skype, stunnel, openvpn with a verry high
success rate within the first packet's on the wire.

In case for the ssh server take a look into this parameters
- LoginGraceTime
- MaxAuthTries
- MaxSessions
- MaxStartups


--
olli

Micheas Herman

2009-Oct-05 20:26 UTC

head link

openssh concerns

On Mon, 2009-10-05 at 12:46 -0600, Lyndon Nerenberg - VE6BBM/VE7TFX
wrote:> > Granted, if somebody is not specifically targeting you and is just
scanning
> > ranges to find sshd on 22 they will pass you right up since that port
will
> > be closed.
> 
> The port change was intended only to avoid the port scanners.

        And when you get notices in your logs, you can respond, as you
        know you are being targeted and can take appropriate responses.
        
        The biggest reason I can see for running ssh on an non-standard
        port is increasing the signal to noise ratio in the logs.
        
        If you can investigate every failed ssh login, you should be
        safer than if you ignore 40,000 failed logins a day.
        
        Just my experience, but of course being able to effortlessly
        investigate 40,000 failed logins would probably be a better
        situation.
        
        > 
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
"freebsd-security-unsubscribe@freebsd.org"

-- 
Things past redress and now with me past care.
		-- William Shakespeare, "Richard II"

Edho P Arief

2009-Oct-08 17:24 UTC

head link

openssh concerns

On Fri, Oct 9, 2009 at 12:22 AM, Doug Barton <dougb@freebsd.org>
wrote:> Oliver Fromme wrote:
>> There are shell machines with lots of user accounts, none
>> of which have administrative control of the system.
>
> Sure there are, but they make up only a tiny fraction of the systems
> on the network today.
>
>
shared webhost?



-- 
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Bap

2009-Oct-08 18:24 UTC

head link

openssh concerns

Quoting Doug Barton <dougb@FreeBSD.org>:
> Oliver Fromme wrote:
>> There are shell machines with lots of user accounts, none
>> of which have administrative control of the system.
>
> Sure there are, but they make up only a tiny fraction of the systems
> on the network today.
wow
>
>
> Doug
>
> --
>
> 	Improve the effectiveness of your Internet presence with
> 	a domain name makeover!    http://SupersetSolutions.com/
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
>

Darren Reed

2009-Oct-18 03:31 UTC

head link

openssh concerns

If this hasn't been mentioned already, disable password logins
in sshd_config and require RSA authentication only.

I do this on all hosts I administer that are internet accessible
and it allows me to confidently ignore all of the password
guessing attacks, resulting in peace of mind.

Darren

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no

freebsd security - Oct 2009 - openssh concerns

openssh concerns

openssh concerns

openssh concerns

openssh concerns

openssh concerns

openssh concerns

openssh concerns

openssh concerns