Virus.Org  IT Security News and Information Portal. We offer the latest IT security news, updates, product reviews, books, and articles for all you IT security professionals out there. Enter and get the best IT security information on the Internet.

 

. Welcome to the Virus.Org Mailing List Archive  
.
.


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


Re: Scan of TCP 552-554
.

  • To: Chris Shepherd <[EMAIL PROTECTED]>
  • Subject: Re: Scan of TCP 552-554
  • From: Rodrigo Barbosa <[EMAIL PROTECTED]>
  • Date: Fri, 1 Aug 2003 14:26:03 -0300
  • Cc: [EMAIL PROTECTED]
  • In-reply-to: <[EMAIL PROTECTED]>
  • Mail-followup-to: Rodrigo Barbosa <[EMAIL PROTECTED]>, Chris Shepherd <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
  • References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
.
 
On Fri, Aug 01, 2003 at 08:25:08AM -0400, Chris Shepherd wrote:
> Quoting Rodrigo Barbosa <[EMAIL PROTECTED]>:
> > > In this case, it may make sense to keep your traps on a honeypot box. I'm
> > > having a bit of a difficult time understanding exactly what you mean
> > > by 'hit my traps faster, so I can react faster'. React how? What would your
> > > reaction to a port scan be? If you cite an example, I'll probably have a
> > >much clearer idea about what kinds of traps you're talking about. :)
> >
> > Errr, filter the address or network on the border router ? That is one.
> > Contact the admin of the network about the scan is another.
> 
> 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.

> 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.

> 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.

-- 
Rodrigo Barbosa <[EMAIL PROTECTED]>
"Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

Attachment: pgp8XXqGzqXJU.pgp
Description: PGP signature

 
.
.
 
Copyright (c) Virus.Org 1997-2006.
All Trademarks Acknowledged.
Please view our Terms and Conditions and our Privacy Policy.