Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Firewalls
[Top] [All Lists]

Re: Pix performance

Subject: Re: Pix performance
Date: Thu, 27 Jan 2005 17:14:29 -0600
Norwich University - Information Security <infosec@norwich.edu> wrote:

I have just inherited a PIX 515e and am wondering if it is capable (from
a performance perspective) of acting as our main firewall.

Given the term "inherited", you may wish to check the PIXOS version,
also if the device is currently using conduits, upgrading to the latest code
will require migrating the configuration to ACLs.


We are a small university with approximately 2500 users.  Our
incoming/outgoing bandwidth is 32Mb/s and can run any where from 4% to
90% utilization with a rough average of about 62% (20Mb/s).

Does anyone know from personal experience if the PIX 515e can reliably
handle this magnitude of usage doing both filtering and NAT?

By "filtering" are you referring to ACLs, or to web content filtering through an
off-box "censorware" solution? (NetNanny, Websense, Smartfilter, etc)


On Thu, 27 Jan 2005 14:54:48 -0500, Jason Albuquerque
<JAlbuquerque@northkingstown.org> wrote:

Yes a 515e is very capable of handling filtering and Nat and Some!! Here
it is used for Filtering, NAT, DMZ, ACL's, 4 VLANs, VPN and more for a
municipality.

The PIX should be able to handle this traffic under normal usage, I have run
into performance problems with PIX when even  a small number of internal
clients become infected with network scanning worms; in my particular case
the client was sourcing from a bogus IP address (a RFC1918 address not
actually used on the internal network), so TCP requests would be sourced
out from "trusted" but no replies would ever come back, seems to be a
state table issue.

Pre-filtering both inbound and outbound traffic to drop spoofed sources
mitigated the PIX issue until the underlying worm infestation was addressed.
Just one more "gotcha" to watch for.

Kevin Kadow

<Prev in Thread] Current Thread [Next in Thread>