Quoting Rodrigo Barbosa <rodrigobat_private>: > On Fri, Aug 01, 2003 at 08:25:08AM -0400, Chris Shepherd wrote: > > Why take that action for a port scan? You're going to be a very busy admin > > if you do all that just for a simple port scan. Those things are > > unimportant, but might be useful if logged, or better yet, dropped. :) > > There's nothing wrong with a port scan in and of itself, it is just a > > simple check to see which services you have listening. > > As long as I'm the one paying for my Internet uplink (and those are > EXPENSIVE here in Brazil), I don't want any traffic on it that is > not authorized. And a portscan is definitively samething I did not > authorized. Regardless of whether you filter it or not, it has already bypassed your ISP's routers, and is using YOUR bandwidth. The packets are getting to you either way, dropping their packets after they have hit your network doesn't stop them from utilizing your bandwidth, and in fact, that further increases the argument for a simple drop-all approach, since you will, in the event of a portscan, send replies, thus using more of your bandwidth than if you had simply dropped them. You really in actuality have little say in the matter. Even if you had a firewall set to drop all traffic, it has to come across your link to get to your firewall in order to be dropped, which is using your bandwidth. > > A policy of having a live person react to a port scan is a little farther > > than I'd be willing to go ever, which is why I simply have my firewall > > refuse to talk on any port that doesn't have a service running. Closed > > ports are not a security risk, > > Don't be so sure. IIRC, there was a bug on same platform that was only > exploitable on "closed" ports. Do you feel this bug is relevant to this conversation in relation to your setup? > > nor are portscans. The security risks come into play on the > > services you already are running. The biggest reason why someone in your > > shoes might want to consider using DROP vs REJECT is that it offers a higher > > delay in accessing those services. Regardless of your firewall, if you have > > a service in place, that is far more likely to become the subject of > > attack, and wanting to conceal those services from port scanning is a more > > intelligent approach (IMO) than wanting to try and conceal the firewall's > > existence. The point of intrusion shouldn't be at the firewall if it is > > properly configured, but rather, the hosts behind it that are by necessity > > running servers (Apache or IIS for example). > > Security risks are one thing. Costing me money is another. Security holes > costs money, but portscans use my link. Even worms that are unable > to infect my system costs money. Yes, and as I said, I don't see how you believe you are being cost any less money, in fact, you would be generating outbound traffic by sending the tcp-resets, and therefore replying to said packets. If you host a server on the internet, you cannot prevent anyone from accessing any purposefully enabled and accessible services in any reliable fashion. That is to say, if you have configured a network whereby you have some servers being natted to across a firewall, you have no sure-fire way of preventing valid/invalid traffic from reaching your hosts, and thus using your bandwidth, short of dropping the appropriate routes at your ISP. Indeed, you will only create more cost for yourself if the situation is as tight as you describe it. -- Chris Shepherd --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Aug 01 2003 - 14:12:53 PDT