Draws largest size SuperSoaker filled with mixed Cranberry and
Pomegranate juice and fires at point blank range while shouting
"Better red than dead, eh?" Then she exists rapidly stage left.
From: "Michael P. Brininstool" <mikepb@xxxxxxxxxxx>
HA! I TOP-POSTED!!!! So SHOOT ME!
I know that the preferred way of controlling access is to use
whitelists, but for my case I'd like to use IP blacklisting.
At some point it affects performance. There are some workarounds.
What problem are you trying to solve? What causes you to block an IP?
I second the suggestion about running SSHD on a different port. It's
removed all my script kiddie attacks. See /etc/ssh/sshd_config to enable.
Moving ssh to a different port seems to be the easiest way, but eventually
the scripts find the new port and start whacking it instead -- iptables
blocking is IMNSHO, a "better way" -- in that they can be logged -- useful
when you call in the feds. (Of course honeypots are even better....)
This is what I have done to block over 2400 ip blocks with no performance
hit measurable. Of course, I whitelist some very common blocks first, so
they avoid any delays, and most everyone else SHOULD be blocked so a delay I
care not about. Snippets only...
-A INPUT -i eth1 -d MY.EXTERNAL.IP -j ext_in
-A ext_in -p tcp -m tcp --dport 22 -j sshblock
-A sshblock -s G.0.0.D/I.P.BLCK.1 -j ACCEPT
-A sshblock -s G.0.0.D/I.P.BLCK.2 -j ACCEPT
Ah - really? I wonder what that G.0.0.D part does.
-A sshblock -s 0.0.0.0/192.0.0.0 -j sshblock0
-A sshblock -s 64.0.0.0/192.0.0.0 -j sshblock64
-A sshblock -s 128.0.0.0/192.0.0.0 -j sshblock128
-A sshblock -s 192.0.0.0/224.0.0.0 -j sshblock192
-A sshblock -s 224.0.0.0/224.0.0.0 -j sshdrop
-A sshblock -j ACCEPT
sshblock0 gets addresses in 0.0.0.0 through 63.255.255.255
sshblock64 gets addresses in 64.0.0.0 through 127.255.255.255
sshblock128 gets addresses in 128.0.0.0 through 191.255.255.255
sshblock192 gets addresses in 192.0.0.0 through 223.255.255.255
224.0.0.0 through 255.255.255.255 goes to sshdrop (which logs as
"DROPPED_SSH_PACKET " and drops)
That seems like a passing clever trick.
To help performance even further, the SYN flag can be added to the check for
port 22 above, provided a "RELATED,ESTABLISHED" line exists in the same
chain.
If you play with "recent" you can work some nice magic. But you also
may want to alter your /etc/sshd.conf, too.
I forgot the URL, but there is a site that has a database of IP block
assignments. I periodically go to that site and download the blocks for
countries I NEVER want to receive email or ssh connections from, like CN,
KR, MY, VN, FR, TW, BR, etc, and add them to the sshblock and smtpblock
lists.
That would be rather handy. I'm all eyes for a message with that list.
This is the way I handle the problem. The core tool of my hand rolled
iptables script (run each time adsl connects) is this three line ditty.
===8<---
$IPTABLES -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
--rcheck --seconds 180 --hitcount 2 -j LOG --log-prefix 'SSH REJECT: '
$IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
--rcheck --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset
===8<---
This means an attacker gets two connection attempts before he is
shoved away for 3 minutes. (This is down from 3 failures and 2 minutes
I used to allow until today.)
A discovery today led me to make a change to the login parameters. I
still allow myself passworded logins. So I repaired an oversight that
allowed too many simultaneous connection attempts. I uncommented and
revalued these three lines in sshd_config to give crackers fewer chances
to guess the passwords involved.
===8<---
LoginGraceTime 1m
MaxAuthTries 2
MaxStartups 1
===8<---
That means there are two tries at a password every three minutes with the
IPTables rules above.
I have been culling the login attempts I catch for attempted ssh cracks.
So far I have a VAST list of Asian, mostly Chinese and Korean, IP
allocations blocked. I just today blocked a rather "smart" attempt
from an ISP/registrar in the fortressitx.com block, 65.98.0.0/12. Until
today all attacks made ONE password guess per connection attempt then
tried again. This one managed more than one attempt per login attempt
and seems to have tried as many as 10 connections at once. So cutting
down the MaxStartups (how many simultaneous connection attempts are
allowed) and MaxAuthTries to 2 seems to be the solution. If I am on
the road and fumble my password twice in a row I have earned a three
minute wait, I figure. I figure the chances of a lucky guess not
being noticed over the multiyear process of repeat trials is rather
small even under a botnet attack. And my machine and piddly slow
DSL connection are not worth such an attack effort.
Of course, YMMV for your needs for foreign ssh connections.
{^_^} Joanne
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
