Index

Subject : Re: LUG: RoadRunner residential subnet mask IP filtering

From : Michael Wright <terminallyalive@gmail.[redacted]>

Date : Wed, 23 Dec 2009 02:31:42 -0500

Parent


It should be a simple matter of altering the line that says "Port XX" in /etc/ssh/sshd_config and restarting the sshd service. If you've done this and its still accepting traffic on port 22, double check the config doesn't have a second Port line elsewhere in the file.

If you're still having issues, perhaps check IPTables to see if its forwarding 22 to the new SSH port for whatever reason (a simple `iptables -L` would do it).

Hopefully those solutions help,
Michael Wright

On Dec 23, 2009, at 1:48 AM, Kyle Bolton wrote:

Sorry for the hijack, but Me being new to hosting a server, how do you kill port 22? I've got it set in sshd_config to use a nonstandard, but it's still allowing port 22 as well.
Kyle Bolton
CCNA-Cisco Certified Networking Associate
E115 Senior Instructor
ITECS EOS HelpDesk Consultant
North Carolina State University
From: lug-owner@lists.ncsu.[redacted] [mailto:lug-owner@lists.ncsu.[redacted]] On Behalf Of Michael Wright
Sent: Wednesday, December 23, 2009 1:37 AM
To: lug@lists.ncsu.[redacted]
Subject: Re: LUG: RoadRunner residential subnet mask IP filtering
I've seen the knocking solution implemented before, and its quite cool (and effective!). But I would start with the most basic of checks - are you running SSH on a non-standard port? I would imagine that would reduce your unwanted traffic dramatically.
If that still doesn't work well enough for you, you can always use IPIndex to list all IPs owned by TWC/Roadrunner (just search for "road runner" in the search menu), that would give you a more complete list, but its /very/ unorganized.
Michael Wright
On Dec 23, 2009, at 1:16 AM, Richard Carter wrote:


Ah well, I suppose if you have a specific need to monitor the log file and keep it pristine then manual filtering would be best. To each their own. :)

By the way, I previously said "after a few failed attempts at logging in as root, a machine is added to the iptables block list"; this is wrong. It blocks attempts at other users too; you can configure it to block after different numbers of tries for root, non-root but restricted, normal, and nonexistent users. And it monitors /var/log/secure and then adds entries to /etc/hosts.deny, not iptables. Just thought I'd clarify for anyone else who wants to look into it; it seems effective on my dedicated server, as it's blocked 57 hosts since I first installed it a few weeks ago and it hasn't locked me out yet. You can clearly see in /var/log/secure that the hosts try to connect X number of times and then are refused.

Anyway, Daniel, one more thing to try is to look up your IP address at arin.net (use the search box in the top-right if you're not familiar with it). The whois entry should have a NetRange which may or may not match the mask that your router has.

One more trick that you could look into is port knocking. Essentially, you close all ports. Then, when you want access, you "knock" on (i.e. send a packet to) a specific series of ports; the computer would hear the knocks but would not respond. But as soon as the series of ports matches a specific series, then a rule is added to the firewall to allow the knocker access. I'm not sure of the options as far as daemons that implement port knocking, but I'm sure a Google search for port knocking will reveal plenty of information on the subject. It might be your ideal solution, as it doesn't require knowing IP addresses ahead of time, and you can block everyone.

On Wed, Dec 23, 2009 at 12:05 AM, Daniel Underwood < daniel.underwood@ncsu.[redacted] > wrote:

> I presume you are filtering IP addresses to reduce the possibility of
> someone SSHing or brute forcing into your computer, correct?

Yes, correct.


> If this is the case, take a look at DenyHosts

I thought about using something similar called Fail2ban:
< http://www.fail2ban.org/wiki/index.php/Main_Page >


> If there is some other reason you're doing this, please share with me
> because I'd really like to know if I'm doing something wrong!

I think either solution would be fine, however, there is another reason.
My auth log file had thousands of failed ssh attempts (before
implementing bruteforce protection).  Using preset IP filtering will get
rid of virtually all these failed ssh attempts in the log file, whereas
the DenyHosts/Fail2ban methods will only reduce the number of failed ssh
attempts in the log file.  This makes log monitoring much easier,
because the log file is far less cluttered.
--

Daniel Underwood
North Carolina State University
Graduate Student - Operations Research
email: daniel.underwood@ncsu.[redacted]
phone: XXX.302.3291
web: http://www4.ncsu.edu/~djunderw/