Re: Blocking attacks from spoofed IP addresses

On Fri, 02 Oct 2009, in the Usenet newsgroup comp.os.linux.networking, in
article <ha6gou$m3s$1@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Marty wrote:

Moe Trin wrote:

Be careful about banning IP addresses. That is often a good way to
cause a _Self_ Denial Of Service attack. While it is very difficult
to spoof a TCP connection (due to sequence numbers), it's not
impossible, and the results can be ``interesting'' if they spoof an
IP address that is vital to the normal operation of your systems.

Not sure I follow this. If I'm not at the console, and someone spoofs
the IP address that I happen to want access from, then I guess I am
out of luck. But someone would be hard pressed to know what that
precise address would be.

2827 Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing. P. Ferguson, D. Senie.
May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated
by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)

3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
BCP0084) (Status: BEST CURRENT PRACTICE)

Two RFCs widely available through any search engine. Most people
know to block inbound packets that claim to come from addresses in
your LAN. Several months ago, we noted attempted attacks from
someplace 12-16 hops away (based on TTL) that were destined to some
of our DMZ servers, and had source IPs from our public DNS servers.
First, our public servers are not 12-16 hops away from our DMZ,
never mind being on the "wrong" side of the firewall. Second, our
DMZ servers are set to use a different group of name servers, not
the "public" ones. Some one was trying very hard - I'm just not
exactly sure what they expected to accomplish.

Banning individual addresses also can be a resource hog - think
about the CPU cycles required to check through a thousand or so
"rules" for each connection. If you must ban, block the address
for a short period (10 minutes) rather than permanently.

So far it's not bad. I've accumulated 450 rules in the last week or
so and I don't see any performance hit.

Trust me - there is one.

I'm also seeing some patterns start to develop in the blocks of
addresses. I can add some intelligence to my script to blanket-ban
an octet if it has more than N violators to reduce the number of
rules.

This is why at work, we block huge chunks (one of the rules applies
to a /5 - the equivalent of eight blocks formerly called Class A in
size) of IP space that are residential network ranges. Potential (or
actual) customers don't try to access our more sensitive net (the
web, mail and ftp sites are in completely different IP blocks), so
the only thing we seem to be blocking is undesirable traffic.

As of 15 September, 2009, there were 2,923,334,816 IPv4 addresses
in 97651 allocated/assigned blocks around the world. It's most
unlikely that you will need to be able to connect from all of them
to your system.

If I am away from home, I may need (and have in the past) to access
my system from Japan, China, and Malaysia to name a few places.

True - but you don't need to access your systems _all_the_time_ from
those ranges. Two solutions are port-knocking and learning what
ranges would need to be allowed for the duration of your visit. The
countries you mention make it difficult, as China has 1630 netblocks
and 213.1 million IPv4 addresses (add 677 nets and 8.4 million IPv4
addresses if you include Hong Kong and Macau), Japan has 2149 blocks
and 158.9 million IPv4 addresses, and Malaysia has a mere 260 blocks
and 44.9 million IPv4 addresses.

Also, there are a number of folks in Germany, Russia, England, and
US residential addresses who frequent my web offerings. Probably a
number of other locations that I'm not aware of too (saw a couple of
legit web hits from somewhere in Africa).

Web services are on your port 80 and/or 443, and one would hope you
are not trying to run your SSH server on the same port numbers. In
consequence, you can use the '--dport' variable in your firewall
rules to apply one set of access rules to SSH, and another for your
web services. One rule no more fits all ports/services than it fits
all Internet users.

[port-knocking]

No need for a web page - everything can be done using firewall
rules without having an open port that can be abused.

I already run the web server, but it's not Apache and the CGI is not
PHP or any such thing. Even if someone got a shell on my web server,
they'd probably have no clue how to do anything there. It's an OS/2
machine. :-)

Is that even supported any more? I'd be extremely wary of using
unpatched software of that age in any hostile setting. The idea of
port knocking is that the function can be run without giving any
access to the knocking port, or to ``untrusted'' systems. Noted
elsewhere in this thread, port knocking uses the idea of knowing
which sequence of ports to access before a remote system is given
access to the real server being protected. I've never seen anyone
need to use port-knocking to protect something mundane as a web or
ftp server (which should have it's own separate protections), but
if you are giving shell access, you should be using appropriate
authentication schemes. Firewall (or other access) rules are not
meant to be part of the authentication, but are meant to hold the
noise (in the logs) down and make brute-force attacks more difficult.

As above - given that most "attacks" come from zombies and 0wn3d
boxes on residential networks, nearly all of which are using a
dynamic address assignment.

True. The dynamic nature of addresses, coupled with the possibilty
of locking myself out (or having someone else who is exceedingly
clever or lucky do it for me) does argue strongly for a
"forgiveness" policy.

Most are not running a system with infinite resources, so a "short
term" block of addresses are usually adequate. Even the skript
kiddiez and zombie authors recognize that banging away on a system
that is ignoring them is wasted CPU cycles. In the case of 'bots
the CPU cycles are (more-or-less) free, but with 2.9 billion IPv4
addresses in the world, they have better things to attack, and soon
loose interest.

Old guy
.

Relevant Pages

  • Re: Blocking attacks from spoofed IP addresses
    ... cause a _Self_ Denial Of Service attack. ... Defeating Denial of Service Attacks ... of our DMZ servers, and had source IPs from our public DNS servers. ... Web services are on your port 80 and/or 443, ...
    (comp.os.linux.networking)
  • RE: Hacking to Xp box
    ... restricts most of the attacks that use anonymous connections. ... nessus found port 135 139 ... Audit your website security with Acunetix Web Vulnerability Scanner: ... login pages, dynamic content etc. Firewalls, SSL and locked-down servers ...
    (Pen-Test)
  • Re: Changes in IDS Companies?
    ... Things like port scans and DoS attacks very often ... > If people are running insecure web servers, ... downplay the vulnerability to save face, so admins even if they are trying ...
    (Focus-IDS)
  • Re: Changes in IDS Companies?
    ... Things like port scans and DoS attacks very often ... >> If people are running insecure web servers, ... when people don't update their patches at ... > downplay the vulnerability to save face, so admins even if they are trying ...
    (Focus-IDS)
  • RE: Hacking to Xp box
    ... If the firewall doesn't block ICMP, ... you need to find some vulnerability that could be exploited to run ... > restricts most of the attacks that use anonymous connections. ... > login pages, dynamic content etc. Firewalls, SSL and locked-down servers ...
    (Pen-Test)