openssh concerns

[johnea]

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@...:/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

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Stef Walter]

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
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Garrett Wollman-6]

<<On Thu, 01 Oct 2009 17:13:55 -0700, johnea <me@...> 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
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[johnea]

Garrett Wollman wrote:

> <<On Thu, 01 Oct 2009 17:13:55 -0700, johnea <me@...> 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

Thank You to everyone who responded!

In fact I did discover these lines in hosts.allow:

31-# Protect against simple DNS spoofing attacks by checking that the
32-# forward and reverse records for the remote host match. If a mismatch
33-# occurs, access is denied, and any positive ident response within
34-# 20 seconds is logged. No protection is afforded against DNS poisoning,
35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS
36-# pass this rule.
37:ALL : PARANOID : RFC931 20 : deny

This is what was generating the auth protocol socket.

I've disabled it to prevent the establishment of the auth socket to hosts
who are attempting to breakin.

Per another suggestion I also intend to change the port for ssh to a
non-standard number (after synchronizing with the users of course 8-)

Maybe I'm a little paranoid, but after watching the level of spam ever
increasing over the last 5 years, and more and more people moving to
big (monopolistic?) service providers like google and hotmail. I've
wondered if these big corporate service providers don't tolerate the
spam level in order to prevent anyone who doesn't have a building full
of IT staff from running their own mail servers.

Perhaps with the help of people like those on this list, the internet
won't have to be abandoned by independents?

Thanks again to everyone!

johnea
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[István-3]

Protect against simple DNS spoofing attacks by checking that the...


So if the ssh bruteforce is coming from a properly setup DNS host it is ok


:))))
On Fri, Oct 2, 2009 at 4:28 PM, johnea <me@...> wrote:

> Garrett Wollman wrote:
>
>> <<On Thu, 01 Oct 2009 17:13:55 -0700, johnea <me@...> 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
>>
>
> Thank You to everyone who responded!
>
> In fact I did discover these lines in hosts.allow:
>
> 31-# Protect against simple DNS spoofing attacks by checking that the
> 32-# forward and reverse records for the remote host match. If a mismatch
> 33-# occurs, access is denied, and any positive ident response within
> 34-# 20 seconds is logged. No protection is afforded against DNS poisoning,
> 35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS
> 36-# pass this rule.
> 37:ALL : PARANOID : RFC931 20 : deny
>
> This is what was generating the auth protocol socket.
>
> I've disabled it to prevent the establishment of the auth socket to hosts
> who are attempting to breakin.
>
> Per another suggestion I also intend to change the port for ssh to a
> non-standard number (after synchronizing with the users of course 8-)
>
> Maybe I'm a little paranoid, but after watching the level of spam ever
> increasing over the last 5 years, and more and more people moving to
> big (monopolistic?) service providers like google and hotmail. I've
> wondered if these big corporate service providers don't tolerate the
> spam level in order to prevent anyone who doesn't have a building full
> of IT staff from running their own mail servers.
>
> Perhaps with the help of people like those on this list, the internet
> won't have to be abandoned by independents?
>
> Thanks again to everyone!
>
> johnea
> _______________________________________________
> freebsd-security@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@...
> "
>

--
the sun shines for all
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Tod McQuillin]

On Fri, 2 Oct 2009, johnea wrote:

> Maybe I'm a little paranoid, but after watching the level of spam ever
> increasing over the last 5 years, and more and more people moving to
> big (monopolistic?) service providers like google and hotmail. I've
> wondered if these big corporate service providers don't tolerate the
> spam level in order to prevent anyone who doesn't have a building full
> of IT staff from running their own mail servers.

As recently as last month I was thinking along the same lines, but now
that I have installed a greylisting spam filter (mail/spamd from ports)
spam is down to extremely manageable levels on my home mail server.

With a little time spent configuring your world, there is still room for
do-it-yourself admins with small networks.
--
Tod
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Ian Smith-12]

On Fri, 2 Oct 2009, johnea wrote:
 > Garrett Wollman wrote:
[..]
 > > > tcp4       0      0 atom.60448             host154.advance.com.ar.auth
 > > > TIME_WAIT
 > >
 > > "auth" is the port number used by the IDENT protocol.
 > >
 > > -GAWollman
 >
 > Thank You to everyone who responded!
 >
 > In fact I did discover these lines in hosts.allow:
 >
 > 31-# Protect against simple DNS spoofing attacks by checking that the
 > 32-# forward and reverse records for the remote host match. If a mismatch
 > 33-# occurs, access is denied, and any positive ident response within
 > 34-# 20 seconds is logged. No protection is afforded against DNS poisoning,
 > 35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS
 > 36-# pass this rule.
 > 37:ALL : PARANOID : RFC931 20 : deny
 >
 > This is what was generating the auth protocol socket.
 >
 > I've disabled it to prevent the establishment of the auth socket to hosts
 > who are attempting to breakin.
 >
 > Per another suggestion I also intend to change the port for ssh to a
 > non-standard number (after synchronizing with the users of course 8-)

This will provide the greatest relief against drive-by ssh probes, which
are pretty much background radiation these days.  Some may decry it as
'security by obscurity', but who cares when it works so effectively :)

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.

cheers, Ian
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Patrick Proniewski]

> This will provide the greatest relief against drive-by ssh probes,  
> which
> are pretty much background radiation these days.  Some may decry it as
> 'security by obscurity', but who cares when it works so effectively :)

against script kiddies and bots, obscurity is good.


> 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.

/etc/services is a good start too :)

patpro

[Dag-Erling Smørgrav]

Ian Smith <smithi@...> writes:
> 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)

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[olli hauer]

>> 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

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Eric Williams-6]

On 10/3/2009 7:18 AM, olli hauer wrote:

>>> 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

The absolute best way to filter out the attacks is to disable
authentication methods other than public keys. Obviously this isn't
possible in all situations, but it's very effective. Most attack bots
will just disconnect when they attempt login, and it's almost impossible
to crack a key and gain access.

[Daniel Bond-3]

Hi,

as long as one uses good passwords, or disable authentication with  
passwords and only authorize using SSH-keys, you should be fine, if  
you can survive a little spam in your system logs.

Personally I tend to either firewall the OpenSSH daemon, or leave it  
wide open. I don't really see the point in changing ports, as long as  
they are still publicly available. However,
I'm concerned about the suggestion of using an unprivileged port (I  
see port 8080 suggested in earlier mails).

If you really do need to use a unprivileged port, one solution could  
be rewrite the port-number with a NAT redirect, so NAT forwards to a  
privileged port.

The reason for this, is that any local user is capable of binding to  
unprivileged ports. If for some reason, a local user/attacker is able  
to crash the OpenSSH daemon process, or bind to the socket before the  
sshd(8) does,
the attacker can install an "evil sshd", to capture information about  
keys and passwords. Not all users care about host-key warnings.

One workaround may be to create a special rule for sshd, with  
mac_portacl(4), so only sshd can bind to port 8080, or whatever. ( http://www.freebsd.org/doc/en/books/handbook/mac-portacl.html 
  ).


Best regards,


Daniel Bond.




On Oct 3, 2009, at 10:39 PM, Eric Williams wrote:

> On 10/3/2009 7:18 AM, olli hauer wrote:
>>>> 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
>
> The absolute best way to filter out the attacks is to disable
> authentication methods other than public keys. Obviously this isn't
> possible in all situations, but it's very effective. Most attack bots
> will just disconnect when they attempt login, and it's almost  
> impossible
> to crack a key and gain access.
>

[Marian Hettwer]

Hej All,

olli hauer schrieb:

>>> 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
>
>  

I think nobody mentioned the overload rules from pf(4). I keep away most
of the tried attempts by using it.
Setup is pretty easy:
table <ssh-spammer> persist
pass quick log proto { tcp, udp } from any to any port ssh label
"ssh-brute" \
        flags S/SA keep state \
        (max-src-conn 15, max-src-conn-rate 10/30, \
        overload <ssh-spammer> flush global)

Obviously, read pf.conf(5) to check what you might want to configure WRT
max-src-conn and max-src-conn-rate.

These rules in combination with enforced key authentication should keep
your logfiles clean and your host secured.
No need to go to another tcp port.

Cheers,
Marian
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> Personally I tend to either firewall the OpenSSH daemon, or leave it  
> wide open. I don't really see the point in changing ports, as long as  
> they are still publicly available.

The ssh bots only seem to probe port 22.  In well over a year of
running my ssh servers on a different (very low numbered) port I
haven't logged a single probe (across about a dozen highly visible
servers).

--lyndon

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Andrew Kuriger]

On Mon, 5 Oct 2009 12:03:44 -0600, Lyndon Nerenberg - VE6BBM/VE7TFX
<lyndon@...> wrote:

>> Personally I tend to either firewall the OpenSSH daemon, or leave it  
>> wide open. I don't really see the point in changing ports, as long as  
>> they are still publicly available.
>
> The ssh bots only seem to probe port 22.  In well over a year of
> running my ssh servers on a different (very low numbered) port I
> haven't logged a single probe (across about a dozen highly visible
> servers).
>
> --lyndon
>

I personally don't use it (although I'm considering it), but you could
look into port knocking. Changing the port that SSHD binds to definitely
falls under that obscurity line since if somebody is targeting you, they
very well may run a SYN scan (Mmm namp) and read the banners to quickly
find out what port you are running sshd on, then target bots accordingly.
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.

Andrew

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Mark Boolootian]

There's always fwknop:  http://www.cipherdyne.org/fwknop/
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> 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.

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Micheas Herman]

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@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."


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

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Andrew Kuriger]

On Mon, 05 Oct 2009 13:02:46 -0700, Micheas Herman <m@...> wrote:

> 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.
>        

I agree its not a bad thing to have sshd running on a non-standard port,
but just wait until the bot herder with 10,000 bots under his control finds
out what port your running it under...

If your receiving 40,000 false logins a day, your either targeted, or
extremely popular and probably shouldn't be running sshd that is accessible
via the internet anyways, aside from port knocking/VPN. I don't know about
you, but when I have been attacked its not 100 connections from the same
IP, its thousands randomly throughout the world.

It does however eliminate the background script kiddie noise and sshd
scanners, but once your found out/targeted its all in the air anyways.

-Andrew
--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[erikcederstrand]

Den 05/10/2009 kl. 22.55 skrev Andrew Kuriger:

> I agree its not a bad thing to have sshd running on a non-standard  
> port,
> but just wait until the bot herder with 10,000 bots under his  
> control finds
> out what port your running it under...

It's like spam filtering: at the time this actually becomes a problem,  
we change tactics. It's not about finding the perfect solution, it's  
about having a manageable log. My log is being spammed, and changing  
the port solves that. "botnet-12-34-56-78.couldntcareless.mx tried to  
log into your nonexistent oracle account" is not a very interesting  
log message. Someone bruteforcing a valid non-trivial account name on  
a non-standard port is, even though they will never succeed.

> If your receiving 40,000 false logins a day, your either targeted, or
> extremely popular and probably shouldn't be running sshd that is  
> accessible
> via the internet anyways, aside from port knocking/VPN.

6 normal, very boring colo-servers here. 40.000 login attempts a day  
per server on port 22 sounds about right - that's still almost nothing  
translated to bandwidth. I use only key-based auth and the bots were  
still trying, som I'm pretty sure it's just someone trying to  
bruteforce every IP under the sun looking for low-hanging fruit. I  
still need ssh access for normal admin work so disabling ssh is not an  
option.

Erik