Limit the number of erroneous logins of root from the same..

Luis_Gonçalves_ · External Since: Nov 14, 2011 Posts: 1

Dear All

There any way to limit the number erroneous logins of root from the
same IP? After the limit that IP can not try to login anymore.

The tries could be consecutive or during a day. After that no more
logins.

Thanks

Luis Gonçalves

Keith Keller · External Since: Jun 21, 2006 Posts: 516

On 2011-11-14, Luis Gonçalves wrote:
>
> There any way to limit the number erroneous logins of root from the
> same IP? After the limit that IP can not try to login anymore.
>
> The tries could be consecutive or during a day. After that no more
> logins.

Look at fail2ban or denyhosts (there are probably others as well).

--keith

--
kkeller-usenet.DeleteThis@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

unruh · External Since: Nov 14, 2011 Posts: 98

On 2011-11-14, Luis Gon?alves wrote:
> Dear All
>
> There any way to limit the number erroneous logins of root from the
> same IP? After the limit that IP can not try to login anymore.

Of course that could allow a denial of service attack--someone tries to
log in from an IP you want to use, and deny your login.
I assume that you are concerned about login attempts from people trying
to break in

Anyway, you could use /etc/hosts.allow
eg
sshd:111.222.333.444 222.333.444.111 ....:deny
to deny any ssh login from those IP addresses (Note you MUST make sure
that there are fewer than 128 addresses on any one line. The tcpwrapper suite has a bug
which causes it to loop forever if there are more. Venema refuses to fix
the bug. )

Eg run a script every 5 min via cron with
grep 'Failed password for root' /var/log/messages>$OUTPUT
for i in `awk '{print $11}' $OUTPUT|sort -u`
do
N=`grep "$i " $OUTPUT|wc -l`
if [ "$N" -gt 5 ]; then
if ! grep "$i " /etc/hosts.allow>/dev/null; then
/bin/ed /etc/hosts.allow 2>/dev/null <<EOF
/^sshd.*deny *$/s/:deny/ $i :deny/
wq
EOF
echo "Too many failed ssh root attempts from $i"
fi
fi
done

awk 'BEGIN{f=0}
$0~/sshd.*deny$/{match($0,/^sshd.*deny$/);s=RLENGTH;f=f+1 } s>1024 &&
f==1 {print "sshd: :deny";s=0} {print $0}' /etc/hosts.allow >/etc/hosts.allow$$
mv -f /etc/hosts.allow$$ /etc/hosts.allow
chmod a+r /etc/hosts.allow

>
> The tries could be consecutive or during a day. After that no more
> logins.
>
> Thanks
>
> Luis Gon?alves

dold · External Since: Jun 21, 2007 Posts: 8

Luis Goncalves wrote:
> There any way to limit the number erroneous logins of root from the
> same IP? After the limit that IP can not try to login anymore.

It is easy to block access from all addresses except for a few.
Or block all access from one IP or subnet.
That prevents the root login bots in certain countries from continuing to
attack your ssh port, as it seems they give only continue to try successful
ports.

You shouldn't allow remote root login. Log in as a normal user and su or
sudo to get the root permissions.

I block all ssh access, and then open it to the subnet where I have
an account. If you are logging in from a new hotspot, this scheme won't
work for you. In my case, I have an ISP account that I can always reach,
and from there I can log in to my machine.

# Flush all the rules.
iptables -F

# Block all attempts to log in via ssh
iptables -I INPUT -p tcp --dport 22 -j DROP
# Or drop all ssh access from an observed bad subnet
iptables -I INPUT -p tcp --dport 22 -j DROP -s 219.134.0.0/16

# Accept connections from my 3G Modem
iptables -I INPUT -p tcp --dport 22 -j ACCEPT -s 75.247.169.0/24

/sbin/service iptables save

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Mon, 14 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, Luis Gonçalves wrote:

> There any way to limit the number erroneous logins of root from the
>same IP? After the limit that IP can not try to login anymore.

Why are you allowing root to log in over the net? MAJOR security
hazard in that. As of last month, there were 3391480528 IPv4 addresses
allocated/assigned to the world. Do you _REALLY_ need to allow access
from every one? Fix your firewall rules to _only_ allow connections
from addresses you have some reason to believe you WANT to have connect.

>The tries could be consecutive or during a day. After that no more
>logins.

They are called "Self Denial Of Service" applications. There are three
things you should consider before trying to use one:

1) most cracker attacks come from zombie computers, and there are
several billion of those out on the net.
2) ever look at the performance of your filter/firewall when it has
a thousand rules to deal with?
3) be careful about reacting to spoof attacks.

On the latter, I've seen idiots trying to spoof login attempts from
infrastructure IP addresses (like our name servers) in the hope a
SelfDOS tool would block access to that server, shutting down access.

If you really must use one of these tools, be sure to set the time that
the system blocks an attacking address to something you can live with.
A ten minute block is usually adequate. The skript kiddiez will move
on to try someone else, and you'll only be locked out for a while.

PortSentry was the first tool - it listened on specific (otherwise
unused) ports for connection attempts. These might be indicative of a
port scan. It offered three options - add a host reject route (man
route), add a host block rule to the firewall, or add a host deny
rule to tcp_wrappers. The later is slightly less of a disaster, while
any spoofer that hits the trigger port can cause you to block access
to a desired service - such as your DNS servers. A separate program
was used to monitor what got blocked (warning you after it shot you in
the wobbly bits), and it could be set to white-list (ignore apparent
"attacks" from specific hosts - like your DNS servers). A _major_
shortcoming is that it defaulted to watching both TCP and UDP - the
latter being absolutely trivial to spoof. I believe this tool is
unmaintained - last version I've seen is 1.2 from May 2003.

Something more common is 'DenyHosts' (version 2.6 was released December
2006 and hasn't been updated since). This is a log reader, normally
used to detect SSH connection failures. It added the IP of the apparent
attacker as a deny host rule to tcp_wrappers. This rule was permanent,
but you had the _option_ of purging those rules after a delay (PURGE_DENY
in units of seconds, minutes, hours, days, weeks _or_ years, DAEMON_PURGE
if used in daemon mode defaults to one hour). Because it's reading logs,
it's harder to _spoof_ an attack, but still possible. It also allows
using mail to trade ban data - which scares me as trivial to cause DoS.

Somewhat more useful are two other log readers. 'BlockHosts' (version
2.6.0 was released 18 June 2011) and 'fail2ban' (version 0.8.4 was
released 17 July 2008) both add rules to the firewall scripts, and these
rules CAN be permanent or temporary (BlockHosts uses hours for the
variable AGE_THRESHOLD and recommends 12 or less, while fail2ban uses
seconds for the variable 'bantime' and defaults to 600 (ten minutes).
'BlockHosts' also allows adding deny rules to tcp_wrappers, and has
the capability of using 'whitelists' and 'blacklists' to permanently
allow or ban specific IP _addresses_ (though these can be regex).

Another is "OSSEC HIDS" - which looks to be a combination log-reader
and r00t-kit detector - combining the worst of two bad tools. I say
"looks like" because the documentation is nearly unusable. Version 2.6
was released in July 2011.

I guess these tools were developed in a fairly benign environment, as
they don't discuss the philosophy of using these tools, the pros, and
more importantly, the cons they may have. Point 2 above (performance
with a large number of _host_ rules) seems to have eluded them.

Old guy

Keith Keller · External Since: Jun 21, 2006 Posts: 516

On 2011-11-14, Moe Trin wrote:
>
> Something more common is 'DenyHosts' (version 2.6 was released December
> 2006 and hasn't been updated since). This is a log reader, normally
> used to detect SSH connection failures. It added the IP of the apparent
> attacker as a deny host rule to tcp_wrappers. This rule was permanent,
> but you had the _option_ of purging those rules after a delay (PURGE_DENY
> in units of seconds, minutes, hours, days, weeks _or_ years, DAEMON_PURGE
> if used in daemon mode defaults to one hour). Because it's reading logs,
> it's harder to _spoof_ an attack, but still possible. It also allows
> using mail to trade ban data - which scares me as trivial to cause DoS.

Sharing ban data is an optional, nondefault feature of denyhosts.
Purging old entries works very well IME.

> I guess these tools were developed in a fairly benign environment, as
> they don't discuss the philosophy of using these tools, the pros, and
> more importantly, the cons they may have. Point 2 above (performance
> with a large number of _host_ rules) seems to have eluded them.

I currently have over 1500 entries in my hosts.deny file, and haven't
noticed any problems with performance. Perhaps it's worse with many
times more entries.

It should be noted that these tools can apply different rules for login
attempts by root than by other users, even if the server does not allow
root logins from arbitrary (or any) hosts. This makes sense, as if you
never expect remote ssh sessions from root, anyone attempting it is very
likely attempting to crack your box.

--keith

--
kkeller-usenet.DeleteThis@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Mon, 14 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, unruh wrote:

>Luis Gonçalves wrote:

>> There any way to limit the number erroneous logins of root from
>> the same IP? After the limit that IP can not try to login anymore.

>Anyway, you could use /etc/hosts.allow
>eg
>sshd:111.222.333.444 222.333.444.111 ....:deny
>to deny any ssh login from those IP addresses (Note you MUST make sure
>that there are fewer than 128 addresses on any one line. The tcpwrapper
>suite has a bug which causes it to loop forever if there are more.
>Venema refuses to fix the bug. )

tcp_wrappers (and the derived package libwrap or tcp_wrappers-lib)
are still based on 'tcp_wrappers-7.6' released April 1997.

Because most "break in" attempts come from the three billion zombie
computers on the Internet (last month, there were 3391480528 IPv4
addresses allocated/assigned world-wide, never mind the 1.2305e34 IPv6
addresses), you really want to include a 'rule removal script also
run by cron, or discover how slow your computer can be with several
thousand rules in /etc/hosts.(allow|deny).

Unlike you, most of us are not world travelers and really don't need
to allow unlimited access from all 216 countries in the world with
Internet service. A simpler solution using tcp_wrappers is

/etc/hosts.allow
sshd: 198.18. 192.0.2. 198.51.100. 203.0.113.

/etc/hosts.deny
sshd: ALL

which allows ssh access from 198.18.x.y, 192.0.2.z, 198.51.100.z and
203.0.113.z _ONLY_ wasting a lot less CPU cycles. Similar rules
can be constructed for any firewall tool.

Old guy

unruh · External Since: Nov 14, 2011 Posts: 98

On 2011-11-14, Moe Trin wrote:
> On Mon, 14 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
> , Luis Gon?alves wrote:
>
>> There any way to limit the number erroneous logins of root from the
>>same IP? After the limit that IP can not try to login anymore.
>
> Why are you allowing root to log in over the net? MAJOR security
> hazard in that. As of last month, there were 3391480528 IPv4 addresses
> allocated/assigned to the world. Do you _REALLY_ need to allow access
> from every one? Fix your firewall rules to _only_ allow connections
> from addresses you have some reason to believe you WANT to have connect.

As you know, if someone manages to connect via ssh for some user, it
becomes far easier to get root. Ie, stopping root logins is not that big
a security. But make sure you have good passwords.

Also, if he travels, he in general has no idea which of those 3391480528
IPv4 addresses he will need to try to connect from. It is hard enough to
get your wireless working once you are there, never mind having to
figure out beforehand what IP addresses you will be trying to log in
from.

>
>>The tries could be consecutive or during a day. After that no more
>>logins.
>
> They are called "Self Denial Of Service" applications. There are three
> things you should consider before trying to use one:
>
> 1) most cracker attacks come from zombie computers, and there are
> several billion of those out on the net.
> 2) ever look at the performance of your filter/firewall when it has
> a thousand rules to deal with?

??? Use tcpwrapper, which handles ssh. It is far faster than having your
firewall try to blacklist all of those.

> 3) be careful about reacting to spoof attacks.
>
> On the latter, I've seen idiots trying to spoof login attempts from
> infrastructure IP addresses (like our name servers) in the hope a
> SelfDOS tool would block access to that server, shutting down access.

Put a line
sshd: <Your local IP address list?> :allow
before any of the deny lists in /etc/hosts.allow.

>
> If you really must use one of these tools, be sure to set the time that
> the system blocks an attacking address to something you can live with.
> A ten minute block is usually adequate. The skript kiddiez will move
> on to try someone else, and you'll only be locked out for a while.
>
> PortSentry was the first tool - it listened on specific (otherwise
> unused) ports for connection attempts. These might be indicative of a
> port scan. It offered three options - add a host reject route (man
> route), add a host block rule to the firewall, or add a host deny
> rule to tcp_wrappers. The later is slightly less of a disaster, while
> any spoofer that hits the trigger port can cause you to block access
> to a desired service - such as your DNS servers. A separate program
> was used to monitor what got blocked (warning you after it shot you in
> the wobbly bits), and it could be set to white-list (ignore apparent
> "attacks" from specific hosts - like your DNS servers). A _major_
> shortcoming is that it defaulted to watching both TCP and UDP - the
> latter being absolutely trivial to spoof. I believe this tool is
> unmaintained - last version I've seen is 1.2 from May 2003.
>
> Something more common is 'DenyHosts' (version 2.6 was released December
> 2006 and hasn't been updated since). This is a log reader, normally
> used to detect SSH connection failures. It added the IP of the apparent
> attacker as a deny host rule to tcp_wrappers. This rule was permanent,
> but you had the _option_ of purging those rules after a delay (PURGE_DENY
> in units of seconds, minutes, hours, days, weeks _or_ years, DAEMON_PURGE
> if used in daemon mode defaults to one hour). Because it's reading logs,
> it's harder to _spoof_ an attack, but still possible. It also allows
> using mail to trade ban data - which scares me as trivial to cause DoS.
>
> Somewhat more useful are two other log readers. 'BlockHosts' (version
> 2.6.0 was released 18 June 2011) and 'fail2ban' (version 0.8.4 was
> released 17 July 2008) both add rules to the firewall scripts, and these
> rules CAN be permanent or temporary (BlockHosts uses hours for the
> variable AGE_THRESHOLD and recommends 12 or less, while fail2ban uses
> seconds for the variable 'bantime' and defaults to 600 (ten minutes).
> 'BlockHosts' also allows adding deny rules to tcp_wrappers, and has
> the capability of using 'whitelists' and 'blacklists' to permanently
> allow or ban specific IP _addresses_ (though these can be regex).
>
> Another is "OSSEC HIDS" - which looks to be a combination log-reader
> and r00t-kit detector - combining the worst of two bad tools. I say
> "looks like" because the documentation is nearly unusable. Version 2.6
> was released in July 2011.
>
> I guess these tools were developed in a fairly benign environment, as
> they don't discuss the philosophy of using these tools, the pros, and
> more importantly, the cons they may have. Point 2 above (performance
> with a large number of _host_ rules) seems to have eluded them.
>
> Old guy

unruh · External Since: Nov 14, 2011 Posts: 98

On 2011-11-14, Moe Trin wrote:
> On Mon, 14 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
> , unruh wrote:
>
>>Luis Gon?alves wrote:
>
>>> There any way to limit the number erroneous logins of root from
>>> the same IP? After the limit that IP can not try to login anymore.
>
>>Anyway, you could use /etc/hosts.allow
>>eg
>>sshd:111.222.333.444 222.333.444.111 ....:deny
>>to deny any ssh login from those IP addresses (Note you MUST make sure
>>that there are fewer than 128 addresses on any one line. The tcpwrapper
>>suite has a bug which causes it to loop forever if there are more.
>>Venema refuses to fix the bug. )
>
> tcp_wrappers (and the derived package libwrap or tcp_wrappers-lib)
> are still based on 'tcp_wrappers-7.6' released April 1997.
>
> Because most "break in" attempts come from the three billion zombie
> computers on the Internet (last month, there were 3391480528 IPv4
> addresses allocated/assigned world-wide, never mind the 1.2305e34 IPv6
> addresses), you really want to include a 'rule removal script also
> run by cron, or discover how slow your computer can be with several
> thousand rules in /etc/hosts.(allow|deny).

I have several thousand "rules" in /etc/hosts.allow, and I have never
even noticed any change in how fast I can log in.

>
> Unlike you, most of us are not world travelers and really don't need
> to allow unlimited access from all 216 countries in the world with
> Internet service. A simpler solution using tcp_wrappers is
>
> /etc/hosts.allow
> sshd: 198.18. 192.0.2. 198.51.100. 203.0.113.
>
> /etc/hosts.deny
> sshd: ALL
>
> which allows ssh access from 198.18.x.y, 192.0.2.z, 198.51.100.z and
> 203.0.113.z _ONLY_ wasting a lot less CPU cycles. Similar rules
> can be constructed for any firewall tool.

IF those are the only places you ever connect from then that is fine.
However, as you say, I and my users ARE world travellers.

so
sshd: <list of critical addresses> :allow
sshd: <list of less than 128 (actually 1024 characters) hosts> :deny
sshd: <next list of less than 128 hosts> :deny
....
sshd: <next list of less than 128 hosts> :deny
sshd::ALL

Ie, always allows from the critical list. It denys those addresses that
have hit more than 5 times in the past few days. It allows all else.

tcp wrapers applies the first rule that matches the address. first from
hosts.allow and then from hosts.deny. However, with the "deny option of
in hosts.allow, it is not clear what the use of hosts.deny is.

>
> Old guy

dold · External Since: Jun 21, 2007 Posts: 8

unruh wrote:
> Anyway, you could use /etc/hosts.allow
> eg
> sshd:111.222.333.444 222.333.444.111 ....:deny
> to deny any ssh login from those IP addresses (Note you MUST make sure

What happens when you try to connect from one of those addresses?
Does it come back quickly as "connection refused", or timeout as if the
server didn't exist?

The iptables looks the same trying to connect to my server as it does
trying to connect to a non-existent server, which I think is handy.

if /etc/hosts.allow works at the same level of obscurity, it does look
easier to administer, and I might switch to that.

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Tue, 15 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, dold.TakeThisOut@03.usenet.us.com wrote:

>unruh wrote:

>> /etc/hosts.allow
>> eg
>> sshd:111.222.333.444 222.333.444.111 ....:deny
>> to deny any ssh login from those IP addresses

>What happens when you try to connect from one of those addresses?
>Does it come back quickly as "connection refused", or timeout as if the
>server didn't exist?

The three-way handshake is completed, and then you get a "connection
refused".

>The iptables looks the same trying to connect to my server as it does
>trying to connect to a non-existent server, which I think is handy.

The router upstream returns a ICMP Type 3 Code 1 ("Host unreachable")?
No, I suspect you have the system to return "nothing", which Steve
Gibson (of GRC.com) claims makes you invisible. The fact that the
upstream router DOESN'T return a "Host unreachable" means that it can
talk to the destination.

>if /etc/hosts.allow works at the same level of obscurity, it does
>look easier to administer, and I might switch to that.

No, if you're trying to pretend you don't exist, you need to use the
firewall with the "DROP" rules. It is easier to admin, but it lacks
a lot of features that the firewall has. Additionally, it only works
with daemons that are able to use 'tcp_wrappers' or 'libwrap', and
does not protect unopened ports as the firewall can.

Old guy

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Tue, 15 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, unruh wrote:

>Moe Trin wrote:

>> Why are you allowing root to log in over the net? MAJOR security
>> hazard in that. As of last month, there were 3391480528 IPv4
>> addresses allocated/assigned to the world. Do you _REALLY_ need to
>> allow access from every one? Fix your firewall rules to _only_
>> allow connections from addresses you have some reason to believe
>> you WANT to have connect.

>As you know, if someone manages to connect via ssh for some user, it
>becomes far easier to get root. Ie, stopping root logins is not that
>big a security. But make sure you have good passwords.

If root can't log in, the bad-guys have to guess the username before
they get to the problem of guessing passwords. Back around 1985, we
set things up such that external logins use a non-public username.
You can have the mail address, but that does you no good because that
username doesn't have external access.

>Also, if he travels, he in general has no idea which of those
>3391480528 IPv4 addresses he will need to try to connect from.

Procedure - trivial to implement, and even our sales-weasels can
perform the necessary steps without needing sticky notes pasted to
their laptops. Concept is VAGUELY like port-knocking, but different.

>> They are called "Self Denial Of Service" applications. There are
>> three things you should consider before trying to use one:
>>
>> 1) most cracker attacks come from zombie computers, and there are
>> several billion of those out on the net.
>> 2) ever look at the performance of your filter/firewall when it
>> has a thousand rules to deal with?

>??? Use tcpwrapper, which handles ssh. It is far faster than having
>your firewall try to blacklist all of those.

We don't blacklist them one-at-a-time. We block MUCH larger blocks,
up-to-and-including /7s. Comes in handy when you have more than one
address range in your ASN.

>> On the latter, I've seen idiots trying to spoof login attempts from
>> infrastructure IP addresses (like our name servers) in the hope a
>> SelfDOS tool would block access to that server, shutting down access.

>Put a line
>sshd: <Your local IP address list?> :allow
>before any of the deny lists in /etc/hosts.allow.

Nope - the perimeter firewall drops inbound packets with source
addresses that should be inside. That's another one we found over
twenty years ago. We also block RFC3330 sources because they're
equally non-routable. Grab a copy of RFC2827 and RFC3704 and scan
through them. Some of it is really "duh!!!".

Old guy

unruh · External Since: Nov 14, 2011 Posts: 98

On 2011-11-15, Moe Trin wrote:
> On Tue, 15 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
> , dold DeleteThis @03.usenet.us.com wrote:
>
>>unruh wrote:
>
>>> /etc/hosts.allow
>>> eg
>>> sshd:111.222.333.444 222.333.444.111 ....:deny
>>> to deny any ssh login from those IP addresses
>
>>What happens when you try to connect from one of those addresses?
>>Does it come back quickly as "connection refused", or timeout as if the
>>server didn't exist?
>
> The three-way handshake is completed, and then you get a "connection
> refused".
>
>>The iptables looks the same trying to connect to my server as it does
>>trying to connect to a non-existent server, which I think is handy.
>
> The router upstream returns a ICMP Type 3 Code 1 ("Host unreachable")?
> No, I suspect you have the system to return "nothing", which Steve
> Gibson (of GRC.com) claims makes you invisible. The fact that the
> upstream router DOESN'T return a "Host unreachable" means that it can
> talk to the destination.
>
>>if /etc/hosts.allow works at the same level of obscurity, it does
>>look easier to administer, and I might switch to that.
>
> No, if you're trying to pretend you don't exist, you need to use the
> firewall with the "DROP" rules. It is easier to admin, but it lacks
> a lot of features that the firewall has. Additionally, it only works
> with daemons that are able to use 'tcp_wrappers' or 'libwrap', and
> does not protect unopened ports as the firewall can.

Agreed. Although what "protecting unopened ports" means is a bit obscure
since an unopened port has nothing listening and thus cannot be used to
do anything to you. Your machine will simply ignore any packet with that
port.
ssh uses tcpwrappers. And I do hope that you are using ssh and not
telnet or rsh on your machine.
>
> Old guy

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Tue, 15 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, unruh wrote:

>Moe Trin wrote:

>> No, if you're trying to pretend you don't exist, you need to use the
>> firewall with the "DROP" rules. It is easier to admin, but it lacks
>> a lot of features that the firewall has. Additionally, it only works
>> with daemons that are able to use 'tcp_wrappers' or 'libwrap', and
>> does not protect unopened ports as the firewall can.

>Agreed. Although what "protecting unopened ports" means is a bit obscure
>since an unopened port has nothing listening and thus cannot be used to
>do anything to you. Your machine will simply ignore any packet with that
>port.

Well, yes and no. For a system ONLY running a basic networking stack,
trying to connect to an unused port (or protocol) will result in the
stack replying to the initial packet (SYN for tcp) with a RST rather
than a SYN-ACK. Now if you have a firewall on the system, the result
will differ _IF_ there is no 'ACCEPT' or forwarding rule for that port
(or protocol). In that case, the firewall looks at the next or default
rule, which may be a DROP (packet goes to /dev/null with no response)
or a REJECT (in which case, the the firewall responds with either a RST
or ICMP Type 3 Code <mumble>). If there is no rule, then the network
stack will respond with the RST as above.

tcp_wrappers acts as an intermediate server, listening on designated
tcp ports. Ports that aren't wrapped (and all other protocols) respond
according to the previous paragraph. A remote attempting to connect
to a wrapped port WILL complete the 3-way handshake, and the network
stack will forward the packet to the tcpd (or libwrap). At _that_
point, /etc/hosts.allow and maybe /etc/hosts.deny will be consulted,
and if the connection is NOT allowed, the daemon/library will return
an appropriate error message (such as "421 Service not available.")
and that's the end of that. But as far as Steve Gibson and the
``stealth'' aficionados are concerned, this gave away the store by
admitting that the host not only exists, but is on-line. (Quick, try
all of the other 255 possible protocols and gazillion other port number
combinations on each. Maybe something IS open to our secret super
cracking script!!!)

>And I do hope that you are using ssh and not telnet or rsh on your
>machine.

Don't forget 'rlogin' Wink

Actually, my systems all have telnet
and ftp _clients_ - the telnet is used as a troubleshooting tool, and
there are hundreds of thousands of _anonymous_ ftp servers on the
Internet, a number of which I access on a regular basis.

Old guy

dold · External Since: Jun 21, 2007 Posts: 8

Moe Trin wrote:

> No, if you're trying to pretend you don't exist, you need to use the
> firewall with the "DROP" rules. It is easier to admin, but it lacks
> a lot of features that the firewall has.

I thought that not existing at all was a good thing, but "connection
refused" would be sufficient to deter an ssh script-kiddie, as if they had
maybe reached a windows server with no sshd.

But, my first exposure to this was a dual boot server, and I noticed the
slowdown while booted in Windows, so it was passing back "connection
refused", I suppose. Maybe the attempts would have died off by themselves
in a day or two.

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Wed, 16 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, dold.TakeThisOut@03.usenet.us.com wrote:

>Moe Trin wrote:

>> No, if you're trying to pretend you don't exist, you need to use
>> the firewall with the "DROP" rules.

>I thought that not existing at all was a good thing, but "connection
>refused" would be sufficient to deter an ssh script-kiddie, as if
>they had maybe reached a windows server with no sshd.

Trying to keep this on the simple side but still give an explanation.

Let's do a quick check of what happens to an IP connection attempt to
port 22/tcp (or similar). IP (RFC0791) is an "unreliable" protocol.
Packets are not guaranteed to be delivered to the destination. So,
the sending host throws an IP packet out there trying to make a
connection. Assume it (and the reply) doesn't get lost between source
and destination. Without a firewall in the way, the packet goes up
the network stack on the destination host. Two ways to go here - no
server on this port (or a firewall with a "REJECT" rule) and an IP
'RST' packet (or maybe an ICMP Type 3 Code 3 "The number you have
reached is not in service...") is sent back. If there IS a server on
this port (and 'tcp_wrappers' counts as a server in this regard) the
stack sends back a TCP/IP packet with the SYN and ACK flags set (the
second part of a three-way handshake). Back at the remote sender, they
receive a packet - either answering the phone or in essence saying
"nobody listening". In the latter case, even the dumbest skript
kiddie or zombie knows further attempts at this port are fruitless.
Move on - nothing here to see - yada, yada, yada. (If tcp_wrappers or
libwrap is running and denying you, at the completion of the three-way
handshake, it MAY return a failure code and close the connection, or
it may just close it with no message at all. In theory the open/close
is detectable as a blocking function, but it's not letting you in the
door either. "Let's try an easier target somewhere else.")

Now, what happens if there is a firewall that is dropping the packet
at the destination? Source waits a second or so, and the network
stack starts swearing at the b0rk3n Internet - the packet must have
made that wrong turn in Albuquerque[1] and gotten lost. So it sends
another. This may be repeated a second time. The stack then reports
to the application that there was no response. That application MAY
attempt to try the connection again, or may not. It says here that
this is wasting CPU cycles on the ``attacking'' host, but the effect
is minimal. The difference on the target? Receive/reply to one
verses receive three (or more). If you're making a fine enough
measurement, returning a RST to the initial connection attempt is a bit
less work than passing repeated packets to the bit-bucket. And don't
forget that you've got to firewall all ports and all protocols (there
is more to the world than TCP, UDP or ICMP). 'tcp_wrappers' and/or
'libwrap' doesn't do that.

>But, my first exposure to this was a dual boot server, and I noticed
>the slowdown while booted in Windows, so it was passing back
>"connection refused", I suppose.

There would be little difference between same conditions on either O/S.
No server/firewall, and both return the RST or ICMP 3/3. Firewall
that is DROPing packets rather than replying - exactly the same.
About the only (minor) difference is the windoze ``personal firewall''
applications (examples: Black Ice or ZoneAlarm) that waste additional
CPU cycles writing crap to the logs about how they thwarted "an
attack" from this address at that time - I suppose that's meant to make
the windoze user feel good. Certainly has no other useful function.
Both at work and at home, we rarely bother logging failed connection
attempts. The firewall worked - what more do I need to know or do?

>Maybe the attempts would have died off by themselves in a day or two.

From a single zombie? Probably finish in a few hours. Of course,
there are probably 2.999 billion other zombies who will be calling
soon enough. Every once in a while, I'll turn on logging for a while
to try to gauge how much noise is out there - but for the most part I
simply don't bother. ISP abuse desks rarely do anything to control
the problem, so I'm not going to waste any more effort on it.

Old guy

[1] Bugs Bunny was right - there were a couple of turns on US Route 66
in down-town Albuquerque, and if you didn't make that turn... This
was fixed when Interstate 40 (the Coronado Freeway) replaced US-66.
Fourteen exit ramps and big signs, but no turns to miss.

dold · External Since: Jun 21, 2007 Posts: 8

Moe Trin wrote:
> On Wed, 16 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
> , dold RemoveThis @03.usenet.us.com wrote:

> >But, my first exposure to this was a dual boot server, and I noticed
> >the slowdown while booted in Windows, so it was passing back
> >"connection refused", I suppose.

> There would be little difference between same conditions on either O/S.
> No server/firewall, and both return the RST or ICMP 3/3. Firewall

In my case, the Windows would have been refusing, the Linux accepting, no
firewall on either.

> that is DROPing packets rather than replying - exactly the same.
> About the only (minor) difference is the windoze ``personal firewall''

Actually, I might have had ZoneAlarm at the time. I was getting the IP
addresses of the attackers from somewhere. Maybe the router, but
probably ZoneAlarm.

> >Maybe the attempts would have died off by themselves in a day or two.

> From a single zombie? Probably finish in a few hours. Of course,

It seemed that there was some cooperation. Maybe not. Even zombies have
some control. Once it was discovered that my Linux was accepting port 22,
then the zombies piled on, trying to brute force crack root/guest/user/
logins.

> simply don't bother. ISP abuse desks rarely do anything to control

The ip addresses were all concentrated in one country. As someone else
noted, it might be easiest to allow a few very broad subnets that are in
one's home country.

Random zombies try to probe for port 22 on random addresses. If they find
a live port, then they tell all their friends and they hammer away at login
attempts. Using hosts.allow to trim 3/4 of the world population out of the
zombies that could see my port, I would eliminate the zombies piling on in
login attempts.

hosts.allow probably has the desired effect, with a more readily understood
format than iptables.

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Fri, 18 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, dold RemoveThis @03.usenet.us.com wrote:

>Moe Trin wrote:

>> There would be little difference between same conditions on either
>> O/S. No server/firewall, and both return the RST or ICMP 3/3.

>In my case, the Windows would have been refusing, the Linux accepting,
>no firewall on either.

So the windoze box wasn't offering SSH, and Linux was?

>>> Maybe the attempts would have died off by themselves in a day or two.

>> From a single zombie? Probably finish in a few hours. Of course,

>It seemed that there was some cooperation. Maybe not. Even zombies
>have some control. Once it was discovered that my Linux was accepting
>port 22, then the zombies piled on, trying to brute force crack
>root/guest/user/ logins.

Can't say that I've seen that, but I haven't been offering SSH to the
world for years. Even at work, the port is functionally restricted.

>> ISP abuse desks rarely do anything

>The ip addresses were all concentrated in one country.

Which one out of curiosity?

>As someone else noted, it might be easiest to allow a few very broad
>subnets that are in one's home country.

Probably me - and really I only allow connections from a select list.
There are three firewall rules that forward from a /22 and two /24s (a
total of 1530 addresses out of 3395108304 as of last week or 0.000045%)
to the box running the SSH server. The other 99.999955% of the Internet
isn't forwarded and thus can't even get _any_ response from the server.
The default rule is a REJECT.

A problem about filtering by country - IANA and the five Regional
Internet Registries (RIRs) don't have IPs conveniently arranged by
country (or even regions). Everyone blames China as a bad guy, so how
would you block the 330.49 million IPv4 addresses they're allocated or
assigned?

[planck ~]$ zgrep -c CN [ALR]*
AFRINIC.gz:0
APNIC.gz:3457
ARIN.gz:1
LACNIC.gz:0
RIPE.gz:0
[planck ~]$ zgrep CN ARIN.gz
CN 199.59.240.0 255.255.252.0 allocated 20101209 ar
[planck ~]$ zgrep -h CN A* | cut -d' ' -f2 | cut -d'.' -f1 | sort -n
| uniq -c | column
54 1 21 112 13 140 17 183
17 14 44 113 6 144 2 192
32 27 30 114 7 150 1 199
25 36 28 115 7 153 555 202
10 39 56 116 7 157 970 203
90 42 38 117 1 159 78 210
17 49 50 118 1 161 45 211
44 58 77 119 1 162 73 218
34 59 29 120 6 163 42 219
38 60 49 121 1 166 17 220
89 61 38 122 1 167 64 221
75 101 50 123 1 168 64 222
90 103 72 124 12 171 28 223
23 106 40 125 20 175
42 110 1 134 36 180
34 111 16 139 29 182
[planck ~]$

If you're not a UNIX scripting nut, the first one asks how many
allocations (distributions to Internet Registries for further
assignment/allocation) and assignments (distribute IPs to end-users)
are assigned to China. 3457 from APNIC, 1 from ARIN (and here's what
an entry in these files looks like). This count ignores allocations
and assignments to Hong Kong (.hk), Macau (.mo) and Taiwan (.tw) which
add another 1305 entries. The long one asks what the FIRST octet of
the addresses are, sorts that, counts, and then displays it in columns.
So, there are 54 1.x.x.x networks associated with Chinese companies.
17 14.x.x.x networks, and so on. Not very convenient. Another minor
problem - just because the addresses are _registered_ in country $FOO
doesn't mean that the computers are actually there. Ever heard of
"multi-national" companies? I work for one.

There _used_to_be_ recommendations to block '202.x.x.x, 203.x.x.x,
210.x.x.x and 211.x.x.x to wipe out all of the Asia-Pacific region.
Know your ISO-3166 country codes?

202
AF BN GU JP LK MU NU PK TO VU
AP BT HK KH MH MV NZ PW TV WS
AS CK ID KI MN MY PF SB TW
AU CN IN KR MO NC PG SG US
BD FJ IO LA MP NP PH TH VN

203
AF BT GU IO KR MN NF PF SG VN
AP CN HK JP LA MV NP PG TH VU
AU FJ ID KH LK MY NR PH TW WS
BD GB IN KI MM NC NZ PK US

210
AF BD FJ ID JP MP NZ PK TH VN
AU CN HK IN KR MY PH SG TW

211
AU CN JP KR MY TW

Notice the GB and US entries? One of the US entries is actually a US
Navy facility, and several of the GB entries are British banks.

Another suggestion in the past has been to block addresses where the
IP resolves to a hostname like $FOO.BAR.BAZ.cn. Two problems with
that suggestion - there are a LOT of IP addresses that don't resolve
because the DNS admin there has his/her head up their ass. Second,
it may be a shock to people, but there are a shed-load of .com domains
in _every_ country.

>Random zombies try to probe for port 22 on random addresses. If they
>find a live port, then they tell all their friends and they hammer
>away at login attempts. Using hosts.allow to trim 3/4 of the world
>population out of the zombies that could see my port, I would
>eliminate the zombies piling on in login attempts.

In the firewall - set the default inbound to DROP or REJECT, and then
add the needed rules to connect those IPs or IP ranges you want to
give access to. In my case, that boils down to just five total lines.

>hosts.allow probably has the desired effect, with a more readily
>understood format than iptables.

It certainly is more readily understandable, but that was written 14+
years ago, in a different universe, and the original author (Wietse
Venema formally of Eindhoven University of Technology) has not been
maintaining it. See http://www.netfilter.org/documentation/HOWTO/
for ways to get the firewall simple and solid.

Old guy

dold · External Since: Jun 21, 2007 Posts: 8

Moe Trin wrote:
> So the windoze box wasn't offering SSH, and Linux was?

correct.

> >The ip addresses were all concentrated in one country.

> Which one out of curiosity?

..cn

> country (or even regions). Everyone blames China as a bad guy, so how

In my case, .cn was the bad guy.

> In the firewall - set the default inbound to DROP or REJECT, and then
> add the needed rules to connect those IPs or IP ranges you want to
> give access to. In my case, that boils down to just five total lines.

For me as well. I have one outside IP address that I can log into from
anywhere. That ISP uses a limit of some sort, with a telnet knock to
reopen for a locked address. From that login, I can go to my home
machine,a nd adjust the allowed list to include my new location, which I
might do for performance reasons, especially if I am running some GUI
remotely. I only allow a couple of subnets, and those have gone away, as
all of the cororate connections seem to come out through one firewall, if
outbound is allowed at all.

> for ways to get the firewall simple and solid.

I got the impression from this thread that hosts.allow was more current.
If not, then I'm happy with the iptables. I only allow port 22, and a port
for a special package, from an even more limited set of IPs.

--
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5

Moe Trin · External Since: Dec 12, 2009 Posts: 46

On Mon, 21 Nov 2011, in the Usenet newsgroup alt.os.linux.redhat, in article
, dold.TakeThisOut@03.usenet.us.com wrote:

>Moe Trin wrote:

>> In the firewall - set the default inbound to DROP or REJECT, and
>> then add the needed rules to connect those IPs or IP ranges you
>> want to give access to. In my case, that boils down to just five
>> total lines.

>For me as well. I have one outside IP address that I can log into
>from anywhere. That ISP uses a limit of some sort, with a telnet
>knock to reopen for a locked address. From that login, I can go to
>my home machine,a nd adjust the allowed list to include my new location

One technique that was used was basic port-knocking. You set up the
firewall to block everything inbound, and monitor some rarely used
port - heck, how about 53/tcp as a poor example. To connect, you first
try a quicky 'telnet your.host 53' - you won't connect, but the
firewall can be configured to open your 22/tcp for packets from that
IP for one minute only. Now, you've got one minute to "log in" (once
you established a TCP connection, the "ESTABLISHED" rule in the firewall
maintains _that_ connection). If you don't log in, the firewall closes
the 22/tcp hole, and we're back to normal. As the firewall is ONLY
permitting "that" host (or any other that first tries to hit 53/tcp in
this example), the rest of the world doesn't exist. This is NOT
"security by obscurity" because once you knock, you STILL have to
authenticate by what-ever means you've got the server set to, AND you've
got one minute to do so.

A problem with this is that a lot of places have put outbound blocks
on ``non-standard'' ports. The classic port-knocking scheme was to
knock a series of ports in a specific order, in a specific time, and
that _substituted_ for authentication (bad idea). My company used
this scheme in the 1980s, but eventually ran into remote facilities
with outbound blocks - blocking ports we needed to knock. We got
around that for a while, using ports less likely to be blocked before
replacing the scheme with something else.

>> for ways to get the firewall simple and solid.

>I got the impression from this thread that hosts.allow was more
>current. If not, then I'm happy with the iptables.

[euclid ~]$ tar -zvtf /net/james-webb/sources/tcp_wrappers_7.6.tar.gz |
cut -c32-42 | sort | uniq -c | column
1 1993-09-11 1 1995-01-03 2 1996-03-19
2 1994-03-23 1 1995-01-08 4 1997-02-11
22 1994-12-28 2 1995-01-30 8 1997-03-21
1 1994-12-31 9 1996-02-11 2 1997-04-07
1 1995-01-02 1 1996-02-21
[euclid ~]$ zgrep -l iptables /net/james-webb/kernel/ChangeLog-3*
/net/james-webb/kernel/ChangeLog-3.0.gz
[euclid ~]$ zgrep -l netfilter /net/james-webb/kernel/ChangeLog-3*
/net/james-webb/kernel/ChangeLog-3.0.5.gz
/net/james-webb/kernel/ChangeLog-3.0.gz
/net/james-webb/kernel/ChangeLog-3.1-rc1.gz
/net/james-webb/kernel/ChangeLog-3.1-rc2.gz
/net/james-webb/kernel/ChangeLog-3.1.gz
[euclid ~]$

tcp_wrappers has some nice features, but it's been unmaintained for
close to 14 years. The firewall code is part of the kernel, and is
under on-going development.

Old guy