Results 1 to 9 of 9
Well, I finally got my games server up an running on it's own static IP address, outside the firewall and utterly clamped down. It only has two ports open, 5121 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-22-2006 #1
sshd, security, and break-in attempts
The problem I'm experiencing is probably very common. sshd is configured to reject all connection attempts unless they're using my RSA2 key; all passwords are rejected, and root login is turned off.
In /var/log/secure, however, I get lots of this kind of rubbish:
Mar 21 20:01:11 nwn sshd: Illegal user ldap from ::ffff:220.127.116.11 Mar 21 20:01:12 nwn sshd: Illegal user netdump from ::ffff:18.104.22.168 Mar 21 20:30:08 nwn sshd: Illegal user test from ::ffff:22.214.171.124 Mar 21 20:30:08 nwn sshd: Illegal user test from ::ffff:126.96.36.199
What (other than posting their IP addresses to a public forum such as this one) can be done?
Is it possible to intercept such attack lines with a script, route the IP through 'whois' and send an automated report to their 'abuse@...' address for their ISP?
Is it possible to clamp down on these by limiting connections in IPtables to known IP addresses (I only ever connect from my primary static IP address anyway...)? This is an FC4 box, and I used the firewall tool (system-config-security) to turn off all access except ssh and the above mentioned port.
Is it possible (and this is my fave) to intercept multiple connection attempts, and immediately fire-back a stream of packets that melts their hard disk, fries their processor and video card, and sets fire to their monitor?
A few pointers here would be much appreciated.
- 03-22-2006 #2
- Join Date
- Jan 2006
if you set your INPUT policy to DROP and just add a -j ACCEPT rule for each ip you want to be allowed access to your ports you shouldn't see any of that rubbish anymore.
iptables -P INPUT DROP
iptables -A INPUT -s <allowed_ip> -p tcp --dport <allowed_port> -j ACCEPT
- 03-22-2006 #3
Thanks for the quick reply, marlowe.
Surely that change will prevent access to my public game server on port 5121 unless I know the IP of the people that are connecting? I think the solution is a little more complex than that.
Also, as I only have ssh access to the box (without digging it out of its hole in the basement) I'd rather not set the INPUT policy to DROP without first defining all the necessary rules. Any more pointers on how to do this?
- 03-23-2006 #4
- Join Date
- Apr 2005
You could be a bit more creative and use something like Port Knocking to secure your SSH connection.
basically with port knocking the SSH port is CLOSED. the only way to access it is to 'knock' (make connection attempts) specific ports in a specific order, at which point the SSH port will open up and allow you to connect to it..
If you don't know the 'secret handshake' you can't even find the door so to speak.
- 03-23-2006 #5
But why would you want to use the default port (22) for ssh? That's very unsecure."To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
- 03-23-2006 #6Originally Posted by antidrugue
Thanks to all for your help.
- 03-23-2006 #7
Well, sorry then. I realize that is not the whole solution.
I just think of security as layers, and not using default port is generally a good idea.
I have 3 machines running sshd, none of them on default port, never had a breaking attemp."To express yourself in freedom, you must die to everything of yesterday. From the 'old', you derive security; from the 'new', you gain the flow."
- 03-24-2006 #8
- Join Date
- Jan 2006
hmm...i thought only you were supposed to use it. i wouldn't have recommended that policy thing otherwise.
how about just dropping all connections to ssh and allowing just one ip?
iptables -A INPUT -s <your_ip> -p tcp --dport <ssh> -j ACCEPT
iptables -A INPUT -s 0/0 -p tcp --dport <ssh> -j DROP
- 03-27-2006 #9
You may want to try this as well...
From their site:
DenyHosts is a script intended to be run by Linux system administrators to help thwart ssh server attacks. If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system?
DenyHosts attempts to address the above..."If you are out to describe the truth leave elegance to the tailor."