locking down ssh

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?

Reply to
brenda
Loading thread data ...

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.

Reply to
Nicholas DePetrillo

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.

Reply to
Eirik Seim

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.