subject:"I don't need no stinking firewall\!"


On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote:

 Further on, if you want to really protect against a real DDoS you would most 
 likely would have to look at a really distributed solution, where the 
 different geographical load balancing solutions come into play.

GSLB or whatever we want to call it is extremely useful from a general 
availability standpoint; however, the attackers can always scale up and really 
distribute their already-DDoS even further (they learned about routeservers and 
DNS tinkering years ago).  

Architecture, visibility, and control are key, as are 
vendor/customer/peer/upstream/opsec community relationships.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-08 Thread bill from home

All,
This thread certainly has been educational, and has changed my
perception of what an appropriate outward facing architecture should be.
But seldom do I have the luxury of designing this from scratch, and also
the networks I administer are small business's.
My question is at what size connection does a state table become
vulnerable, are we talking 1mb dsl's with a soho firewall?

Or as I suspect we are talking about a larger scale?
I know there are variables, I am just looking for a rule of thumb.
I would not want to recommend a change if it is not warranted.
But when fatter and fatter pipes become available at what point would a
change be warranted.

Thanks
Bill Kruchas

Dobbins, Roland wrote:

On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote:

Further on, if you want to really protect against a real DDoS you would most
likely would have to look at a really distributed solution, where the different
geographical load balancing solutions come into play.

GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago).

Architecture, visibility, and control are key, as are
vendor/customer/peer/upstream/opsec community relationships.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!


On Jan 8, 2010, at 8:22 PM, bill from home wrote:

 Or as I suspect we are talking about a larger scale?

Even an attacker with relatively moderate resources can succeed simply by 
creating enough well-formed, programatically-generated traffic to 'crowd out' 
legitimate traffic.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-08 Thread bill from home


Roland,
   I understand, but at the site we are protecting, at what point is 
the bottleneck the connection speed, and at what point is the state 
table the bottle neck.

It saves me the following uncomfortable conversation.

ME Mr customer, remember that firewall you bought a couple of years ago 
for .

Customer Yes...
ME We might better throw it out. And then you can pay me to harden your 
hosts.


Or I could just re cable, and leave it turned on, they would never know 
(just kidding).


And maybe there is no way to tell, but I feel I need to ask the question.

Thanks Bill Kruchas

Dobbins, Roland wrote:

On Jan 8, 2010, at 8:22 PM, bill from home wrote:

  

Or as I suspect we are talking about a larger scale?



Even an attacker with relatively moderate resources can succeed simply by 
creating enough well-formed, programatically-generated traffic to 'crowd out' 
legitimate traffic.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!


On Jan 8, 2010, at 9:02 PM, bill from home wrote:

 And maybe there is no way to tell, but I feel I need to ask the question.

Situationally-dependent; the only way to really tell, not just theorize, is to 
test the firewall to destruction during a maintenance window (or one like it, 
in the lab).

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

RE: I don't need no stinking firewall!

2010-01-08 Thread Joel Snyder




On Thu Jan 07, 2010 at 01:04:01PM -0800, Jay Hennigan j...@west.net wrote:


Or better:
- Allow from anywhere port 80 to server port  1023 established

 Adding established brings us back to stateful firewall!


Not really.  It only looks to see if the ACK or RST bits are set.  This 
is different from a stateful firewall which memorizes each outbound 
packet and checks the return for a match source/destination/sequence.


Actually, most firewalls don't check TCP sequence numbers.  You are 
totally correct in that stateless packet filters with established are 
only looking for TCP bits, but the main difference that stateful 
firewalls add is watching the TCP state machine.  Sequence number 
watching is a bonus, something you can enable on some firewalls, but 
most of the common ones don't do it by default.


jms

--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

Re: I don't need no stinking firewall!

2010-01-08 Thread Valdis . Kletnieks

On Fri, 08 Jan 2010 08:22:00 EST, bill from home said:

 My question is at what size connection does a state table become 
 vulnerable, are we talking 1mb dsl's with a soho firewall?

Security - you're doing it wrong. ;)

The question you *should* be asking yourself is at what size connection am I
enough of a network presence that I might attract attention from somebody who
might want to attack me?  And that depends more on the *type* of presence than
the size of the pipe.

If you're a small electrical-components design firm that nobody's heard of, the
size of your state table is probably moot.  One of your users just drew the
attention of some random 4chan /b/tard, the size of the state table is again
probably moot. ;)

But to answer your question - it's so absurdly easy for a competent(*) attacker
to saturate any edge connection smaller than a gigabit or so, that 'state
table exhaustion' is only *really* an issue if you have a 10G or bigger
pipe.

(*) There is of course the case of an incompetent attacker who only has a
botnet of a few hundred machines, attacking a small pipe. At that point, it's
probably a crap shoot - if your firewall falls over, you've been DDoS'ed. But
if it doesn't fall over, you'll probably *still* be DDoS'ed because the machines
you're protecting fall over...



pgpj9NQpfiqdL.pgp
Description: PGP signature

Re: I don't need no stinking firewall!

2010-01-08 Thread Joe Greco

 All,
 This thread certainly has been educational, and has changed my 
 perception of what an appropriate outward facing architecture should be.
 But seldom do I have the luxury of designing this from scratch, and also 
 the networks I administer are small business's.
 My question is at what size connection does a state table become 
 vulnerable, are we talking 1mb dsl's with a soho firewall?
 Or as I suspect we are talking about a larger scale?
 I know there are variables, I am just looking for a rule of thumb.
 I would not want to recommend a change if it is not warranted.
 But when fatter and fatter pipes become available at what point would a 
 change be warranted.

For small pipes, a simple DoS is trivial enough to jam up the works
without worrying about the state table size.

However, that doesn't mean it isn't smart to get a handle on it. 

The biggest question may be pipe size:  this variable controls the total
possible PPS that can be tossed at the firewall.

If you consider a technology such as 10base-T Ethernet, that's 10 megabits
per second.  When you add up the IFG, MAC preamble, dest/src, MAC type,
payload, and CRC, the smallest Ethernet frame is 84 bytes.  10M/(84*8) =
14880 frames per second.

Now let's say you want to block a SYN flood from hitting your server 
(nobody need tell me that there are obvious problems with this; this 
is an educational exercise).  If your firewall is configured to expire
state table entries for partially opened connections after 15 seconds,
the speed of ethernet combined with the 15 seconds means you need a
table that's 225,000 entries large.

But wait.  If they're blowing 14880 frames per second at you, that
Ethernet's quite full.  You're already getting DoS'ed by capacity.

Further, what happens when the attack moves to simply fully opening
connections?  Your state table is tiny for that...

I know this is NANOG, and it's network-centric.  However, fundamentally,
a stateful firewall fuzzes the boundary between network and server.  It
is taking on some duties that have typically been the responsibility of
the server.  So I'm going to go off on a tangent and say that it may be
useful to consider the state of the art in server technology.

A good UNIX implementation (OpenBSD, FreeBSD, maybe Linux ;-) ) will be
hardened and further-hardenable against these sorts of attacks.  The
server *already* has to do things such as tracking SYN's, except that
they no longer have to - they can issue cookies back and then simply 
forget about it.  If the cookie is returned in the ACK, then a 
connection is established.  A proper implementation of this means that
a server using SYN cookies has an infinitely large SYN queue; packets 
on the network itself are actually the queue.  The technique works and 
scales at 1Mbps as well as it does at 10Gbps.  

Putting a stateful firewall in front of that would be dumb; the server
is completely capable of coping with the superfluous SYN's in a much
more competent manner than the firewall.

I won't go into this in more detail.  You can look to see what the IRC
networks are doing to protect themselves.  They're commonly beat up and
have learned most of the best defense tricks around.

A stateless firewall that can implement filtering policies in silicon
is absolutely a fantastic thing to have, especially when faced with a
DoS for which you can write rules.  Put your servers behind one heck of
a good stateless firewall, and run a well-tuned OS.  You'll be a lot
more DoS-resistant.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: I don't need no stinking firewall!

2010-01-08 Thread Joel Jaeggli



bill from home wrote:
 All,
This thread certainly has been educational, and has changed my
 perception of what an appropriate outward facing architecture should be.
 But seldom do I have the luxury of designing this from scratch, and also
 the networks I administer are small business's.
 My question is at what size connection does a state table become
 vulnerable, are we talking 1mb dsl's with a soho firewall?

some numbers,

100Mb/s will carry 220Kpps worth of 64byte packets, if this is a fairly
simple syn attack and your firewall can support 100k new connections a
second (that's a fairly fast firewall), you need less than 50Mb/s to
nuke it... the maximum size of the state table on a linux derived system
with 4GB of ram is north of a million connections so assuming the
session rate of the dos is trackable your firewall needs to start aging
connections out in an accelerated fashion after about 4 seconds
otherwise you're similarly hosed...

given the same firewall can probably forward 2-3mpps when it comes to
small packet you run out of state long before your run out of forwarding
horsepower.

Some kind of firewall device that you might put in front of a business
cable connection, or fractional ethernet is like to support a much lower
connection rate embedded Pentium equivalent or low to mid-range mips
might support a rate of 2-10k connections per second at which point the
thresh-hold for dosing it based on session rate is quite a bit lower
(quite a bit lower than that of a webserver or dekstop pc for example).
i.e. if 10kpps of dos will take it out that's like 5Mb/s on a device
that might other wise be able to forward 300-500Mb/s interface to
interface using large packet.

 Or as I suspect we are talking about a larger scale?
 I know there are variables, I am just looking for a rule of thumb.
 I would not want to recommend a change if it is not warranted.
 But when fatter and fatter pipes become available at what point would a
 change be warranted.
 
 Thanks
 Bill Kruchas
 
 
 Dobbins, Roland wrote:
 On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote:

  
 Further on, if you want to really protect against a real DDoS you
 would most likely would have to look at a really distributed
 solution, where the different geographical load balancing solutions
 come into play.
 

 GSLB or whatever we want to call it is extremely useful from a general
 availability standpoint; however, the attackers can always scale up
 and really distribute their already-DDoS even further (they learned
 about routeservers and DNS tinkering years ago). 
 Architecture, visibility, and control are key, as are
 vendor/customer/peer/upstream/opsec community relationships.

 ---
 Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

 Injustice is relatively easy to bear; what stings is justice.

 -- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-08 Thread Joel Jaeggli



Dobbins, Roland wrote:
 On Jan 8, 2010, at 9:02 PM, bill from home wrote:
 
 And maybe there is no way to tell, but I feel I need to ask the question.
 
 Situationally-dependent; the only way to really tell, not just theorize, is 
 to test the firewall to destruction during a maintenance window (or one like 
 it, in the lab).

see my post in the subject, a reasonably complete performance report for
the device is a useful place to start. if you know what the maximum
session rate and state table size for the device are, you have a pretty
good idea at what rate of state instantiation it will break. rather
frequently it's more than two orders of magnitude lower than the peak
forwarding rate.


 ---
 Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
 
 Injustice is relatively easy to bear; what stings is justice.
 
 -- H.L. Mencken

Re: I don't need no stinking firewall!


On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote:

 see my post in the subject, a reasonably complete performance report for the 
 device is a useful place to start. 

The problem is that one can't trust the stated vendor performance figures, 
which is why actual testing is required.  I've seen instances in which actual 
performance is 5% or less of vendor assertions (i.e., vendor constructed a 
highly artificial scenario in order to be able to make a specific claim which 
doesn't hold up in real life).  

Also note that most vendors don't perform negative testing, astonishing though 
that may seem.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-08 Thread Joel Jaeggli



Dobbins, Roland wrote:
 On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote:
 
 see my post in the subject, a reasonably complete performance 
 report for the device is a useful place to start.
 
 The problem is that one can't trust the stated vendor performance 
 figures, which is why actual testing is required.  I've seen 
 instances in which actual performance is 5% or less of vendor 
 assertions (i.e., vendor constructed a highly artificial scenario in 
 order to be able to make a specific claim which doesn't hold up in 
 real life).

I'll go out on a limb and just quote myself since you didn't fully.

 if you know what the maximum session rate and state table size for
 the device are, you have a pretty good idea at what rate of state 
 instantiation it will break. rather frequently it's more than two 
 orders of magnitude lower than the peak forwarding rate.

two orders of magnitude lower is 1% of forwarding rate. It could be
lower but it's probably not 3 orders of magnitude.

rfc 3511 testing won't tell you that much that's useful in the real
world. but it will tell you how many concurrent sessions you can
establish (which is almost purely a function of the amount of ram for
that data strcture) through the DUT and how quickly you can establish
them (which may vary with your rule base but will almost certainly never
get better). vendors are mostly honest about that becuase you can
trivially replicate that test even with fairly low end equipment on all
but the biggest stateful devices.

 Also note that most vendors don't perform negative testing, 
 astonishing though that may seem.

 ---
  Roland Dobbins rdobb...@arbor.net // 
 http://www.arbornetworks.com
 
 Injustice is relatively easy to bear; what stings is justice.
 
 -- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-07 Thread Jay Hennigan


Nenad Andric wrote:

On Tue Jan 05, 2010 at 01:04:01PM -0800, Jay Hennigan j...@west.net wrote:



Or better:
- Allow from anywhere port 80 to server port  1023 established


 Adding established brings us back to stateful firewall!


Not really.  It only looks to see if the ACK or RST bits are set.  This 
is different from a stateful firewall which memorizes each outbound 
packet and checks the return for a match source/destination/sequence.


--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: I don't need no stinking firewall!

2010-01-06 Thread William Pitcock

On Wed, 2010-01-06 at 01:47 -0600, James Hess wrote:
 On Tue, Jan 5, 2010 at 11:41 PM, Dobbins, Roland rdobb...@arbor.net wrote:
  On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote:
  DDoS attacks are attacks against capacity and/or state.  Start reducing
 
 DDoS,  by its very nature is a type of attack that dances around
 common security measures  like  conventional firewalls, by its very
 nature.
 
 The possibility of someone dropping a nuke on your facility,
 shouldn't stop you from locking your doors at night.
 If necessary, use another arrangement to detect that threat, and
 protect firewall+servers from it.
 

DDoS mitigation gear tends to choke up in my experience.  It's a really
touchy subject.

 Having no 'firewall' type safeguard at all  (stateless or otherwise)
 would appear pretty risky.

Not really, because firewalls don't do anything useful.  Stateless ACL
policies do something useful, and usually that is handled in the router
in a modern network.  The other features of a firewall range from not so
useful to actively harmful.

 
  Because, by definition, all incoming packets to the server are unsolicited.
 
 For UDP servers sure..  not for TCP..  the initial SYN is unsolicited,
 for inbound  TCP connections.  Once the server acknowledges the
 connection by invoking  accept(),  the rest of it the packets are
 solicited,  the packets are either part of an active connection,  or
 unwanted.

Wrong.  You seem to assume that TCP stacks are well-behaved, or that
botnets aren't just synthesizing junk.  I've seen unsolicited ACK floods
before.  They are quite real.  So, in fact, all incoming packets should
be considered unsolicited until proven otherwise.

It should be mentioned that DDoS mitigation gear in use on that network
let those packets through without even alerting us about it.

William

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 2:47 PM, James Hess wrote:

 Overflowing the state table   then  becomes only  a  possible
 outcome  that has some acceptable  level of probability,   assuming
 that your  other protections have already failed...

Wrong.  The attacker just programmatically generates semantically-valid traffic 
which is indistinguishablle from real traffic, and crowds out the real traffic.

All those fancy timers and counters and what-not don't matter.

I've seen it done over and over again.  Why some folks seem to think this is 
theoretical or that I somehow haven't thought of something they think will 
prove to be a magic solution is really beyond me, heh.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 3:03 PM, William Pitcock wrote:

  So, in fact, all incoming packets should
 be considered unsolicited until proven otherwise.

Concur - it works this way, as well.  At one extreme, completely pathological, 
at the other extreme, perfectly normal - just faux.

;

 It should be mentioned that DDoS mitigation gear in use on that network let 
 those packets through without even alerting us about it.

This is where baselining and anomaly-detection can come into play, along with 
an understanding of valid/invalid states, if the system is designed correctly, 
heh.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-06 Thread William Waites



Le 10-01-05 à 21:29, Dobbins, Roland a écrit :

Stateful firewalls make absolutely no sense in front of servers,  
given that by definition, every packet coming into the server is  
unsolicited (some protocols like ftp work a bit differently in that  
there're multiple bidirectional/omnidirectional communications  
sessions, but the key is that the initial connection is always  
unsolicited).


Most hosts are in some measure servers and clients. Sometimes a server
might want to make an outbound connection for a legitimate reason (say
a DNS lookup or zone transfer). Sometimes it might be tricked into doing
so for nefarious reasons (like the old reverse telnet trick of binding
a shell to an outbound tcp connection). A properly configured firewall
will prevent latter.

-w

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 5:38 PM, William Waites wrote:

 A properly configured firewall will prevent latter.

So will stateless ACLs, running in hardware capable of handling mpps.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-06 Thread juttazalud

am Mittwoch, 06. Jänner 2010 um 13:43 schrieb Roland Dobbins:

 On Jan 6, 2010, at 5:38 PM, William Waites wrote:

 A properly configured firewall will prevent latter.

 So will stateless ACLs, running in hardware capable of handling mpps.

How do you define firewall?

I remember something like a security concept, comprising a device or
set of devices designed to prevent unauthorized access to a computer
system or network. ACLs would then just be part of the firewall
concept.

cheers,
jutta

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 8:25 PM, juttazalud wrote:

 How do you define firewall?

This threat was about stateful firewalls in particular.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-06 Thread Jared Mauch


On Jan 5, 2010, at 4:24 PM, Robert Brockway wrote:

 Do you have any evidence to support this assertion?  You've just asserted 
 that all firewalls have a specific vulnerability.  It isn't even possible to 
 know the complete set of architectures (hardware  software) used for 
 firewalls so I don't see how you can assert they all have this vulnerability.

Just about every ddos i've ever been involved in mitigation results in some 
device labeled firewall blowing it's brains and crippling the company further 
than if they had utilized a more distributed model.

When combined with various other layers of mitigation that are either 
integrated or inline with another device we've spent lots of time 
troubleshooting which exact device was causing the most trouble.

I can't cite specific cases unless my customers say I can, but it's somewhat 
amusing to watch some C* of a company realize they've wasted money on a 
device/service that actually made the problem worse in the face of an attack.

There are those that might say the protection devices were not properly used, 
configured, etc... and if that's the case, it reflects the sad state of the 
lack of maturity of the industry/tech.  (Or that it's obsolete).

- Jared

Re: I don't need no stinking firewall!

2010-01-06 Thread Jared Mauch


On Jan 6, 2010, at 3:12 AM, Dobbins, Roland wrote:

 Wrong.  The attacker just programmatically generates semantically-valid 
 traffic which is indistinguishablle from real traffic, and crowds out the 
 real traffic.
 
 All those fancy timers and counters and what-not don't matter.
 
 I've seen it done over and over again.  Why some folks seem to think this is 
 theoretical or that I somehow haven't thought of something they think will 
 prove to be a magic solution is really beyond me, heh.

The reality is they just have not been attacked yet, and hence have no 
experience in what to do about the problem...

- Jared

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 8:42 PM, Jared Mauch wrote:

 The reality is they just have not been attacked yet, and hence have no 
 experience in what to do about the problem...

And they've been bombarded with misinformation for years by 'security' vendors, 
wildly unrealistic certification training courses, and the 'compliance' mafia; 
you're right, of course.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-06 Thread Tony Finch

On Tue, 5 Jan 2010, Kevin Oberman wrote:

 I suspect at least part of this will soon get fixed due to DNSSEC.
 Blocking tcp/53 and packets over 512 bytes will cause user complaints
 and, after enough education, the problem will get fixed.

Yes. Remember the root zone is due to be signed within the next six
months, and many nameservers (BIND in particular) request DNSSEC data by
default. You WILL have to deal with large DNS replies SOON - the first
ones from the root servers will appear this month.

http://www.root-dnssec.org/

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: I don't need no stinking firewall!

2010-01-06 Thread David Hiers

Poking the dragon a bit, aren't you?  Fun.

If you really look at it, there is no quantitative difference between
statefull and non-statefull.  A non-stateful firewall can prevent a
TCP session from entering the SYN_RECEIVED state by blocking the SYN
packet, so it strongly impacts session state without really trying.  A
statefull firewall will venture a bit deeper into the state diagram
with a few more rules, but this is mostly a quantitative difference
when viewed at a behavioral level (disregarding the internal
implementation, of course).  Coders and marketeers will burn me in
effigy over this, but there's already a lot of people in that line...

In the most general terms, a firewall attempts to permit desired
traffic flows and block undesirable traffic flows.

Statefull ones attempt to do so using knowledge of the protocols'
state machines.

The work performed by a statefull firewall must be done, either  by
the ultimate endpoints (your servers, etc) or by a central enforcement
point (a firewall).  In other words, desirable traffic (like spice)
must flow, and undesirable traffic must not impede the former.

The rationale for the existence of firewalls is that you can enforce
the rules of the protocols more cheaply if you move some of the
enforcement into a specialized device (a statefull firewall).

If you care to engineer every end node such that they can enforce the
protocols' state machines in every case at every possible traffic
level, you have no need for firewalls at all.  At the current
triple-point of threat, product, and protocol, separation of function
is currently a useful method, nothing more.

David






On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson bjohn...@drtel.com wrote:
 Security Gurus, et al,

 I have my own idea of what a firewall is and what it does. I also
 understand what statefull packet inspection is and what it does. Given
 this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?

 Please respond on-list as I want to have some useful discourse and
 discussion in the clear. Flamers and Trolls will be disregarded. :)

 Thank you.

  - Brian


  CONFIDENTIALITY NOTICE: This email message, including any attachments, is 
 for the sole use of the
 intended recipient(s) and may contain confidential and privileged 
 information. Any unauthorized review,
 copying, use, disclosure, or distribution is prohibited. If you are not the 
 intended recipient, please
 contact the sender by reply e-mail and destroy all copies of the original 
 message. Thank you.

RE: I don't need no stinking firewall!

2010-01-06 Thread Brandon M. Lapointe

-Original Message-
From: David Hiers [mailto:hie...@gmail.com] 
Sent: Wednesday, January 06, 2010 10:50 AM
To: Brian Johnson
Cc: nanog@nanog.org
Subject: Re: I don't need no stinking firewall!

Poking the dragon a bit, aren't you?  Fun.

If you really look at it, there is no quantitative difference between
statefull and non-statefull.  A non-stateful firewall can prevent a
TCP session from entering the SYN_RECEIVED state by blocking the SYN
packet, so it strongly impacts session state without really trying.  A
statefull firewall will venture a bit deeper into the state diagram
with a few more rules, but this is mostly a quantitative difference
when viewed at a behavioral level -snip-

David

+1

As mentioned before, the line has substantially blurred with what current 
devices (routers/load balancers) can do in hardware.

Brandon L.

On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson bjohn...@drtel.com wrote:
 Security Gurus, et al,

 I have my own idea of what a firewall is and what it does. I also
 understand what statefull packet inspection is and what it does. Given
 this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?

 Please respond on-list as I want to have some useful discourse and
 discussion in the clear. Flamers and Trolls will be disregarded. :)

 Thank you.

  - Brian

  CONFIDENTIALITY NOTICE: This email message, including any attachments, is 
 for the sole use of the
 intended recipient(s) and may contain confidential and privileged 
 information. Any unauthorized review,
 copying, use, disclosure, or distribution is prohibited. If you are not the 
 intended recipient, please
 contact the sender by reply e-mail and destroy all copies of the original 
 message. Thank you.

Re: I don't need no stinking firewall!

2010-01-06 Thread Brian Keefer


On Jan 6, 2010, at 6:51 AM, Brian Johnson wrote:

  Like Roland, I've been doing
 this for over a decade as well, and I have seen some pretty strange
 things, even a statefull firewall in front of servers with IPS actually
 work.
 


What do you mean by work?  If you mean all three pieces ran for years 
without being seriously attacked, then that's really not the same thing as 
continued to perform assigned duties effectively in the face of a determined 
DDoS.

I'd venture to say the vast majority of network operators, including myself, 
have never faced a DoS worse than a miscreant kid with a cable modem.  The few 
customers I've talked to who have been DDoS'd have all said the firewall died 
first.

It's pretty simple.  Of the devices on your network that have to keep state, a 
firewall has to maintain far more of them, since it's the aggregate of many 
down-stream hosts.  The resources to maintain state are finite.  At some point, 
those finite resources will be exceeded, and that will happen to a device 
holding the aggregate before any other device succumbs to the same problem.

If the firewall goes down, that DoS's everything behind it.  Is that really 
better than having only a portion of the down-stream hosts unavailable?

IMO firewalls have been a crutch for far too long.  They're an excuse for not 
having tight host-based security and (more importantly) good patch-management.  
There really isn't a network perimeter any more any way.  If any of your hosts 
gets infected, they're going to attempt to infect their neighbors.  Worms have 
been doing this since they were invented and a network firewall offers very 
little protection against it.

Put another way:  Is it clear that spending money on fancy network firewalls 
and IPS is more effective at mitigating risk than investing the same money in 
patch-management and host-hardening?  I don't think so.

I'd also like to add a +1 to the statement firewalls break things in subtle 
and hard-to-debug ways.  The longest support calls are always those trying to 
figure out how the customer's firewall is breaking things, and then how to 
prove this to their $management so they'll approve disabling the offending 
feature.  Speaking of which, there are about 700MB of PCAPs that I'm supposed 
to be looking at right now...

--
bk

RE: I don't need no stinking firewall!

2010-01-06 Thread Brian Johnson

- Brian

 -Original Message-
 From: Brian Keefer [mailto:ch...@smtps.net]
 Sent: Wednesday, January 06, 2010 11:38 AM
 To: Brian Johnson
 Cc: NANOG list
 Subject: Re: I don't need no stinking firewall!

 On Jan 6, 2010, at 6:51 AM, Brian Johnson wrote:

   Like Roland, I've been doing
  this for over a decade as well, and I have seen some pretty strange
  things, even a statefull firewall in front of servers with IPS
 actually
  work.

 What do you mean by work?  If you mean all three pieces ran for
 years without being seriously attacked, then that's really not the
 same thing as continued to perform assigned duties effectively in the
 face of a determined DDoS.

By work I mean that it held-up under DDoS attack. The size of a DDoS
attack is the question. If I have enough resources a person can DDoS an
entire network, irrelevant of its equipment, that will make the network
un-usable and unreachable. Statefull firewall or not. They simply need
to fill up the inbound connection with traffic so that nothing else gets
through.

If your point is given unlimited inbound bandwidth that a stateful
firewall will fail (not work correctly), I can say that about any piece
of equipment.  And even if it does fail, does it matter if your
connection is full of useless traffic?

DDoS attacks are not designed to compromise or gather data about
networks. DDoS is the sledge hammer of the dubious to cause disruption.
It doesn't matter what you put in there (Statefull Firewall, IDS, IPS,
Router ACLS, et al...), if the connection is flooded, the network will
be unreachable. Does it matter if the equipment can't handle it if no
good traffic, that would need to be statefully inspected, is traversing
the connection?

 - Brian

 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for 
the sole use of the
intended recipient(s) and may contain confidential and privileged information. 
Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the 
intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original 
message. Thank you.

Re: I don't need no stinking firewall!

2010-01-06 Thread Valdis . Kletnieks

On Tue, 05 Jan 2010 23:14:05 CST, Ryan Brooks said:

 Everyone needs to listen to Roland's mantra: stateless ACLs in hardware 
 than can handle Mpps.  It's more than just a hint.

I suspect that more than a few need to be reminded that stateless ACLs in
switch hardware is just another name for switch that also does stateless
firewall.


pgpuUXwACAEWB.pgp
Description: PGP signature

RE: I don't need no stinking firewall!

2010-01-06 Thread Brian Johnson

 -Original Message-
 From: Brian Keefer [mailto:ch...@smtps.net]
 Sent: Wednesday, January 06, 2010 3:12 PM
 To: Brian Johnson
 Cc: NANOG list
 Subject: Re: I don't need no stinking firewall!

SNIP

 It's quite possible to flood the state table on a device with a
 fraction of the pipe's capacity, in which case a stateful device will
 fall over where a stateless device would not have.  This type of
attack
 will definitely degrade the service it's aimed at, and probably
degrade
 other services sharing the same pipe, but won't _necessarily_ kill
them
 as is the case when a stateful gateway falls over.

This would depend on the nature of the DDoS (how it was crafted). I
would agree that a DDoS designed to fill a state table would do this.
However, a DDoS can also be designed with large packets to fill up the
capacity of the connection. In this case it would depend on the amount
of bandwidth available. If total bandwidth / packet size  state table
size (rough formula), then your assertion is valid. But if not, then it
may be flawed. This goes back to the idea that the network
design/goals/intent is an unknown quantity in every statement made on
this matter.

 Typical scenario is $badguys DDoS one of your webservers.  If the
 gateway is stateless, your webservers grind to a crawl, but your DNS,
 e-mail, VOIP, etc probably still function to a degree.  Contrast that
 with site-wide outage if your gateway was stateful and
 crashed/rebooted/refused to pass traffic due to having the state table
 filled.

I'll give this to you, but this still depends on the previous point. I
know that under minimum packet sizes and using a pipe with  200 Mbps
capacity, I have seen a statefull firewall handle a large DDoS just
fine. The problem was that the packets that needed to get in to the host
couldn't, because the bandwidth was fully utilized. I also know that if
the state table on said device were to be filled, the box wouldn't crash
or reboot. It would just queue or drop the packets until a state slot
became available. The scope of the state table was so large though that
it would take a lot more traffic than the operation would ever purchase
to fill it up. Remember YMMV. :)

 You're not going to be able to stop $sophisticated_badguy from
 enumerating your services no matter how fancy your gear is.  Could you
 detect a distributed portscan that looks at 5000 proto/IP/port combos
 per day, across your IP space, each probe coming from a different IP?
I
 really doubt it.  If you have services listening, someone is going to
 find them.

So the port scan would tell them about services I want there to be
access to. I'm OK with that to a large extent. In practice if I do
detect a port scan (usually from a single IP address), this would lead
me to take prerequisite steps to block a future attack.

 IMO you're better off making sure only the services you intend to
 provide are listening, and that those services are hardened
 appropriately for public exposure.

OK. This is obvious to anyone with experience in these things. But I
also believe in a layered approach. It never hurts to add more layers to
prevent human error or even internal breaches as the different systems
are under the control of different equipment (servers, routers,
switches, security devices). It's like two supports holding up something
without knowing if the other one is doing its job. Both need to pull the
full weight in case the other fails.

 This topic has probably run it's course; everyone has different
 opinions and takes away different lessons from their experience.  I
 think it's valuable to challenge the common assumptions (everyone
knows
 you need a stateful firewall!) now and then to make sure they actually
 make sense.

I agree. I just don't want anyone to go throw out their statefull
firewalls because you, I or somebody else maybe would do it differently.
Or because we have a different type of network or size of network or
even goals of our network.

So here's the brunt of it... Understand what statefull firewalls are and
what they do, every network is different and YMMV.

Now, let's go get a beer. :)

 - Brian

 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for 
the sole use of the
intended recipient(s) and may contain confidential and privileged information. 
Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the 
intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original 
message. Thank you.

RE: I don't need no stinking firewall!

2010-01-06 Thread Brian Johnson

 -Original Message-
 From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
 Sent: Wednesday, January 06, 2010 3:46 PM
 To: nanog@nanog.org
 Subject: Re: I don't need no stinking firewall!

 On Tue, 05 Jan 2010 23:14:05 CST, Ryan Brooks said:

  Everyone needs to listen to Roland's mantra: stateless ACLs in
 hardware
  than can handle Mpps.  It's more than just a hint.

 I suspect that more than a few need to be reminded that stateless
ACLs
 in
 switch hardware is just another name for switch that also does
 stateless
 firewall.

I don't think so: stateless ACLs in switch hardware !=  switch that
also does stateless firewall

IMHO... stateless ACLs in [switch|router] hardware = ACLs applied to
interfaces that filter packets based on source or destination IP
addresses and ports, or protocols. Correct me if I'm wrong Roland.

 - Brian

 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for 
the sole use of the
intended recipient(s) and may contain confidential and privileged information. 
Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the 
intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original 
message. Thank you.

RE: I don't need no stinking firewall!

2010-01-06 Thread gb10hkzo-nanog

Don't think anyone has mentioned this yet, so I will

All this debate over the pros and cons of firewalls brings the words Jericho 
Forum to mind.and their  principles for de-perimeterization (perimeter 
erosion)

http://www.opengroup.org/jericho/

Just my 2insert_currency worth !

I don't need no stinking firewall!

2010-01-05 Thread Brian Johnson

Security Gurus, et al,

I have my own idea of what a firewall is and what it does. I also
understand what statefull packet inspection is and what it does. Given
this information, and not prejudging any responses, exactly what is a
firewall for and when is statefull inspection useful?

Please respond on-list as I want to have some useful discourse and
discussion in the clear. Flamers and Trolls will be disregarded. :)

Thank you.

 - Brian


 CONFIDENTIALITY NOTICE: This email message, including any attachments, is for 
the sole use of the
intended recipient(s) and may contain confidential and privileged information. 
Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are not the 
intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original 
message. Thank you.

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 3:16 AM, Brian Johnson wrote:

  Given this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?

In the most basic terms, a stateful firewall performs bidirectional 
classification of communications between nodes, and makes a pass/fail 
determination on each packet based on a) whether or not a bidirectional 
communications session is already open between the nodes and b) any policy 
rules configured on the firewall as to what ports/protocols should be allowed 
between said nodes.

Stateful firewalls make good sense in front of machines which are primarily 
clients; the stateful inspection part keeps unsolicited packets away from the 
clients.

Stateful firewalls make absolutely no sense in front of servers, given that by 
definition, every packet coming into the server is unsolicited (some protocols 
like ftp work a bit differently in that there're multiple 
bidirectional/omnidirectional communications sessions, but the key is that the 
initial connection is always unsolicited).

Putting firewalls in front of servers is a Really Bad Idea - besides the fact 
that the stateful inspection premise doesn't apply (see above), rendering the 
stateful firewall superfluous, even the biggest, baddest firewalls out there 
can be easily taken down via state-table exhaustion; an attacker can craft 
enough programmatically-generated, well-formed traffic which conforms to the 
firewall policies to 'crowd out' legitimate traffic, thus DoSing the server.  
Addtionally, the firewall can be made to collapse far quicker than the server 
itself would collapse, as the overhead on the state-tracking is less than what 
the server itself could handle on its own.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-05 Thread Tony Finch

On Tue, 5 Jan 2010, Brian Johnson wrote:

 Given this information, and not prejudging any responses, exactly what
 is a firewall for and when is statefull inspection useful?

Stateful inspection is useful for breaking things in subtle and
hard-to-debug ways.
http://fanf.livejournal.com/102206.html
http://fanf.livejournal.com/95831.html

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: I don't need no stinking firewall!

2010-01-05 Thread Brielle Bruns


On 1/5/10 1:29 PM, Dobbins, Roland wrote:

Putting firewalls in front of servers is a Really Bad Idea - besides
the fact that the stateful inspection premise doesn't apply (see
above), rendering the stateful firewall superfluous, even the
biggest, baddest firewalls out there can be easily taken down via
state-table exhaustion; an attacker can craft enough
programmatically-generated, well-formed traffic which conforms to the
firewall policies to 'crowd out' legitimate traffic, thus DoSing the
server.  Addtionally, the firewall can be made to collapse far
quicker than the server itself would collapse, as the overhead on the
state-tracking is less than what the server itself could handle on
its own.


The trick is to not track ports/IPs that do not need it.  On my combo 
firewalls (that handle both NATing and serving websites, dns, etc) for 
example, I'll do a NOTRACK on the LAN side to prevent connections to the 
firewall itself from taking up valuable table space.


It's all how you configure and tweak the firewall.  Recommending people 
run servers without a firewall is bad advice - do you really want your 
Win2k3 server exposed, SMB, RPC, and all to the world?


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: I don't need no stinking firewall!

2010-01-05 Thread Peter Hicks


Tony Finch wrote:


Stateful inspection is useful for breaking things in subtle and
hard-to-debug ways.



http://fanf.livejournal.com/102206.html
http://fanf.livejournal.com/95831.html


Is that really stateful inspection?  Isn't the SMTP fixup on a PIX an 
application-level gateway?


I *though* most of the world turns SMTP fixup off because it's naff.


Peter

Re: I don't need no stinking firewall!

2010-01-05 Thread Jay Hennigan


Simon Lockhart wrote:


Generally, I just use stateless ACLs when I need additional network level
security. However, they do have one big disadvantage. Say you've got a server
where you want to allow outbound HTTP access to anywhere on the Internet, but
only SSH inbound from your home DSL. To do this, you'd build an inbound ACL
which looks something like:

  - Allow from home DSL IP to server port 22
  - Allow from anywhere port 80 to server


Change the above to:
- Allow from anywhere port 80 to server port  1023

Or better:
- Allow from anywhere port 80 to server port  1023 established


  - Deny all other traffic.

You need the port 80 rule to allow the return traffic from all those outbound
connections.


Those outbound connections will originate from a random high port, so 
just allow those as destination ports on your inbound rule.



However, an enterprising hacker realises that he can create a TCP connection
from port 80 on his own box to port 22 on your server.


Not with the above rules.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: I don't need no stinking firewall!

2010-01-05 Thread Brielle Bruns


On 1/5/10 2:01 PM, Peter Hicks wrote:

Tony Finch wrote:


Stateful inspection is useful for breaking things in subtle and
hard-to-debug ways.

 

http://fanf.livejournal.com/102206.html
http://fanf.livejournal.com/95831.html


Is that really stateful inspection? Isn't the SMTP fixup on a PIX an
application-level gateway?

I *though* most of the world turns SMTP fixup off because it's naff.





It is a ALG, and a completely braindead one at that.  Nothing like 
trying to figure out what an error message means when its just...


XXX   **

The PIX's fixup for DNS packets have been causing issues on my end too 
in one setup.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: I don't need no stinking firewall!

2010-01-05 Thread Simon Lockhart

On Tue Jan 05, 2010 at 01:58:52PM -0700, Brielle Bruns wrote:
 It's all how you configure and tweak the firewall.  Recommending people 
 run servers without a firewall is bad advice - do you really want your 
 Win2k3 server exposed, SMB, RPC, and all to the world?

I have an answer to that problem, but not everyone would agree with it [1].

Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director|* Domain  Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: i...@bogons.net  * 

[1] That said, when I've had no choice but to use a Win2k3 web server, I've
proxy-passed it behind an Apache server.

Re: I don't need no stinking firewall!

2010-01-05 Thread Mark Foster


Stateful firewalls make absolutely no sense in front of servers, given that by 
definition, every packet coming into the server is unsolicited (some protocols 
like ftp work a bit differently in that there're multiple 
bidirectional/omnidirectional communications sessions, but the key is that the 
initial connection is always unsolicited).



I'm interested by this assertion; surely Stateful Inspection is meant to 
facilitate the blocking of out-of-sequence packets, ones which aren't part 
of valid + recognised existing sessions - whilst of course allowing valid 
SYN session-starters, etc?


So thus, there may still be some value in catching 'injected' packets 
which don't actually belong in a session... ?




Putting firewalls in front of servers is a Really Bad Idea - besides the fact 
that the stateful inspection premise doesn't apply (see above), rendering the 
stateful firewall superfluous, even the biggest, baddest firewalls out there 
can be easily taken down via state-table exhaustion; an attacker can craft 
enough programmatically-generated, well-formed traffic which conforms to the 
firewall policies to 'crowd out' legitimate traffic, thus DoSing the server.  
Addtionally, the firewall can be made to collapse far quicker than the server 
itself would collapse, as the overhead on the state-tracking is less than what 
the server itself could handle on its own.



Some might argue that DoS is preferred to the other degrees of risk that 
many webservers hold... (trying not to point the finger in any one 
specific direction.)




Mark.

Re: I don't need no stinking firewall!

2010-01-05 Thread Tony Finch

On Tue, 5 Jan 2010, Peter Hicks wrote:

 Is that really stateful inspection?  Isn't the SMTP fixup on a PIX an
 application-level gateway?

Well, the bug I described is caused by it not being stateful enough.

 I *though* most of the world turns SMTP fixup off because it's naff.

Exactly my point :-)

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

Re: I don't need no stinking firewall!

2010-01-05 Thread Brielle Bruns


On 1/5/10 2:06 PM, Simon Lockhart wrote:



I have an answer to that problem, but not everyone would agree with it [1].



One of my biggest beefs with some people is that they'll stand there 
with their fingers in their ears yelling LA LA LA if you point out to 
them that not every person in the world can use Linux/UNIX/etc.  Some 
businesses _must_ use Windows to support the applications they use.



 [1] That said, when I've had no choice but to use a Win2k3 web
 server, I've proxy-passed it behind an Apache server.

Except that it requires yet another machine to be sold to a customer who 
already laid out however many thousands of dollars for a server + 
licenses + CALs + applications.


If we already have the firewall, its _very_ hard for me to justify to 
the customer another chunk of cash for a second firewall just for the 
server.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: I don't need no stinking firewall!

2010-01-05 Thread Jared Mauch


On Jan 5, 2010, at 3:58 PM, Brielle Bruns wrote:

 It's all how you configure and tweak the firewall.  Recommending people run 
 servers without a firewall is bad advice - do you really want your Win2k3 
 server exposed, SMB, RPC, and all to the world?

Some people think that exposing any functionality by default such as that is a 
poor security practice :)

My biggest issue is that people think that Firewalls, AV, etc  are a catch-all 
for any network/user/security badness.  The real world is more complex than 
that.

Most people make poor security choices and this creates much larger issues.

I thought the firewall would protect me.
I thought my IPS would protect me
I thought my AV would protect me

Most of these technologies create a truly false sense of security.

I'm once again reminded of many people who do technically silly things like 
block TCP/53, packets over 512 bytes, port 587, ssl imap ports, etc.

It's frustrating and sad because it's not an effective security strategy and 
frustrates grumpy old-school users as myself that used odi drivers w/ ka9q to 
multitask over our CSLIP networks.

- Jared

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 3:58 AM, Brielle Bruns wrote:

 It's all how you configure and tweak the firewall.  Recommending people 
 run servers without a firewall is bad advice - do you really want your 
 Win2k3 server exposed, SMB, RPC, and all to the world?

Nope - I use stateless ACLs in hardware, capable of handling mpps.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 4:07 AM, Mark Foster wrote:

 I'm interested by this assertion; surely Stateful Inspection is meant to 
 facilitate the blocking of out-of-sequence packets, ones which aren't part 
 of valid + recognised existing sessions - whilst of course allowing valid 
 SYN session-starters, etc?
 
 So thus, there may still be some value in catching 'injected' packets 
 which don't actually belong in a session... ?

Nope - the hosts handle this better on their own.

 
 Some might argue that DoS is preferred to the other degrees of risk that 
 many webservers hold... (trying not to point the finger in any one 
 specific direction.)

Except that the firewalls don't mitigate any of the other degrees of risk, 
either.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: I don't need no stinking firewall!

2010-01-05 Thread William Herrin

On Tue, Jan 5, 2010 at 3:16 PM, Brian Johnson bjohn...@drtel.com wrote:
 I have my own idea of what a firewall is and what it does. I also
 understand what statefull packet inspection is and what it does. Given
 this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?

A firewall is anything that examines IP packets in-line for the
purpose of discarding undesirable packets before they can be
interpreted by the transport layer protocol (e.g. TCP) on the endpoint
computer.

A firewall is usually a computer filling in the same slot as a router
in a network topology capable of discarding packets before they can
reach the endpoint computer at all. In some cases though, a firewall
may be a separate piece of software on the same computer sending or
receiving the packet.

The purpose of the firewall is to permit the protected equipment to
operate with a less thorough (hence less expensive) attention to the
network security process. Can't really afford to have a dedicated
network security guru for every dozen desktops playing big brother
with what software the users are using so you focus your attention on
the border instead.


Stateful inspection is useful when you want the firewall to discard
any packets which are not part of a communications session that the
firewall understands and has approved. By contrast, packet filtering
will only discard those packets explicitly deemed bad.

At a practical level, the above distinction can be a noop. Internal
machines are usually incapable of acting on packets the packet filter
will unintentionally pass, such as IP fragments without the first
fragment.

Stateful address-overloaded NAT offers additional protection over
stateful inspection alone in that the firewall naturally fails
closed. That is, a malfunctioning firewall will drop acceptable
packets rather than allow bad ones. This is defense in depth. An
error in the filtering process still leaves the firewall with no idea
which internal machine to transmit the errantly cleared packet to;
that information was only available as part of the session state. By
contrast, stateful, packet filtering and non-overloaded NAT firewalls
are always able to send the packet to an internal machine once it
passes the filtering rules.

This last is part of what makes the little DSL routers such useful
weapons in the network security professional's arsenal.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: I don't need no stinking firewall!

2010-01-05 Thread Henry Yen

On Tue, Jan 05, 2010 at 13:18:47PM -0800, Jay Hennigan wrote:
 Jason Shearer wrote:
  Doesn't using the established allow any packet with ACK/RST set 
 
 Yes, as would be expected for legitimate return traffic for a TCP 
 connection initiated from a browser inside the firewall.
 
  and wouldn't you have to allow all high ports?
 
 That's what the  is for.  Cisco syntax gt (greater than).

One could also use reflexive access lists, which are much better
than static lists, although that takes you back to stateful.

It is possible to combine them both to achieve a mostly stateless
setup while still having better overall security.

 The point is that either of these will deny unsolicited new connection 
 attempts from the outside to TCP 22 (and 445, 135, etc.)

-- 
Henry Yen   Aegis Information Systems, Inc.
Senior Systems Programmer   Hicksville, New York
(800) 234-4700

Re: I don't need no stinking firewall!

2010-01-05 Thread Fred Baker


The primary value of a firewall is two-fold:

 - It enables a network administrator to define his edge, the  
interior of which he is responsible for.
 - It enables a network administrator to isolate his network from  
externally-originated traffic per his whims and viewpoints.


IMHO, it is not a security solution per se; it is comparable perhaps  
to human skin - keeping certain stuff out to limit the need to use  
other tools that one uses internally. That said, the tools one uses to  
create true security are a combination of network-based detection/ 
analysis equipment like honeypots, router configurations, and sensors,  
and host-based security technologies. In the final analysis, the  
hosted application is responsible for its own security (if some  
attacker threads the needle, it had better be able to handle the  
attack), and uses host and network facilities as defense-in-depth (the  
less it has to worry about that the more effective overall security is).


On Jan 5, 2010, at 12:16 PM, Brian Johnson wrote:


Security Gurus, et al,

I have my own idea of what a firewall is and what it does. I also
understand what statefull packet inspection is and what it does. Given
this information, and not prejudging any responses, exactly what is a
firewall for and when is statefull inspection useful?

Please respond on-list as I want to have some useful discourse and
discussion in the clear. Flamers and Trolls will be disregarded. :)

Thank you.

- Brian


CONFIDENTIALITY NOTICE: This email message, including any  
attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged  
information. Any unauthorized review,
copying, use, disclosure, or distribution is prohibited. If you are  
not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the  
original message. Thank you.




http://www.ipinc.net/IPv4.GIF

Re: I don't need no stinking firewall!

2010-01-05 Thread Sean Donelan


On Tue, 5 Jan 2010, Fred Baker wrote:

The primary value of a firewall is two-fold:

- It enables a network administrator to define his edge, the interior of 
which he is responsible for.
- It enables a network administrator to isolate his network from 
externally-originated traffic per his whims and viewpoints.


Actually, a firewall is so the security administrator can intervene 
between the network administrator and the system administrator to impose 
controls on both because they didn't prevent something themselves.  It 
sounds like of beginning of a joke, a network administrator, system 
administrator and security administrator walk into a 
bar ...


A statefull firewall is most useful for *outbound* traffic, inbound 
traffic controls usually break things that depend on maintaining state. 
Of course, if you want outbound traffic from your web server, its no 
longer just a web server.  Its some mongrel type of client/server. 
Likewise a IDS/IPS/AV/Anti-X box is no longer just a stateful firewall, 
its some kind of mongrel security device.


Simple ACLs can keep stuff out, or keep stuff in.  Stateful things are 
only needed when you want to keep track of things you sent outbound, so 
you can let (hopefull) the same thing back inbound.


IMHO, it is not a security solution per se; it is comparable perhaps to human 
skin - keeping certain stuff out to limit the need to use other tools that 
one uses internally. That said, the tools one uses to create true security 
are a combination of network-based detection/analysis equipment like 
honeypots, router configurations, and sensors, and host-based security 
technologies. In the final analysis, the hosted application is responsible 
for its own security (if some attacker threads the needle, it had better be 
able to handle the attack), and uses host and network facilities as 
defense-in-depth (the less it has to worry about that the more effective 
overall security is).


Your simple, verifiable, etc security devices then become something 
even more complex than the systems they are supposedly are protecting. 
With that additional complexity comes additional risks that the security
device itself has flaws.  Adding NAT/PAT/state/DNS proxy creates its own 
problems and many protocol hacks, often requiring even more complexity to

fix what you broke.

I blame Bellovin  Cheswick for firewalls :-)  There are some subtle 
points in their early papers I'm still learning.


Yes, statefull firewalls can be usefull.  But too often security 
professionals suffer from the I have a hammer syndrome.  They break 
everything with a single tool, even stuff that may be better without it. 
Security should worry about all the letters in C-I-A.

Re: I don't need no stinking firewall!

2010-01-05 Thread Kenny Sallee

On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson bjohn...@drtel.com wrote:

 Security Gurus, et al,

 I have my own idea of what a firewall is and what it does. I also
 understand what statefull packet inspection is and what it does. Given
 this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?

 Please respond on-list as I want to have some useful discourse and
 discussion in the clear. Flamers and Trolls will be disregarded. :)

 Thank you.

  - Brian



To me - a firewall is just another layer of security to help protect
company/personal assets.  Firewalls, AV, IPS, OS patches, physical security,
educated users etc. etc...all play a part in protecting what you own and
what you data you have from 'bad guys'.  Where to place firewalls depends on
what you are protecting.  If regular humans (ie consumers) stateful packet
firewalls are smart (although NAT does provide a level of security - and I
know there will be arguments against that).  If business assets - it depends
on scale and traffic.  If you have a small to medium business with a T1 - a
smart network engineer can us ACL's to protect your assets but stateful
firewalls are fairly cheap so why not use them?  If you are running gigabits
worth of traffic then a stateful firewall is a bad thing but layered
protection is still important.  DDOS defenses of some form is part of that
layered protection (scale to handle DDOS, work w/ upstream providers etc..)
.  So I guess my answer is - it just depends on the business, traffic
patterns, $$, and skill sets of the engineers or consultants you hire.  But
I do agree - firewalling or protection of assets is a necessity no matter
what your size or scale from a practical and most likely regulatory
perspective.

So now I get to rant - becuase I think that 'security guru's' are
one-tracked minded.  Often times - in larger organizations the executives
are the largest FUD mongers.  This lead to hiring a 'Security Guru'.  The
'Security Guru' convinces said executives that the sky is falling.
 Executives fear for their jobs and company assets and the next thing you
know - all innovation and flexibility is removed from the employee's in the
name of security.  It's a really bad thing.  Are most users bungholes that
require strict security policies - yes.  Are they all? No.  It's your job to
make sure the company is protected enough to continue innovation and making
money.  You have a tough job I'll give you that - and I wouldn't want it -
but you chose your path in life not me!  So make it work without stifling
the users you are trying to protect! /end_rant

Kenny

Re: I don't need no stinking firewall!

2010-01-05 Thread Mark Smith

On Tue, 5 Jan 2010 14:16:58 -0600
Brian Johnson bjohn...@drtel.com wrote:

 Security Gurus, et al,
 
 I have my own idea of what a firewall is and what it does. I also
 understand what statefull packet inspection is and what it does. Given
 this information, and not prejudging any responses, exactly what is a
 firewall for and when is statefull inspection useful?
 

First thing to work out is your threat model. Once you've worked out
what you're trying to protect, who you're trying to protect it from,
and what techniques they're likely use to break that protection, you
can then work out if a firewall is the right tool, then work out how
many to have and where (network perimeter only, network perimeter +
hosts, network perimeter + hosts + in application protection (e.g.
authentication like in ssh - remember, it's people that are your real
threat, not machines and their IP addresses - those are just the tools
people use).

The trap is to think technology like firewalls are only thing you
need to worry about. Unfortunately they won't stop the building
cleaners from lifting things out of the bins under desks.


 Please respond on-list as I want to have some useful discourse and
 discussion in the clear. Flamers and Trolls will be disregarded. :)
 
 Thank you.
 
  - Brian
 
 
  CONFIDENTIALITY NOTICE: This email message, including any attachments, is 
 for the sole use of the
 intended recipient(s) and may contain confidential and privileged 
 information. Any unauthorized review,
 copying, use, disclosure, or distribution is prohibited. If you are not the 
 intended recipient, please
 contact the sender by reply e-mail and destroy all copies of the original 
 message. Thank you.

Re: I don't need no stinking firewall!

2010-01-05 Thread Mark Smith

On Tue, 5 Jan 2010 20:51:47 +
Tony Finch d...@dotat.at wrote:

 On Tue, 5 Jan 2010, Brian Johnson wrote:
 
  Given this information, and not prejudging any responses, exactly what
  is a firewall for and when is statefull inspection useful?
 
 Stateful inspection is useful for breaking things in subtle and
 hard-to-debug ways.
 http://fanf.livejournal.com/102206.html
 http://fanf.livejournal.com/95831.html
 

Your second article (with the pointer to end-to-end arguments in
systems design) reminded me of this thread that came up on the Linux
networking development mailing list recently. TCP was flaking out, but
if the same traffic was tunnelled over the same connection, all was
good.

Strange TCP behavior over HSDPA
http://www.spinics.net/lists/netdev/msg116809.html




 Tony.
 -- 
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
 MODERATE OR GOOD.

Re: I don't need no stinking firewall!

2010-01-05 Thread Kevin Oberman

 From: Jared Mauch ja...@puck.nether.net
 Date: Tue, 5 Jan 2010 16:20:56 -0500

 On Jan 5, 2010, at 3:58 PM, Brielle Bruns wrote:

  It's all how you configure and tweak the firewall.  Recommending people run 
  servers without a firewall is bad advice - do you really want your Win2k3 
  server exposed, SMB, RPC, and all to the world?

 Some people think that exposing any functionality by default such as that is 
 a poor security practice :)

 My biggest issue is that people think that Firewalls, AV, etc  are a 
 catch-all for any network/user/security badness.  The real world is more 
 complex than that.

 Most people make poor security choices and this creates much larger issues.

 I thought the firewall would protect me.
 I thought my IPS would protect me
 I thought my AV would protect me

 Most of these technologies create a truly false sense of security.

 I'm once again reminded of many people who do technically silly
 things like block TCP/53, packets over 512 bytes, port 587, ssl imap
 ports, etc.

 It's frustrating and sad because it's not an effective security
 strategy and frustrates grumpy old-school users as myself that used
 odi drivers w/ ka9q to multitask over our CSLIP networks.

I suspect at least part of this will soon get fixed due to DNSSEC.
Blocking tcp/53 and packets over 512 bytes will cause user complaints
and, after enough education, the problem will get fixed.

I had a problem with a large US government site due to tcp/53 blocking
and had no luck getting it fixed. The Security Officer informed me
that tcp/53 was only ever needed for zone transfer and any other use was
clear evidence of abuse. RFCs meant nothing to him. (I don't know if he
knew what an RFC was.)

Now that gov domains are mandated to be signed, seems like he learned that
tcp/53 could be used for normal operations.

You can get more with a kind word and a two-by-four than you can with
just a kind word. 
 J. Michael Straczynski from
 Ceremonies of Light and Dark
 Babylon 5
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Re: I don't need no stinking firewall!

2010-01-05 Thread Rich Kulawiec


A firewall is another layer in a defense-in-depth strategy, but tends
to only be truly effective if the first rule in it is

deny all from any to any

which of course does not happen much of the time in the real world,
with predictable results.

Moreover, stateful packet inspection is not the end-all be-all: there's
a lot to be said for application-level proxying, and for quasi-realtime
traffic analysis.

I think of my firewalls as tools which reduce the overwhelming flood
of malicious and garbage traffic to a trickle -- which does not necessarily
reduce the attack surface or the threats to it, but may at least allow
me a better chance of seeing the threats and doing something useful
about them.

---Rsk

Re: I don't need no stinking firewall!

2010-01-05 Thread Robert Brockway


On Tue, 5 Jan 2010, Dobbins, Roland wrote:

In the most basic terms, a stateful firewall performs bidirectional 
classification of communications between nodes, and makes a pass/fail 
determination on each packet based on a) whether or not a bidirectional 
communications session is already open between the nodes and b) any 
policy rules configured on the firewall as to what ports/protocols 
should be allowed between said nodes.


Stateful firewalls make good sense in front of machines which are 
primarily clients; the stateful inspection part keeps unsolicited 
packets away from the clients.


Stateful firewalls make absolutely no sense in front of servers, given 
that by definition, every packet coming into the server is unsolicited 
(some protocols like ftp work a bit differently in that there're 
multiple bidirectional/omnidirectional communications sessions, but the 
key is that the initial connection is always unsolicited).


Putting firewalls in front of servers is a Really Bad Idea - besides the


Hi Roland.  I disagree strongly with this position.


fact that the stateful inspection premise doesn't apply (see above),


The problem is that your premise is wrong.  Stateful firewalls (hereafter 
just called firewalls) offer several advantages.  This list is not 
necessarily exhaustive.


(1) Security in depth.  In an ideal world every packet arriving at a 
server would be for a port that is intended to be open and listening. 
Unfortunately ports can be opened unintentionally on servers in several 
ways: sysadmin error, package management systems pulling in an extra 
package which starts a service, etc.  By having a firewall in front of the 
server we gain security in depth against errors like this.


(2) Centralised management of access controls.  Many services should only 
be open to a certain set of source addresses.  While this could be managed 
on each server we may find that some applications don't support this well, 
and management of access controls is then spread across any number of 
management interfaces. Using a firewall for network access control reduces 
the management overhead and chances of error.  Even if network access 
control is managed on the server, doing it on the firewall offers 
additional security in depth.


(3) Outbound access controls.  In many cases we want to stop certain types 
of outbound traffic.  This may contain an intrusion and prevent attacks 
against other hosts owned by the organisation or other organisations. 
Trying to do outbound access control on the server won't help as if the 
server is compromised the attacker can likely get around it.


(4) Rate limiting.  The ability to rate limit incoming and outgoing data 
can prevent certain sorts of DoSes.


(5) Signature based blocking.   Modern firewalls can be tied to intrusion 
prevention systems which will 'raise the shields' in the face of 
certain attacks.  Many exploits require repeated probing and this provides 
a way to stop the attack before it is successful.


rendering the stateful firewall superfluous, even the biggest, baddest 
firewalls out there can be easily taken down via state-table exhaustion;


Do you have any evidence to support this assertion?  You've just asserted 
that all firewalls have a specific vulnerability.  It isn't even possible 
to know the complete set of architectures (hardware  software) used for 
firewalls so I don't see how you can assert they all have this 
vulnerability.


In any case, my experience tells me that a DDoS will be successful due to 
exhaustion of available network capacity before it exhausts the state 
table on the firewall.


an attacker can craft enough programmatically-generated, well-formed 
traffic which conforms to the firewall policies to 'crowd out' 
legitimate traffic, thus DoSing the server.  Addtionally, the firewall 
can be made to collapse far quicker than the server itself would 
collapse, as the overhead on the state-tracking is less than what the 
server itself could handle on its own.


Again, I don't believe such a global claim can be made given the wide 
variety of architectures used for firewalls.


Cheers,

Rob

--
I tried to change the world but they had a no-return policy
http://www.practicalsysadmin.com

Re: I don't need no stinking firewall!

2010-01-05 Thread Jorge Amodio

- A firewall is a partition structure that normally consists of two
side walls with a fire retardant material between them.
- A firewall does not prevent a fire.
- A firewall does not extinguish a fire.
- A firewall only delays the propagation of a fire event to the other side.
- The characteristics and properties of each side are independent and
not necessary equal.
- A firewall eventually gets on fire.
- Fire retardant performance is dependent on type of fire and subject
to change without notice.
- A firewall does not prevent against monkeys with matchboxes.
- In the event of a fire locate the nearest exit.
- Use the exit and wait in a safe place for the arrival of trained
personnel to extinguish the fire.
- Clean up the mess and get rid of the monkey.
- Apply to computer networks as necessary.

Cheers
Jorge

Re: I don't need no stinking firewall!


On Jan 6, 2010, at 4:24 AM, Robert Brockway wrote:

 Hi Roland.  I disagree strongly with this position.

You can disagree all you want, but it's still borne out by real-world 
operational experience.

;

 The problem is that your premise is wrong.

Just what about my premise is wrong?  Nothing in your message repudiates - or 
even addresses - a single thing I've said.

;

  Stateful firewalls (hereafter just called firewalls) offer several 
 advantages.

Not in front of servers, they don't.

Clients, yes.  Servers, no.

  This list is not necessarily exhaustive.

No, it doesn't include all - or even any - of the reasons firewalls are 
inappropriate for placement in front of servers, not by a long shot.

;

 (1) Security in depth.  In an ideal world every packet arriving at a 
 server would be for a port that is intended to be open and listening. 
 Unfortunately ports can be opened unintentionally on servers in several 
 ways: sysadmin error, package management systems pulling in an extra 
 package which starts a service, etc.  By having a firewall in front of the 
 server we gain security in depth against errors like this.

Stateless ACLs in router/switch hardware capable of handling mpps takes care of 
this.

 (2) Centralised management of access controls.  Many services should only 
 be open to a certain set of source addresses.  While this could be managed 
 on each server we may find that some applications don't support this well, 
 and management of access controls is then spread across any number of 
 management interfaces. Using a firewall for network access control reduces 
 the management overhead and chances of error.  Even if network access 
 control is managed on the server, doing it on the firewall offers 
 additional security in depth.

Stateless ACLs in router/switch hardware capable of handling mpps takes care of 
this.

 
 (3) Outbound access controls.  In many cases we want to stop certain types 
 of outbound traffic.  This may contain an intrusion and prevent attacks 
 against other hosts owned by the organisation or other organisations. 
 Trying to do outbound access control on the server won't help as if the 
 server is compromised the attacker can likely get around it.

Stateless ACLs in router/switch hardware capable of handling mpps takes care of 
this.

 (4) Rate limiting.  The ability to rate limit incoming and outgoing data 
 can prevent certain sorts of DoSes.

Rate-limiting during a DDoS - i.e., an attack against state and *capacity* - is 
absolutely the *worst* thing one can possibly do, in almost all circumstances. 

Yet another security myth which is easily disproved via hands-on operational 
experience.
 
 (5) Signature based blocking.

Signatures are obsolete before they're ever created; 15 years of firewalls and 
so-called IDS/'IPS', and the resultant hundreds of millions of botted hosts, 
pretty much put paid to this canard.

   Modern firewalls can be tied to intrusion 
 prevention systems which will 'raise the shields' in the face of 
 certain attacks.

These systems are worse than useless, they're actively harmful; they form DDoS 
chokepoints themselves, drastically increase the attack surface, and can also 
be gamed. 

  Many exploits require repeated probing and this provides a way to stop the 
 attack before it is successful.

In the same way that powering off the server ensures perfect confidentiality 
and integrity of its data, applications, and services.

;

 Do you have any evidence to support this assertion?

Yes - many years of watching the biggest, baddest firewalls choke and die under 
trivial DDoS.  Including the better part of a  decade working for the largest 
firewall vendor in the world.

  You've just asserted that all firewalls have a specific vulnerability.

No, I've asserted that all stateful firewalls created in the history of the 
world to date, commercial or open-source, are based upon a specific 
*fundamental architectural premise* which precludes their placement in front of 
servers.  

This isn't the same as saying they've a *vulnerability*.  I'm saying they're 
unsuited to be placed in front of servers.

 I don't see how you can assert they all have this 
 vulnerability.

Again, I'm not asserting they've a vulnerability.  I'm asserting that it 
doesn't make much sense to pound nails with a monkey-wrench.

;

 In any case, my experience tells me that a DDoS will be successful due to 
 exhaustion of available network capacity before it exhausts the state 
 table on the firewall.

My experiences defending against DDoS attacks from the 1990s to the present 
nanosecond indicate otherwise.

;

 Again, I don't believe such a global claim can be made given the wide variety 
 of architectures used for firewalls.

Again, *all* stateful firewalls produced to date share a fundamental 
architectural premise which renders them unsuitable for placement in front of 
servers.

In fact, one major firewall vendor recently implemented a 'stateful inspection

Re: I don't need no stinking firewall!

2010-01-05 Thread William Pitcock

On Tue, 2010-01-05 at 16:24 -0500, Robert Brockway wrote:
 On Tue, 5 Jan 2010, Dobbins, Roland wrote:
 
  In the most basic terms, a stateful firewall performs bidirectional 
  classification of communications between nodes, and makes a pass/fail 
  determination on each packet based on a) whether or not a bidirectional 
  communications session is already open between the nodes and b) any 
  policy rules configured on the firewall as to what ports/protocols 
  should be allowed between said nodes.
 
  Stateful firewalls make good sense in front of machines which are 
  primarily clients; the stateful inspection part keeps unsolicited 
  packets away from the clients.
 
  Stateful firewalls make absolutely no sense in front of servers, given 
  that by definition, every packet coming into the server is unsolicited 
  (some protocols like ftp work a bit differently in that there're 
  multiple bidirectional/omnidirectional communications sessions, but the 
  key is that the initial connection is always unsolicited).
 
  Putting firewalls in front of servers is a Really Bad Idea - besides the
 
 Hi Roland.  I disagree strongly with this position.

As someone who worked for a startup several years ago working on solving
precisely the problem of having a reliable firewall/IDS solution infront
of the server, I'm going to have to disagree with your disagreement.

 
  fact that the stateful inspection premise doesn't apply (see above),
 
 The problem is that your premise is wrong.  Stateful firewalls (hereafter 
 just called firewalls) offer several advantages.  This list is not 
 necessarily exhaustive.
 
 (1) Security in depth.  In an ideal world every packet arriving at a 
 server would be for a port that is intended to be open and listening. 
 Unfortunately ports can be opened unintentionally on servers in several 
 ways: sysadmin error, package management systems pulling in an extra 
 package which starts a service, etc.  By having a firewall in front of the 
 server we gain security in depth against errors like this.
 

ACLs in the router hardware handle this.  Your average datacentre
switch, even a small one can handle stateless ACL checks in hardware.

Also ACLs don't protect you from the bad guys, especially if you're
incompetent.  What my team found was that it was infact -impossible- to
sanely do DPI infront of a server and also survive a DDoS attack.  DDoS
attacks are a big problem these days, in case you didn't notice.

 (2) Centralised management of access controls.  Many services should only 
 be open to a certain set of source addresses.  While this could be managed 
 on each server we may find that some applications don't support this well, 
 and management of access controls is then spread across any number of 
 management interfaces. Using a firewall for network access control reduces 
 the management overhead and chances of error.  Even if network access 
 control is managed on the server, doing it on the firewall offers 
 additional security in depth.

ACLs in the router hardware handles this.  Doing it on a firewall
provides no additional security, and may infact decrease network
performance and throughput.  Additionally, predictive firewalls can be
gamed.

 
 (3) Outbound access controls.  In many cases we want to stop certain types 
 of outbound traffic.  This may contain an intrusion and prevent attacks 
 against other hosts owned by the organisation or other organisations. 
 Trying to do outbound access control on the server won't help as if the 
 server is compromised the attacker can likely get around it.

ACLs in the router hardware as well as blackholed /32s in the route
table of the router handle this.  Doing it on a firewall provides no
additional security and *will* decrease network performance and
throughput.  Routers are built for large route tables and make use of
RADIX tries and other optimizations that hardware server-oriented
firewalls do not typically have.

 
 (4) Rate limiting.  The ability to rate limit incoming and outgoing data 
 can prevent certain sorts of DoSes.

I am not sure what makes you believe that.  The ability to rate limit
incoming data at the server level would definitely not prevent a DoS. 

The ability to rate limit outgoing data would cause a DoS of anything
other than DoS traffic that is hosted on the server.

The basic rule here is you can't filter more than your port speed, and
if your port is getting hit with 1.3gbit of DDoS and your port is only
1gbit, you're still offline.

 
 (5) Signature based blocking.   

LOL.  Signature based blocking is the biggest scam since the 1980s when
IDS technology was first invented.  It doesn't work.  It is snake oil.
The only type of 'signature' that would work would be a list of all
known botnet IPs, and you're never going to get that.

 Modern firewalls can be tied to intrusion 
 prevention systems which will 'raise the shields' in the face of 
 certain attacks.  Many exploits require repeated probing and this

Re: I don't need no stinking firewall!

2010-01-05 Thread Ryan Brooks


On 1/5/10 3:24 PM, Robert Brockway wrote:

On Tue, 5 Jan 2010, Dobbins, Roland wrote:

The problem is that your premise is wrong.  Stateful firewalls 
(hereafter just called firewalls) offer several advantages.  This list 
is not necessarily exhaustive.



Great advantages list, but where's the disadvantages list?

Here's mine:

1..n) Stateful firewalls go down.  It's the very nature of what they 
do.  If you haven't had this problem, then your application is small.


Everyone needs to listen to Roland's mantra: stateless ACLs in hardware 
than can handle Mpps.  It's more than just a hint.

Re: I don't need no stinking firewall!