Subject : Re: LUG: RoadRunner residential subnet mask IP filtering
From : "Kyle Bolton" <kabolton@ncsu.[redacted]>
Date : Wed, 23 Dec 2009 01:48:34 -0500
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/
Replies :