And it was exactly adaptative scanning I was thinking of. It is very easy, when the firewall drop packages, to determine that it IS a firewall, and the expected response time. So, it can simply change it's scanning timings to the expected values. In this case, droping packages would do nothing to slow the scanning. This kind of thing can be some pretty fast. One only have to check the ports that are usualy open (53/udp, 25/tcp and 80/tcp) and once that is usualy closed (1,2,3,5,7,9/tcp). 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. These are just sort of idle toughts, of course. There is many variables here. Slowing down the attack is some, for sure, and I do see your point. I think we have to consider the following points: 1) How much do we really slow down attacks by droping packages, specially considering things like adaptative scanning 2) How much do we hide the firewall, by using tcp-reset ? Do we hide it at all ? 3) If slowing down is not really possible, and hiding the firewall is also not possible, why not just be nice, and answer with adm-forbidden messages and such ? []s On Mon, Jul 28, 2003 at 11:40:15AM -0600, Russell Harding wrote: > Rodrido, > > When configuring my new firewall, I had this exact thought, and decided > to silently drop as most firewalls, thinking I was likely missing > something. > > I think the reason to drop, rather than reply politely is the following: > scanning is much slower when packets are dropped. Try scanning a > firewalled host which has packets dropped, and compare to an unfirewalled > host which responds with RSETs, the time difference is dramatic. > > <thought> > I have often wondered if adaptive scanning techniques will be used > against this common policy. For example, if RTT times are short for all > ports != 135-139, do we have to wait for a full timeout? or perhaps RTT*3? > or a scaner which will pick up stray RSET's and figure out which probe > they were responding to, etc.... > </thought> > > -Russell > > On Fri, 25 Jul 2003, Rodrigo Barbosa wrote: > > > 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 <rodrigobat_private> > > "Be excellent to each other ..." - Bill & Ted (The Wild Stallions) > > > > -- Rodrigo Barbosa <rodrigobat_private> "Be excellent to each other ..." - Bill & Ted (The Wild Stallions)
This archive was generated by hypermail 2b30 : Mon Jul 28 2003 - 12:52:15 PDT