locking down ssh

Jan 31, 2006 2 Replies

Hi,



I am trying to lock down my pc connection to the internet



1) I have a nating router, with only port 22 open
2) The ssh server in on a fedora core 4 stock
3) I run yum nightly for updates
4) the windows pc's are all running norton antivirus
5) in the sshd_config file I did the following:

# $OpenBSD: sshd_config,v 1.70 2004/12/23 23:11:00 djm Exp $



# This is the sshd server system-wide configuration file. See # sshd_config(5) for more information.



# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin



# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value.



#Port 22 #Protocol 2,1 Protocol 2 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::



# HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key



# Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768



# Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO # Authentication: AllowUsers brenda@remoteip AllowUsers brenda@192.168.3.*



#LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6



#RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys



# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes



# To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no PasswordAuthentication yes



# Change to no to disable s/key passwords #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no



# Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no



# GSSAPI options #GSSAPIAuthentication no GSSAPIAuthentication yes #GSSAPICleanupCredentials yes GSSAPICleanupCredentials yes



# Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no #UsePAM no UsePAM yes



#AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #ShowPatchLevel no



# no default banner path #Banner /some/path



# override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server



Is there anything else I can do to lock the system down?


Just a few easy suggestions.

You could turn on "MaxAuthTries" so that brute force attempts have to wait a while. Other than using SSH keys with paraphrases you should be pretty solid.

Do you read the logs? Or even any system/security logs? You'd be surprised how many who don't do that.

If you only need to access your server from a specific remote ip address, you could (should!) block all others in your fw/router. Also, consider the threat if someone took control of your server. If protecting the rest of your internal computers is a priority, the server offering services to the world should be in a separated environment (DMZ).

Do you need this?

Consider adding a banner with a suitable threathening message.

No matter how hard we try, there is always possible to do better. Some wise man once said something I remember as "Once you've got foolproof security, a more creative fool comes along". The message basically is the same as always: Security is a process. If you do it right, you're never done.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required