>>>
>>> Also, why wouldn't you just buy an inexpensive box to run as a linux
>>> iptables firewall since you're planning on using iptables anyway
>>> instead of buying some expensive firewall appliance or running
>>> iptables on each box?
>>>
>> Mostly it is a performance issue (I guess), see my other response
>> (from before this one).
>
>
> Ian may be able to say for sure about handling the 180Mbps figure you
> quoted, but I know that NKS has tons of "beige box" linux-based
> firewalls all over the place handling tons and tons and tons of
> network traffic without any problem at all. From your other post about
> the architecture, I don't really see that having one fairly powerful
> firewall box would really be any problem for what you want to do. Put
> a few interfaces in it and bind them or just put them up on multiple
> IP addresses to spread the load across. I know there are people doing
> gigabit on linux with iptables/netfilter and snort and aren't going
> out and buying eight-way 4Ghz Opteron boxes to do it.
>
If we are going to put in a standalone firewall, it will probably be
Cisco; I can't *guarantee* to my bosses that the performance would be as
good with a Linux solution, though I suspect that it would. "Nobody ever
got fired for buying Cisco." To be fair, we have a rather
latency-sensitive, 'realtime' application. Even if the solution is good
at handling bandwidth, we need to be careful about latency.
> Centralizing the firewall also gives you the
> single-point-of-analysis/response for snort. Otherwise you're either
> building a big machine anyway to connect to a span-port on your switch
> (which always seems to be at least a little problematic if not
> downright busted) or putting snort on all of your application servers,
> which it sounds like are already pretty heavily loaded.
>
I am leaning towards the span-port solution for IDS, but we might
actually go with one copy of snort on each application server (our
current switch doesn't support mirroring).
>> The automatic IDS is probably going to be a must, just because of
>> speed. By the time a beeper message has gotten from snort to our
>> sysadmin (and we do not have a 24/7 admin staff), and he has SSH'd in
>> to see if there is an attack, several of our applications could have
>> been crippled (very expensive, and bad PR). I would rather lock-out a
>> kosher user and take 30 minutes to let them back in, than have all of
>> our remote users (hundreds) frozen-out by a DOS attack for 10 minutes.
>
>
> Then you probably still want to use snort with flexresp. It will block
> connections that match the rule you've specified, without having to
> mess about with your iptables rules. (trying to automagically manage
> iptables rules is just really really messy, and I really don't suggest
> it, no matter how important the auto-respond thing is. Best case
> scenario is that it blocks valid users for a while, worst case
> scenario is that the rules insert/delete/modify gets messed up and
> your whole firewall barfs its guts for the whole world to get access
> to....)
>
flexresp only works if snort is running on a box that isolates the rest
of the network (e.g. a dedicated firewall), or am I mistaken? I am
looking at "Guardian" which reads the snort logs and manipulates
IPTables (and IPChains, ipfwadm, PIX, etc). Guardian has a whitelist
feature that I consider critical to keep us from getting locked out of
our machines.
> The other obvious (and tactless) question is, how poorly is this
> application written that it can be so easily Pwn3d that you need this
> kind of feature and wouldn't it be worth it to spend some of the
> resources hardening the app than building a big IDS infrastructure to
> protect it?
I have been similarly tactless with my superiors, and they are tired of
hearing it.
--ronan
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:16:06 EDT