Re: Blocking attacks from spoofed IP addresses

On Sat, 03 Oct 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <eutcc5tdqofn2o4tmnnqb18meuo51c7d0i@xxxxxxx>, Grant wrote:

(Moe Trin) wrote:

I hesitate to ask, but what IP[s]? Some time ago, I looked at the
logs of someone else's system, and noted a lot of consistent hits
from a handful of IP ranges registered in China. DNS lookups were
useless, as most addresses there don't have PTR records, but the
'whois' queries provide some hints.

From my block drop list:

[...]

No, don't see the blocks I expected. I'm seeing a lot of consistent
hits from Hangzhou province (122.224/12) and Hebei province (121.16/13,
221.192/13) networks. The addresses are steady for a month or more,
then they disappear. 221.192.199.xx seems to be the hot spot now.
The Chinese whois server (whois.cnnic.net.cn) claims not to own the
address range.

Only caught one oddness, that:
"
# dunno, something is calling home to 38.97.225.166:6667
38.97.225.128/25
"
after a web page hijacking.

It's obvious you know how to use rwhois, and that block belongs to
name.com in Denver - they're an ICANN accredited registrar. Currently,
they are only accredited for .cat .coop .museum
(http://www.icann.org/registrars/accredited-list.html), but last summer
they were accredited for .aero .asia .biz .com .info .jobs .mobi and
..name domains. I don't know when they cut back. Port 6667 is one used
by IRC. Co-inky-dink? Perhaps - perhaps not. As you know, port
numbers are not fool-proof, and there is no requirement that a packet
destined for port $FOO must be service/protocol $BAR.

[port knocking ports]

I'd possibly use https here as I don't offer that, or a web .cgi as
that server is always running (no php here :)

You don't need a server - in fact it's USUALLY better not to be running
anything on the port. Instead, you might have a logging rule for the
knock port, and then use a cron strip to scan the log looking for
"recent" hits. Some one else suggested

--------------------
CMD="iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport"
$CMD 22 -m recent --rcheck --name SSH -j ACCEPT
$CMD 11 -m recent --name SSH --remove -j DROP
$CMD 12 -m recent --name SSH --set -j DROP
$CMD 13 -m recent --name SSH --remove -j DROP

If you make a connection to port 12, it'll remember the IP you did
that from, and enable SSH access from that IP, even though the
connection to port 12 fails. This is the knock on the door that
unlocks it. Connect to port 11 or 13 to close the port again. This is
so a sequential portscan won't keep the SSH port opened.
--------------------

but obviously you'd need to use more ``appropriate'' port numbers.
This is far from the only or best technique/rule-set. Doing a google
search for the keywords 'port knocking' and 'Linux' or 'iptables'
will bring up lots of hits, some rather interesting.

I've noticed telnet hits are more frequent last couple years, but
the firewall here bans the IP for some time after first hit to 22
or 23.

I don't normally bother logging drops on the firewall at home (it's
just the remnants of a 386SX laptop and doesn't have that much
horsepower), but don't recall anything going after telnet. That's
a pretty dead service, and just about everyone and his dog has
transitioned to SSH. Actually, I'm not even sure that distributions
are supplying the telnet server any more. Client, yes, but not the
server.

Just don't make the procedure[s] so complex that you are sure to
make a typ0 or other fumble-finger and lock yourself out.

Think I'd go for the KISS method -- after all it's only about
reducing exposure to the system scanners out there discovering an
open port to try logins on.

That is the name of the game, but a lot of people loose sight of that
goal, and shoot themselves very nicely. More than once I've heard
horror stories about someone fixing up a new spiffy firewall on their
co-lo box, and having to have the local staff kick the system in the
appropriate places to regain access.

Old guy
.

Relevant Pages

  • RE: Logs: Many hits with source port of 80
    ... I have seen similar hits for the past three months. ... Are you sure yours are TCP? ... Subject: Logs: Many hits with source port of 80 ... where the source port is set to tcp 80 and the destination port is some ...
    (Incidents)
  • Re: Port 25 blocking ????
    ... But I should see some hits on my permit statements in my ACL if it was ... If they are port 25 blocking, that would prevent my telnet attempt, ... Timing out is a typical reaction for a firewalled connection. ...
    (comp.dcom.sys.cisco)
  • Re: New program/virus is making the rounds?
    ... >Most hits were port 27374, now almost all are port 1433. ... >What new program hit the web now??? ... which filters the crap out of the emails BEFORE it infects ...
    (comp.security.firewalls)
  • McAfee Personal Firewall
    ... I just purchased the McAfee Personal Firewall this weekend ... the hits that have probably always been there. ... that was using a "Microsoft-DS" service or program. ... If you want to allow traffic on this port, ...
    (microsoft.public.security)
  • Re: New program/virus is making the rounds?
    ... >Most hits were port 27374, now almost all are port 1433. ... >What new program hit the web now??? ... which filters the crap out of the emails BEFORE it infects ...
    (comp.security.firewalls)