openssh concerns

[Daniel Bond]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20091005/0da33ae1/PGP.pgp