[c-nsp] what type of firewall/ids

[Mike Butash]

Scott,

	Just out of curiosity, how do you leverage using CSA in your 
environment?  I toyed with it a bit to adapt the stripped-down versions 
that ship with call-manglers and various other voice-related win-servers 
for applications it didn't explicitly know to allow, but it was not for 
the faint of heart or for recreational dabbling.  The only other option 
is to use VMS, which was an atrocious piece of software we quickly 
abandoned all hope for, and CSA seemed to require very in depth 
familiarity to modify without.  VMS didn't seem to really offer much to 
boot for dealing with the nitty-gritty of system level process tracking 
CSA does. There was little to no documentation on how to configure the 
clients as such, little in the way of of a client api for easing the 
pain, their xml configs weren't terribly intuitive by themselves, and 
overall it seemed specifically tailored to an OEM integration partner 
with *privileged* access to documentation the general paying population 
would not receive.  When bugging my SE on the matter, he pretty much 
confirmed it was meant for a partner integration ala IPCC only.  Do you 
simply outsource to deemed CSA experts or do you take more of an 
in-house development approach?  Because of the walled-garden approach 
they seemed to take with usage of their product, we dismissed it as a 
viable product without thrusting ourselves down a dark and foreboding 
rabbit hole.

	If you use CSA widespread, I'd be interested in knowing what 
methodology you use to maintain, modify, template, and develop new 
models for server-types.  I find most windoze admins know little about 
the inner workings and dependencies of application dll system calls and 
file system permissions CSA relies explicitly on to make it truly 
effective.  Typically because it is a Cisco product, my network team 
ended up owning the products as such, and as a lowly network monkey, 
it's hard for me to tell our systems groups how they should secure their 
systems generally, glean how exactly they do so to begin with, nor do i 
have time to debug system-level application interaction for them.  ;)

-mb


Voll, Scott wrote:
> And if your looking for Day Zero protection, you might want to look at
> Cisco's CSA client.  Has done a very good job of keeping worms / viruses
> off servers for us.
> 
> Scott
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mike Butash
> Sent: Tuesday, July 11, 2006 2:47 AM
> To: Shaun
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] what type of firewall/ids
> 
> Depends what kind of capacity, connections, and throughput you need 
> really.  I've found the Cisco FWSM's are about the highest capacity 
> firewall out there in terms of sheer connections, new connection 
> setup/teardown, and overall throughput capability.  Nothing else on the 
> market touches their capacity that we found, and they offer some 
> built-in management though object-group use if you get creative. 
> Pix/FWSM gui via pdm/adsm is limited (read worthless) for advance users,
> 
> but I'm not a gui person so take it for what you will.  The fwsm's are a
> 
> preference when nothing less than several gigs are required, and when 
> paired to the cat6500's are capable of some very cool things.  I've run 
> them with 50k+ ace's (compiled) under significant ddos's and not seen 
> them blink.  Of course, this is somewhat variable on pps, new connection
> 
> setups, etc, so caveat emptor.  ;)
> 
> I've used netscreens in the past and found their cli configuration 
> somewhat hokey with use compared to pix/fwsm equivalents, though I hear 
> since the juniper acquisition they've gotten better.  I could only stand
> 
> using them via their gui at the time, which was about 4 years ago.  Of 
> course, take this with a grain of salt from an old cisco guy...  Can't 
> much attest to much else with the NS's short of their own reps telling 
> us they couldn't touch a FWSM in terms of capacity and connections.
> 
> Riverhead/Cisco Anomaly Guards were a godsend as far as ddos protection 
> if you see a lot of it, though they are quirky and require some constant
> 
> babysitting.  Overall the appliances will take a full gig a piece 
> without issue, their only limitation is protecting a large footprint of 
> disparate hosts/ip's.  As with anything, they have quirks, bugs, things 
> they do better than others, etc, but overall they are an excellent 
> product if you are prone to random internet drive-by rapings in the form
> 
> of DDoS's.  They do not handle layer 5 and higher exploits, don't expect
> 
> them to...
> 
> As far as IDS, can't really go wrong with snort/sourcefire with 
> commodity server hardware and good nics.  Snortcenter makes a pretty 
> good aggregator of multiple sensor hosts as well.  I'd recommend using 
> passive/regeneration optical taps over span sessions (netoptics brands 
> work well though experience).  Monitor/span sessions come with a lot of 
> caveats you'll want to avoid, although your physical fiber plant will 
> get somewhat complex with taps in place - document the runs and test 
> failover situations twice.  You'll save yourself something like 
> overrunning the cat6500 buffers if you ever push more traffic through 
> the src port than the dst ports allocated to the monitor sessions and 
> crashing the box.
> 
> As far as IPS, we've used tipping points, but really have to question 
> overall what an IPS offered other than pretty reports to managers of 5yr
> 
> old exploits noted and *defended against* en masse.  I think there was 
> only one situation they ever presented actual usefulness under a ddos 
> situation, and it was very niche.  They added a LOT of complexity and 
> overall limitations to our network infrastructure that put serious 
> question to their overall usefulness and purposefulness.  For instance, 
> in normally fully meshed routed environments, their stateful nature 
> requires them to see full two-way conversations, which limit your 
> network to active/passive paths maintained though IGP costs or some 
> such.  If you are running less than a gig of throughput in a simple 
> routed environment, you're probably fine to use them to your 
> satisfaction, but when facing anything that requires multiple 
> port-channeled gige's/10G (don't think TP's can do 10G yet) and 
> multipath full-mesh routing is impossible with these beasts in-line.
> 
> IMHO, you're better off maintaining a good security posture and patch 
> regiment with your hosts that are internet facing and keeping your 
> firewalls locked down tightly.  If zero-day windoze attacks hit, you're 
> likely to still be screwed before someone updates the IPS, but they 
> might save you grief if M$ decides to wait a month to release patches as
> 
> they've been known to do.  More possible protection generally means 
> better, but with their network integration complexity and overall 
> limiting of network capacity for the IPS throughput, I think the only 
> reason they are still in use is the CISO didn't want to admit he wasted 
> capex on them...  ;)
> 
> -mb
> 
> 
> Shaun wrote:
>> What brand/model firewall/ids hardware are you guys out there using to
> block 
>> incomming/outgoing attacks, port scans, brute force attempts, etc.
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>