You lose some anonymity, as the PIX will now reset the odd connections &
portscan attempts. Although security through obscurity is not a good
defense in and of it self, it doesn't hurt. It was always an added bonus
on the PIX, and you lose that. It's value is debatable.
In doing attack resilience testing, with the PIX under extreme loads, the
addition of service resetinbound added a minor amount to the memory
processing overhead. So I don't think you'll see any performance impact
under normal conditions, as it was not noticeable under extreme conditions.
I can't think of any other concerns, but corrections always welcome.
Thanks,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
At 05:40 PM 03/13/2000 -0800, Yi Liu wrote:
>Any disadvantages for using service reset inbound vs. standard behavior of
>silently dropping connections?
>
> YL
>
> > -----Original Message-----
> > From: Lisa Napier [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 13, 2000 11:36 AM
> > To: Ron DuFresne; [EMAIL PROTECTED]
> > Cc: Pere Camps; [EMAIL PROTECTED]
> > Subject: Re: Port 113
> >
> >
> > Groan... Apologies to all. I can only say it was a
> > pre-coffee url copy.
> >
> > Here's the real one:
> >
> >
> <http://www.cisco.com/warp/public/110/2.html>http://www.cisco.com/warp/pub
> lic/110/2.html
> >
> > Many thanks for pointing out my error.
> >
> > Lisa Napier
> > Product Security Incident Response Team
> > Cisco Systems
> >
> <http://www.cisco.com/warp/public/707/sec_incident_response.shtml>http://w
> ww.cisco.com/warp/public/707/sec_incident_response.shtml
> >
> > PGP: A671 782D 2926 B489 F81A 3D5E B72F E407 B72C AF1F
> > ID: 0xB72CAF1F, DH/DSS 2048/1024
> >
> > At 01:27 PM 03/13/2000 -0600, Ron DuFresne wrote:
> >
> > >Lisa,
> > >
> > >Yer URL, here, returns a "cannot connect to remote host" message.
> > >
> > >Thanks,
> > >
> > >Ron DuFresne
> > >
> > >
> > >On Mon, 13 Mar 2000, Lisa Napier wrote:
> > >
> > > > Hi all,
> > > >
> > > >
> <http://cco/warp/customer/110/2.html>http://cco/warp/customer/110/2.html
> > > >
> > > > This URL has the answers to the question.
> > > >
> > > > Thanks much,
> > > >
> > > > Lisa Napier
> > > > Product Security Incident Response Team
> > > > Cisco Systems
> > > >
> <http://www.cisco.com/warp/public/707/sec_incident_response.shtml>http://w
> ww.cisco.com/warp/public/707/sec_incident_response.shtml
> > > >
> > > > PGP: A671 782D 2926 B489 F81A 3D5E B72F E407 B72C AF1F
> > > > ID: 0xB72CAF1F, DH/DSS 2048/1024
> > > >
> > > > At 12:27 PM 03/11/2000 +0100, Pere Camps wrote:
> > > > >Hello,
> > > > >
> > > > > > request and tries again before giving up. There was
> > also mention
> > > of a way
> > > > > > to have the f/w do something other than silently drop
> > the packet to
> > > allow
> > > > > > the server to give up more quickly.
> > > > >
> > > > > Don't know how to set it up in pix, but what
> > you have to do is to
> > > > >REJECT the packets instead of DENYING them. DENY simply
> > drops them and
> > > > >REJECT drops them AND sends the client an ICMP
> > destination-unreachable
> > > > >packet.
> > > > >
> > > > > HTH.
> > > > >
> > > > >-- p.
> > > > >
> > > > >-
> > > > >[To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > > >"unsubscribe firewalls" in the body of the message.]
> > > >
> > > > -
> > > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > > "unsubscribe firewalls" in the body of the message.]
> > > >
> > >
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >"Cutting the space budget really restores my faith in humanity. It
> > >eliminates dreams, goals, and ideals and lets us get straight to the
> > >business of hate, debauchery, and self-annihilation." -- Johnny Hart
> > > ***testing, only testing, and damn good at it too!***
> > >
> > >OK, so you're a Ph.D. Just don't touch anything.
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
