Re: Scan of TCP 552-554
From: Rodrigo Barbosa (rodrigob_at_suespammers.org)
Date: Fri, 25 Jul 2003 15:22:53 -0300 To: Incidents <firstname.lastname@example.org>
On Thu, Jul 24, 2003 at 06:10:30PM -0500, Frank Knobbe wrote:
> For example, if you do a TCP scan from port 135 to port 140 on a Windows
> box, and you receive nothing on 135, 136, 137, 138, 139, but a TCP Reset
> on 140, there is a high probability that an admin only put a firewall
> rules in place that simply says 'drop 135-139' to cover the RPC/NetBIOS
> range, but left the system otherwise unprotected, with Windows sending a
> Reset on port 140. (Of course you might want to confirm by 'pinging' a
> couple other closed ports, like port 109 or something).
That is something I have been wondering for a while.
On my firewall, I can set the blockage to either drop the package,
send a tcp-reset back, or an asorted lot of icmp messages.
I figured that sending a tcp-reset would help to hide the firewall. On
the other hand, it would cause extra traffic (which could help a DoS attempt).
Also, sending an icmp-administratively-forbidden message back would be the
'polite' thing to do. After all that, I would what would be the best practice.
On small links, I usually choose to use tcp-reset. After all, it's
pretty easy to do a DoS on those links. And the less information an
would-be-attacker get on my system, the better. On the other hand (3 hands!??!),
the tcp-reset package do carry some information about my host.
So, all in all, I'm a little lost of which is the better option to use.
-- Rodrigo Barbosa <email@example.com> "Be excellent to each other ..." - Bill & Ted (The Wild Stallions)
- application/pgp-signature attachment: stored