Re: Scan of TCP 552-554
From: Chris Shepherd (chriss_at_whstuart.com)
Date: 07/30/03
- Previous message: Christian Kieft: "Re: Exploit for Windows RPC may be in the wild!"
- In reply to: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Next in thread: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Reply: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 30 Jul 2003 09:58:42 -0400 To: incidents@securityfocus.com
Quoting Rodrigo Barbosa <rodrigob@suespammers.org>:
> My reasoning is that you have to trust your firewall. Sooner or later, the
> atacker will bruteforce it. So, the longer it takes for the
> attacker to understand there is a firewall there, the better. That is
> why I'm considering using tcp-reset. This way, the attacker will hit
> the traps faster. Maybe even same traps that will block his attack
> entirely.
The assumption here is that your attacker will be fooled by using tcp-reset.
This is a bad assumption especially when there are active in use services on
the host (ie: HTTP, SMTP, DNS, etc.).
An example:
I decide I want to scan host A. Host A is really nothing more than a firewall
that NATs port 80 back through to host Z. All I need to do to figure out if a
firewall is in place with tcp-reset is to watch the TTL of reply packets using
nothing more than tcpdump. If it decrements one further on port 80 than it does
on any other firewalled port, then I know for sure the box doing the responding
on closed ports is in between my machine and host Z, which indicates a real
good possibility of a firewall. This could be countered if you were to reset
the TTL on all outbound packets at the firewall to a consistent value, but as
you've mentioned, it would only delay the inevitable. Other things come into
account like measuring average response times, etc., etc.. If you were to chart
it out, it would by necessity take longer to respond to a valid connection
through host A to 80 on host Z than it would to receive the response to a
closed port from host A.
I have always worked from the assumption that I can never hide a box from a
skilled attacker, only make it hard to find for an unskilled one. In that
light, I would rather slow down an attacker as much as possible during his
investigation phase than I would try and conceal the fact that I have a
firewall in place. I've had one concerted effort on our network here, but a lot
more scans (one guy kept scanning for quite a few days, but gave up). I think
it stems from the fact that people in general are impatient. Why waste all this
time on my hosts here when they could go out and find an open box to break
into?
You specifically say you have to trust your firewall, and then try and conceal
its presence. The point in question is whether or not making it look like a
real machine will delay an attacker more than simply dropping all traffic. IMHO
the latter is the better overall solution, since once your firewall has been
discovered, it will slow and frustrate attempts on your network.
-- Chris Shepherd --------------------------------------------------------------------------- ----------------------------------------------------------------------------
- Previous message: Christian Kieft: "Re: Exploit for Windows RPC may be in the wild!"
- In reply to: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Next in thread: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Reply: Rodrigo Barbosa: "Re: Scan of TCP 552-554"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
