5 ms·

Some notes from an InfoSec person. - Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattend

by tempfs 8y ago

Some notes from an InfoSec person. - Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattended-upgrades and reboots itself at least once a week.[could also be a minimal VM like AlpineOS if you need Gbps+ line speed] - Have this R-Pi and your network gear plugged into a UPS that can withstand at least a couple of hours of power outage. - Use non-standard ports on your perimeter FW for forwarding to the R-Pi. - Run fail2ban or something similar. Set a bantime of at least an hour[3600 sec] after no more than 5 attempts in 600 sec. This is mostly to discourage anyone who stumbles across your perimeter listening port.[which enough will] Password login will be disabled anyway, but a bot might not check for allowed auth types.[nmap -Pn -p 22 --script ssh-auth-methods <target>] - No passwords allowed in /etc/ssh/sshd_config[PasswordAuthentication no]. Use public key based authentication.[PubkeyAuthentication yes] Put the public SSH key[id_rsa.pub] of any machine that you wish to authorize into ~/.ssh/authorized_keys on your R-Pi. This way you can authorize and de-authorize remote machines[with particular users] at will. - add 'AllowUsers xxxx yyyy' to your /etc/ssh/sshd_config - No root logins allowed![PermitRootLogin no] - Maybe limit via perimeter or on the R-Pi which source IP ranges are allowed to access to SSH.[whitelisting] - Periodically review your logs of perimeter FW, R-Pi FW and /var/log/auth.log to see what's going on. It should be pretty quiet, but look at them anyway once a week. - Sleep well knowing that you have a simple, layered and robust defense strategy that also has power-event survivability. Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds. Don't use your perimeter device to host SSH services. It will not get patches fast enough when vulns come up.

rsync 8y ago
"Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds." I don't know how much it adds, but it is non-zero. The knockd daemon is rock solid[1] and your ssh port traffic goes down to zero (other than your own use). Port knocking has no place in security by itself but I think it's a wonderful addition to a layered defense - my favorite one, in fact.
- akira2501 8y ago
  I just use the firewall.. if you make more than 4 SSH connections inside of a minute you're blackholed for 5 minutes. Pretty much drops all automated scanners right on the floor while not adding any steps for normal use.
- bitbang 8y ago
  Try using fwknop. Similar concept to Port knocking, but much more secure.
- frankzinger 8y ago
  [1] http://www.zeroflux.org/projects/knock http://www.zeroflux.org/projects/knock
pdkl95 8y ago
> Use non-standard ports While I completely agree and encourage people to use all of your suggestions, this single step - not being on port 22 - has easily provided the most benefit. When sshd listened on port 22, I regularly saw attacks that would run through thousands of common passwords at high speed[1]. After moving to a random port, it was over a year before I saw another hostile login attempt. It may be easy to discover the server with a simple port scan, but in practice the attacks seem to focus on the easy targets. > fail2ban Fail2ban is great and highly configurable. I could accept having to manually reset occasional false positives, so my fail2ban will immediately (no retries) ban on the first use of anything that is known to be malicious such as any attempt to login as root with a password, asking to login with an account name like [admin, mysql, squid], or any apache access log matching /\/phpMyAdmin/, etc. [1] Several logins per second over ADSL could use a large fraction of the upload bandwidth.

by tempfs 8y ago

rsync 8y ago

"Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds." I don't know how much it adds, but it is non-zero. The knockd daemon is rock solid[1] and your ssh port traffic goes down to zero (other than your own use). Port knocking has no place in security by itself but I think it's a wonderful addition to a layered defense - my favorite one, in fact.

akira2501 8y ago
I just use the firewall.. if you make more than 4 SSH connections inside of a minute you're blackholed for 5 minutes. Pretty much drops all automated scanners right on the floor while not adding any steps for normal use.
bitbang 8y ago
Try using fwknop. Similar concept to Port knocking, but much more secure.
frankzinger 8y ago
[1] http://www.zeroflux.org/projects/knock http://www.zeroflux.org/projects/knock

pdkl95 8y ago

> Use non-standard ports While I completely agree and encourage people to use all of your suggestions, this single step - not being on port 22 - has easily provided the most benefit. When sshd listened on port 22, I regularly saw attacks that would run through thousands of common passwords at high speed[1]. After moving to a random port, it was over a year before I saw another hostile login attempt. It may be easy to discover the server with a simple port scan, but in practice the attacks seem to focus on the easy targets. > fail2ban Fail2ban is great and highly configurable. I could accept having to manually reset occasional false positives, so my fail2ban will immediately (no retries) ban on the first use of anything that is known to be malicious such as any attempt to login as root with a password, asking to login with an account name like [admin, mysql, squid], or any apache access log matching /\/phpMyAdmin/, etc. [1] Several logins per second over ADSL could use a large fraction of the upload bandwidth.