Re: securing sshd
On 21/03/10 02:27, Peter wrote: On the same line, portknocking with pf: Port knocking suck: If you have to knock a single time on the secret port you might just have no added security at all, could be that the port scanner first knocked on the secret port then on the ssh port. If you have to knock multiple times on the secret port, same thing, usually when you scan for open ports, multiple packets are sent in case of packet loss. You can't use timing between packets because this may change on the path. Yet you do need to implement timeouts to avoid a halfway knocked sequence. If you have to knock various ports, you can't rely on packets arriving in a particular sequence. And even if you did, the port scanner might just get that order right. If your secret is to knock port 1234 and then port 2345 nmap might do just that when scanning ports 0-1. And if the secret is the reverse order, again, nmap might just do that because multiple packets are sent to each port. If you require more than a single knock you have to monitor also for wrong knocks or a simple nmap scan may be just sufficient to expose your server as in the example above. A port knock or port knock sequence is a shared password that cannot be encrypted. Since there is no previous user identification the knocking is the same for all users. It's not encrypted because the secret is in the port number you knock. This is possibly the worst kind of secret you can manage. If you find yourself thinking you need port knocking, then your passwords are not strong enough. It is far better to use longer and more complex passwords: They are individual for each user and encrypted. Then you have the problem of monitoring established connections to flush the tables once a session is terminated. Port knocking adds complexity to your server, meaning more things can go wrong, and adding yet another attack vector for the intruder. Having a script to automatically update a live rule set is a recipe for disaster. It's as unuserfriendly and impractical as it gets: The more ports you have to knock the higher the probability that some packets will be filtered when you're behind somebody else's firewall. You can be most certain that you can't convince the admin of some corporate network to open up for your port knocking. Because of the build in stealth you have no way of knowing if packets are dropped or filtered. And the user will have to accept a delay for your port knocking script to update the rules. You add complexity for the user, now they have your special port knocking client, know the secret, on top of carrying around their private ssh keys etc. Port knocking suck at security: It does not solve a single existing problem but introduces a host of other problems. Use it at home for playing around and learning about protocols and stuff, but please don't give people the illusion that their security problems will be solved with port knocking. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
securing sshd
Hello I've been reading up on securing sshd after being bombarded with attempted logins. The steps i've taken so far to make things more secure are: * changed the encryption method for passwords in /etc/login.conf from md5 to blowfish and changed all the passwords to ridiculously obscure ones (at least as obscure as I could think of). * changed /etc/ttys secure entries to insecure to prevent root logins on the console (the above are not really sshd specific i know.) * Disabled root login by ssh in /etc/ssh/sshd_config * Set myself as the only user able to login by ssh * Disabled password logins completely, and to only allow public key authentication * Changed the default ssh port from 22 to something much higher I'm the only user that will ever need to log into the machine. I wondered, does this setup seem ok and are there any other methods used by anyone on list that might help me to secure remote logins even further? Thanks for any help. Jamie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
On 20/03/10 14:18, Jamie Griffin wrote: I've been reading up on securing sshd after being bombarded with attempted logins. Hi! First step to ssh security is: Don't panic! Take your time to read the logs and understand what's going on. So, you've got bombarded with login attempts, but they failed. Just because there is some log entry doesn't mean you have to act on it. I recall reading an analysis of this kind of brute force attacks on securityfocus.com. These brute force attacks are pretty harmless if you've got basic security in place. This was also discussed on the list two weeks ago, check the archives. * Disabled root login by ssh in /etc/ssh/sshd_config Good, if you read the logs you will see that about 50% of the attempts are against the root account. * Set myself as the only user able to login by ssh Good, if you read the logs you will see that about 40% of the attempts are against standard unix accounts, and guest. The remaining are against randomly generated user names usually based on common names (john, smith, etc) you can get this statistic from your logs. * Disabled password logins completely, and to only allow public key authentication This seems good for security, but not always practical. Now you have to walk around with a USB or have keys on your laptop and if you loose the USB or the laptop gets stolen you can't get access. Worse, you can't revoke the keys till you get back home. * Changed the default ssh port from 22 to something much higher Number is irrelevant and I discourage this. If you ever find yourself behind somebody else's firewall, if access is enabled it is enabled for the default port. I'm the only user that will ever need to log into the machine. I wondered, does this setup seem ok and are there any other methods used by anyone on list that might help me to secure remote logins even further? Since you're the only one on that system, you know where you're going to connect from, at least roughly. Why allow connections from anywhere? Restrict the client access to certain ranges of IPs. The different registries publish ip ranges assigned per country and you can create a list blocking countries you are certain not to visit, you can use my script: http://www.locolomo.org/pub/src/toolbox/inet.pl The last things I can think of is not to have your user name as in your mail address, not have mail password as your unix account password and remember to password protect your ssh keys. Run other services such as mail, http, dns etc. in jails - if possible separate jails. All this all depends on your paranoia. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
On Sat, 20 Mar 2010 16:32:28 +0100 Erik Norgaard norga...@locolomo.org articulated: * Disabled password logins completely, and to only allow public key authentication This seems good for security, but not always practical. Now you have to walk around with a USB or have keys on your laptop and if you loose the USB or the laptop gets stolen you can't get access. Worse, you can't revoke the keys till you get back home. Worse yet, if you get shot and killed you won't be able to access your data no matter how hard you try. Seriously, disabling password log-ins and using key authentication is extremely secure. Do make sure that you password protect your keys however. In any event, if you laptop or whatever is stolen, you have more than just one problem to contend with anyway. -- Jerry ges...@yahoo.com Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ It's not whether you win or lose, it's how you place the blame. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
On Saturday 20 of March 2010 18:14:17 Jerry wrote: On Sat, 20 Mar 2010 16:32:28 +0100 Erik Norgaard norga...@locolomo.org articulated: * Disabled password logins completely, and to only allow public key authentication This seems good for security, but not always practical. Now you have to walk around with a USB or have keys on your laptop and if you loose the USB or the laptop gets stolen you can't get access. Worse, you can't revoke the keys till you get back home. Worse yet, if you get shot and killed you won't be able to access your data no matter how hard you try. Seriously, disabling password log-ins and using key authentication is extremely secure. Do make sure that you password protect your keys however. In any event, if you laptop or whatever is stolen, you have more than just one problem to contend with anyway. Another thing you could do is perhaps to secure your sshd using a program like sshguard. This is another measure you could take against brute force attack to your ssh. Elias ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
On 20/03/10 17:14, Jerry wrote: Seriously, disabling password log-ins and using key authentication is extremely secure. Do make sure that you password protect your keys however. In any event, if you laptop or whatever is stolen, you have more than just one problem to contend with anyway. I don't doubt that it is much harder to brute force a key than a password. I simply say that it is not always practical. Anyone stealing or finding your usb or laptop will likely not be too interested in your data. But, now you have to carry the key and protect it. If you travel a lot, and travel light, you bring just a usb stick which is easily lost, and being without access for months is not fun. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
Jamie Griffin ja...@fantomatic.co.uk writes: Hello I've been reading up on securing sshd after being bombarded with attempted logins. The steps i've taken so far to make things more secure are: * changed the encryption method for passwords in /etc/login.conf from md5 to blowfish and changed all the passwords to ridiculously obscure ones (at least as obscure as I could think of). * changed /etc/ttys secure entries to insecure to prevent root logins on the console (the above are not really sshd specific i know.) * Disabled root login by ssh in /etc/ssh/sshd_config * Set myself as the only user able to login by ssh * Disabled password logins completely, and to only allow public key authentication * Changed the default ssh port from 22 to something much higher I'm the only user that will ever need to log into the machine. I wondered, does this setup seem ok and are there any other methods used by anyone on list that might help me to secure remote logins even further? Hi, I'm using the following pf snippet in order to protect myself and my system's logs against brute force attemps on sshd: # # Block them all # block log quick from bruteforce_ssh # # connection rate the incoming ssh connections and fill the bruteforce # table # pass in log inet proto tcp from any to any port = 22 \ flags S/SA keep state \ (max-src-conn 10, max-src-conn-rate 5/4, \ overload bruteforce_ssh flush global) For more information on how this works, take a look at pf.conf(5). I don't know if it's complete (or even good practice), but a) I think it works for me and b) it does not depend on a port-provided solution. Thanks for any help. Jamie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
I think on reflection I might have been a little over the top with blocking password logins and I think the point about carrying a key on a usb stick, etc, is a very good one. The reason I went with that decision is because I only expect to be logging in to the server from two locations: at home or from a computer at my university, where the public key can be kept in the accounts I use at each location. Also, there are no other users loggin into it so it won't be too much of a problem doing it this way, i hope. When I saw hundreds of failed login attemps I panicked a bit i think :-) I really like the pf option and have just set up a similar rule actually, which i think will work well because i've also got it working with spamd to greylist inbound mail, as recommended by someone on this list the other day. Really appreciate all the good advice though, thanks. Jamie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
On 20/03/10 18:23, Jamie Griffin wrote: The reason I went with that decision is because I only expect to be logging in to the server from two locations: at home or from a computer at my university In that case, the best thing you can do is figure out the IP ranges of either location. Check your log for your own successful logins to find the source IP, then look up the range with whois. You can be pretty sure that wherever you are on campus, the assigned IP will be in that range. Then just allow access from those ranges and block everything else in your firewall. Whitelists are far easier to manage than black lists. Having some daemon running to monitor illicit attempts to login and block the source is futile. You can be almost certain that you won't see that IP in your logs again, partly because these attempts may come from botnets, partly because the source may be assigned IP dynamically. Btw. I found two articles on securityfocus.com, the first is analysis using a honeypot, as you see these attacks are pretty lame: http://www.symantec.com/connect/articles/analyzing-malicious-ssh-login-attempts Then somebody having to respond, because security was pretty lame: http://www.symantec.com/connect/articles/responding-brute-force-ssh-attack?ref=rss BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
In that case, the best thing you can do is figure out the IP ranges of either location. Definately a good idea, thanks Eric. Btw. I found two articles on securityfocus.com, the first is analysis using a honeypot, as you see these attacks are pretty lame: http://www.symantec.com/connect/articles/analyzing-malicious-ssh-login-attempts Then somebody having to respond, because security was pretty lame: http://www.symantec.com/connect/articles/responding-brute-force-ssh-attack?ref=rss Thanks for posting those links, interesting information there. Jamie ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: securing sshd
Jamie Griffin ja...@fantomatic.co.uk writes:
Hello
I've been reading up on securing sshd after being bombarded with
attempted logins.
The steps i've taken so far to make things more secure are:
* changed the encryption method for passwords in /etc/login.conf from
md5 to blowfish and changed all the passwords to ridiculously obscure
ones (at least as obscure as I could think of).
* changed /etc/ttys secure entries to insecure to prevent root logins on
the console
(the above are not really sshd specific i know.)
* Disabled root login by ssh in /etc/ssh/sshd_config
* Set myself as the only user able to login by ssh
* Disabled password logins completely, and to only allow public key
authentication
* Changed the default ssh port from 22 to something much higher
I'm the only user that will ever need to log into the machine. I
wondered, does this setup seem ok and are there any other methods used
by anyone on list that might help me to secure remote logins even
further?
Hi,
I'm using the following pf snippet in order to protect myself and my
system's logs against brute force attemps on sshd:
#
# Block them all
#
block log quick from bruteforce_ssh
#
# connection rate the incoming ssh connections and fill the bruteforce
# table
#
pass in log inet proto tcp from any to any port = 22 \
flags S/SA keep state \
(max-src-conn 10, max-src-conn-rate 5/4, \
overload bruteforce_ssh flush global)
For more information on how this works, take a look at pf.conf(5).
I don't know if it's complete (or even good practice), but a) I think it
works for me and b) it does not depend on a port-provided solution.
Thanks for any help.
Jamie
On the same line, portknocking with pf:
.
..
...
# Table for allowed IPs
# [gets auto populated via portknocking]
table portknock_ssh persist
.
..
...
block #default block policy
# Allow everyone to hit 'any' on port '1234' - pf proxies tcp connection
# [if not using 'synproxy', the connection is never established to
#'overload' the rule]
# 5 attempts in 15 seconds
pass in log quick proto tcp from any to any port {1234} synproxy state \
(max-src-conn-rate 5/15, overload portknock_ssh)
#Allow IPs that have been 'overload'ed into the portknock_ssh table
pass in log quick proto tcp from {portknock_ssh} to any port {ssh}
.
..
...
Although ssh is blocked from all except some trusted IPs, you can still
always have access, just have to knock first.
]Peter[
Then put a crontab on a per needed basis to expire all IPs in that table
that have not been referenced in 60 seconds:
* *** * /sbin/pfctl -vt portknock_ssh -T expire 60
All established sessions will be kept alive, all new sessions will need to
portknock after the IP is cleared from table
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
