[TriLUG] OT: Router vs Firewall, Was: OT: strange happenings - self booting server?

[Ryan Leathers]

All correct, but this is, as you described, a basic explanation.  A stateful firewall of any quality looks deeper.  Traffic has to pass a "sniff test" so to speak.  Things like sequence numbers and offsets are checked.  The data size has to be sane for the protocol.  More common protocols have specific processing rules working with the state table.  In the Cisco PIX (which I am most familiar with) these are called Fix-Ups.   

The idea that stateful firewalls tightly control inbound connection requests, and permit replies to outbound connection requests is not incorrect - its just not the whole story.  

-----Original Message-----
From: trilug-bounces at trilug.org on behalf of Barry Gaskins
Sent: Fri 4/14/2006 1:12 PM
To: Triangle Linux Users Group discussion list
Subject: Re: [TriLUG] OT: Router vs Firewall,Was: OT: strange happenings - self booting server?
 
   I think the value of stateful packet filtering is the ability to look at
incoming packets and allow them if they are part of an existing ongoing
communication that someone on the inside of the firewall started.  So if my
web browser requests something from a server outside the firewall then the
response will be allowed to get through.  But if some packet comes in that
is not related to a request sent out then it can be dropped.

   I think some of the newer enhancements to stateful packet filtering will
even allow some new connection requests from the outside to get through IF
it is related to existing communication initiated from inside the firewall.
For example if you open an FTP session with an ftp server that is outside
the firewall then that ftp server can open another connection going back to
transfer data and the stateful packet filter will realise that it is related
and let it through.

   I am sure that some others on this list can give a better explaination
with more details for the experts.. That is a very basic explaination to
match my limited understanding.  But it might be easier for someone who is
not an expert to  understand.

    - Barry Gaskins

On 4/14/06, Ryan Leathers <ryan.leathers at globalknowledge.com> wrote:
>
> Sorry, not much time, but the best way to understand it is to try an
> example
>
> netcat is the easiest way to get started since it is readily had with
> any distro.
>
> man nc
> google "shell shoveling"
>
> set one up and play with it some.
>
> then learn about "stateful packet filtering"
> you'll discover how a "stateful firewall" prevents your nc shovel
> again, google is your friend
>
>
>
> On Fri, 2006-04-14 at 12:23 -0400, William Sutton wrote:
> > For those of us interested in learning more but who had no clue what you
> > just said (>me<)...could you kindly translate? :)
> >
> > --
> > William Sutton
> >
> >
> > On Fri, 14 Apr 2006, Ryan Leathers wrote:
> >
> > > Brian,
> > >
> > > NAT does not give you stateful inpection.  Imagine the example of
> shell
> > > shoveling.  Through some exploit, an outbound connection is made from
> > > your network, through the NAT, to some destination.  Said exploit
> > > permits a shell to be tossed at the destination so the remote attacker
> > > now has an interactive connection right through your NAT.  (People
> > > sometimes use netcat to do this, thwarting the office security policy)
> > > Obviously, preventing the exploit in the first place is desirable, but
> > > if you are using a stateful firewall there is an excellent chance
> you'll
> > > be protected from this kind of exploit.
> > >
> > > Ryan
> > >
> > > On Fri, 2006-04-14 at 10:48 -0400, Brian Henning wrote:
> > > > Okay, since there's still a lot I have to learn, I'll ask the
> question:
> > > >
> > > > What do you gain from having a firewall behind a NAT router with no
> port
> > > > forwards?  Speaking only in terms of inbound protection, of course.
> > > > Obviously a firewall can filter traffic in both directions.  Can one
> not
> > > > depend on a forwardless NAT router to simply drop all incoming
> > > > connection attempts?  Are there packets, or methods of connecting,
> that
> > > > can somehow sneak through such a NAT setup and reach machines on the
> inside?
> > > >
> > > > In all the networks I administer, firewall + router is the standard
> > > > operating procedure, so I'm just interested in more of the reasons
> why
> > > > it's a good idea (that is, I don't need any convincing to start
> doing it).
> > > >
> > > > As always, both lengthy explanations and links to reading material
> are
> > > > appreciated equally. :-)
> > > >
> > > > Cheers,
> > > > ~B
> > > >
> > > > P.S. A linux box with iptables configured on the "reject everything
> but
> > > > _____" principle counts as "good," right? :-)
> > > >
> > > >
> > > >
> > > > Cristobal Palmer wrote:
> > > > > So the backstory is that we (Brian + Cerient) ate lunch, and I
> told
> > > > > Brian about this... *ahem* ...friend of mine who insisted to me
> that a
> > > > > router is always a firewall. When I say insisted, I mean he
> followed
> > > > > me after I'd gotten up and left the room. I mean he emailed me the
> > > > > next morning to follow up on his insistence.
> > > > >
> > > > > I... uhh... have some weird friends. Seriously though, get a good
> > > > > firewall everybody. The internets are dangerous.
> > > > >
> > > > > Vice-chair-ily yours,
> > > > > CMP
> > > > >
> > >
> > >
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>
-- 
TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ  : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/