Re: Blocking attacks from spoofed IP addresses

Moe Trin wrote:
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.

Funny you should mention it. I just saw this beauty today...

marty@sittyfo:~> nslookup 123.30.98.50
Server: 68.87.76.178
Address: 68.87.76.178#53

Non-authoritative answer:
50.98.30.123.in-addr.arpa name = localhost.

Authoritative answers can be found from:


Very cute indeed. :-)

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.

Would I see "system" time building up? I'm just not sure how to measure
this right now, but I'd like to know. The filtration lives inside the
kernel, right?

[snips, but I did read and thanks for the input]

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.

True. I'm painting all my ports with the same brush right now. SSH
really doesn't need broad access ever. It just needs to follow me
around the globe. Web and FTP are a different story, but I don't need
to expose SSH to the same leniency.

[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?

Yes and no. These guys are, but not IBM anymore:
http://www.ecomstation.com

I'd be extremely wary of using
unpatched software of that age in any hostile setting.

The OS software vintage is actually 2003 or so. The software I'm
running on it is quite a bit newer than that and is still kept up to
date. It's neigh bulletproof, but it's also behind my firewall with a
masquerade set up for the HTTP port. It also has some virtual desktop
software which is old enough to make me nervous, so I leave that off
until I activate it with a CGI through the web server. It only permits
a single login so I know that while I'm in, nobody else can be. Then I
kill it off when I'm done with another CGI script.

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.

I was talking about the opposite way around. In other words, using the
web access as a "knock" to open up the SSH port. But the more I thought
about it, it introduces an additional point of failure. The hardware on
that machine is aging.

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.

Agreed.

--
Reverse the parts of the e-mail address to reply by mail.
.

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)
Loading