forum.excito.org

I agree with Ubi, you have several options, and all are covered in this thread:
- Disable ssh from outside
- Change the port number
- Use denyhost/fail2ban or similar
- Use good usernames and passwords.

I must add this though:
I was once the target of a distributed ssh attack. Why anyone would be interested in my machine is anyone's guess, but I sat and watched auth.log with tail all day and saw a typical dictionary attempt, but distributed:
- All the attempts came from different addresses
- Even so, it was obviously the same attacker, because all the logins tried were in alphabetical order, and exactly 2 seconds apart

denyhost only responded when the addresses in the attacker's botnet had been reused 3 (or 5) times, and by this time they had already exhausted the dictionary they were using with the addresses that hadn't already been banned by denyhost..

I guess if I had used fail2ban when this happened, the iptables rules might have grown enormous...
But it has only happened once. And anyway - even if they find a valid login, they will still need a password (unless you have been careless with your ssh keys)

Cheeseboy wrote:I agree with Ubi, you have several options, and all are covered in this thread:
- Disable ssh from outside
- Change the port number
- Use denyhost/fail2ban or similar
- Use good usernames and passwords.

You forgot one:
- limit the addresses that can connect in the first place

Correct!
And of course: OpenVPN.

how is openvpn more secure than key-based SSH?

Ubi wrote:how is openvpn more secure than key-based SSH?

It's not, just another alternative that was not discussed in the thread.

EDIT:
Actually, having thought about it for a minute: I think it is.
I use it every day to get access to my network at home. I still have to use ssh to get access to the b3 though.
And I access it by the name "b3", not it's public address.
Only "public" things are available to someone who manages to break into my network through OpenVPN.
Besides, it is soo much easier to use if you want resources like DHCP, DNS, etcetera than using ssh with -L or -D.

Never mind, I guess we have concluded:
If you want remote access, there are risks, but several ways to minimize them.

Working on my firewall to get rid of some bad boys I came across a neat little trick known as "knocking". Essentially what this means is that you have to do a "ping" on a specific sequence of other ports before being granted access to the actual intended port. Do anything different and the port will not show as open at all.

There's a good example here how to set that up: http://www.linuxri.org/articles/portkno ... thiptables

theres even a debian package, called knockd:
http://www.cyberciti.biz/faq/debian-ubu ... -tutorial/

http://www.portknocking.org/
http://en.wikipedia.org/wiki/Port_knocking

Yes, but I'm worried that knockd might expose itself because it essentially makes every port active and could thereby give a different response than would normally be the case with a reject or drop. I read a similar article about the TARPIT target being quite easy to identify for portscanners this way and obviously when showing what you're doing you're practically inviting those script kiddies to have a field day on your B3.

Really? I always thought that knockd worked on filtered ports (which are still sensed by iptables, but shown as filtered to the client). still, even if you expose the machine as knockd protected you still need the portknock combination. 4 port choices of a 65k set is still a lot better than the pin code on my atm card, and i dont see anyone having a field day with that.

From what I gather knockd sits in front of iptables - has to because you'd otherwise have to configure iptables to pass the knock ports and there's no mentioning of that in the howto. But honestly I don't know if it - I just think the iptables solution with the `recent` module looks nice and clean and also shouldn't disturb how the system responds to calling on "inactive" ports.