[lug] Attaching with non-static IPs

gordongoldin at aim.com gordongoldin at aim.com
Tue Nov 20 12:42:37 MST 2007



 





I tried to login to my server remotely from my folks

house the other day based upon the external ip address

of their qwest dsl router which I had taken note last

time I visited.  This visit, their ip address had

changed and I was locked out of my server.  After some

periodic checking over a couple of days, it appears

qwest must be expiring the ip lease on their router on

a regular basis or some other scheme.



 



I have this same problem.? I have to open a range of addresses, so that local Boulder Quest people can get to the server.? So the attack has to come from the Denver area.? At least Korea and Nigeria are off the list :-) Amazing the difference in traffic...

On security, the "cheap" IP addresses may be more secure.? Some providers make them "non-addressable", traffic is not passed on to that IP unless the session is started by that IP.

I have to put a VPN on the "cheap" servers so they attach to me. 
?If they had a static IP, no need, it was easy.

Here is good feedback on security:

??? How about changing SecureShell off of port 22?

>>>>Well, if the goal is to "reduce attack messages" then the focus is all
wrong. The goal should be to mitigate the risk of a successful attack.

I've done this in a few places and it certainly helps with the
automated scripts that try guessable passwords for common user
accounts. It should always be considered a second.. or third.. or
fourth line of defense, however. In general, you should:

1) Use password cracking software (like john the ripper) on your
shadow file on a regular basis
2) Evaluate user accounts occasionally to make sure they should exist at all.
3) Consider restricting which accounts can log in via ssh
4) Consider moving to public key authentication only, if possible
5) Make sure that root logins via SSH are not allowed
6) Consider restricting what hosts can connect (either via
tcpwrappers, which is natively supported by OpenSSH, or via iptables).
This may not be practical, depending on the environment.

Then, and only then, does it make sense to move SSH to a different port.

- Ben

Additionally there's a few utilities out there to automate #6... 
DenyHosts or Fail2Ban are ones that are readily packaged for 
Debian-esque systems.






________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20071120/066c1674/attachment.html>


More information about the LUG mailing list