Send firewall-wizards mailing list submissions to
firewall-wizards@honor.icsalabs.com
To subscribe or unsubscribe via the World Wide Web, visit
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@honor.icsalabs.com
You can reach the person managing the list at
firewall-wizards-admin@honor.icsalabs.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."
Today's Topics:
1. Re: Host based vs network firewall in datacenter (Daniel Linder)
2. RE: Host based vs network firewall in datacenter (Rik Schneider)
3. RE: so much for "deny all" (Tina Bird)
4. Re: Host based vs network firewall in datacenter (Chuck Swiger)
5. Re: so much for "deny all" (Rob Hughes)
6. RE: so much for "deny all" (Dave Piscitello)
7. RE: Strange Pix behavior. (Paul Melson)
8. Re: Ok, so now we have a firewall, we're safe, right? (R. DuFresne)
--__--__--
Message: 1
Date: Fri, 10 Jun 2005 15:58:25 -0500 (CDT)
Subject: Re: [fw-wiz] Host based vs network firewall in datacenter
From: "Daniel Linder" <dan@linder.org>
To: "Zurek, Patrick" <pzurek@uillinois.edu>
Cc: firewall-wizards@honor.icsalabs.com
Reply-To: dan@linder.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick Zurek said:
> These are the options as I see them:
> 1) Wide open - keep the hosts locked down tight and keep open services to
> a minimum.
> 2) Host based firewall - put ipf on the hosts
> 3) Network firewall behind the router - ???
> 1) Does not seem feasible to continue to operate this way.
I agree 100%.
> 2) As a short term measure I have applied ipfilter on several of our non
> production hosts. My manager has began to advocate putting it on all
> production systems now (about 15 hosts). At first I thought this would be
> a bad idea, as a network firewall would ease administration and having to
> administer seperate rule sets for each server would be unwieldy. However,
> after reading the opinions of certain members of the list, I'm at a loss
> as to how to proceed.
[snip]
> I'm interested in using the right tool for the
> job. Is ipf on a production Sun 15k a good idea?
I guess it all depends on your workload of the servers. If they are
handling 1000's of packets per second, then the overhead of doing packet
filtering on each client might be a bit overwhelming.
> 3) This option is good because it will allow us to apply stateless ACLs at
> the gateway and centralize the management of firewall functions.
You might want to look into a Linux/BSD system setup as an in-line
firewall. Basically, the system has two NICs setup as a bridge. The
traffic IP addresses don't get translated, but the system can filter using
IPTables rules. I think the latest Linux Journal discussed this setup.
If you can't convince your bosses this step is necessary, present these
scenarios to them:
1: Someone starts sending DoS traffic to your systems as they are no.
Each machine has to investigate each packet and drop it themselves, plus
intra-server traffic will be impacted.
2: Same situation, but you have a single firewall as a chokepoint. This
single system is stopping all those 'bad' packets before they ever have a
chance to get to your servers. This keeps your internal network available
for the valuable traffic and the trash off it.
Dan
- - - - -
Wait for that wisest of all counselors, Time.
-- Pericles
"I do not fear computer,I fear the lack of them."
-- Isaac Asimov
GPG fingerprint:9EE8 ABAE 10D3 0B55 C536 E17A 3620 4DCA A533 19BF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFCqf7wNiBNyqUzGb8RAit5AJ9jMIltbrBZ4PmuJMLynXDix+209wCeMf3M
f3VvSOXoEPtBeBnMnronXVE=
=d3RI
-----END PGP SIGNATURE-----
--__--__--
Message: 2
Subject: RE: [fw-wiz] Host based vs network firewall in datacenter
Date: Fri, 10 Jun 2005 16:08:05 -0500
From: "Rik Schneider" <riks@wni.com>
To: "Zurek, Patrick" <pzurek@uillinois.edu>,
<firewall-wizards@honor.icsalabs.com>
From: Zurek, Patrick - Tuesday, June 07, 2005 12:34 PM
To: firewall-wizards@honor.icsalabs.com
> These are the options as I see them:
> 1) Wide open - keep the hosts locked down tight and keep open services
to > a minimum.
> 2) Host based firewall - put ipf on the hosts
> 3) Network firewall behind the router - ???
You forgot to mention:
4) Do both 2 and 3 above.
3 alone is like an M&M - hard and crunchy on the outside, soft and tasty
on the inside. If you can only do one or the other #2 is where I would
start. Remember that the hosts likely have no need to
ftp/telnet/ssh/http/snmp/etc to/from each other.=20
> 1) Does not seem feasible to continue to operate this way.
I agree. =20
> 2) As a short term measure I have applied ipfilter on several of our
non
> production hosts. My manager has began to advocate putting it on all
> production systems now (about 15 hosts). At first I thought this
would be
> a bad idea, as a network firewall would ease administration and having
to > administer separate rule sets for each server would be unwieldy.
However, > after reading the opinions of certain members of the list,
I'm at a loss=20
> as to how to proceed. I don't want to purchase something like:
>
> "- Some of the products we're buying simply don't work
> - Some of the products we're buying aren't being used
> properly
> - There is no correlation between cost and effectiveness
> of security products"
>
> as MJR said last week. I'm interested in using the right tool for the
> job. Is ipf on a production Sun 15k a good idea?
IPF works well but depending on your support requirements you may need
to look at a commercial solution. If you are using Solaris 8 or 9 and
are under sun support you may want to look at Sunscreen Lite but I still
prefer ipfilter.=20
> 3) This option is good because it will allow us to apply stateless
ACLs at > the gateway and centralize the management of firewall
functions.
There are many solutions for this, some as simple as putting a BSD (or
Linux or ...) box up as a bridge and again using IPF for packet
filtering to buying one of the many appliances. Bear in mind that the
stance should be to deny everything by default and then turn on only
what is truly needed. =20
> Bearing in mind that I'm still relatively new to this, and that I'm
having > trouble bridging the gap between the way security should be
done, and=20
> actually implementing it, I'd appreciate any advice and help.
Start by playing with whatever non-production equipment you can. Don't
just look at normal operations but failure modes as well. I know of at
least one AV solution, for email, that will pass all messages if the
quarantine area gets full.
As MJR has pointed out the best firewall is no network connection.
Think about what you want to accomplish with the network connection and
then configure appropriately. =20
> Thanks for reading,
--__--__--
Message: 3
From: "Tina Bird" <tbird@precision-guesswork.com>
To: <dave@corecom.com>
Cc: <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] so much for "deny all"
Date: Fri, 10 Jun 2005 14:51:24 -0700
> On 7 Jun 2005 at 9:41, Tina Bird wrote:
>=20
> > >From the TechTarget coverage of the Gartner Security Summit this
> > >week:
> >=20
> > "Next generation firewalls that do deep-packet inspections from
> > vendors like Juniper Networks, Check Point and Fortinet employ a
> > heuristics engine and allow all network traffic and behavior, except
> > those which policy says it must block. Most enterprises, however,
> > refresh their firewall purchases on a three- to five-year cycle and
> > that makes it challenging to synch new features."
> From: Dave Piscitello [mailto:dave@corecom.com]=20
>=20
> This is very good publicity for firewall vendors not in the list who=20
> provide a default "DENY ALL" in policy configuration. I'll enjoy=20
> tormenting friends at these companies over this:-)
I guess that's one way to look at it. I'd like to think that folks at =
those
companies will be cringing, and refusing to pay for multi-martini =
lunches
(if anyone in this politically correct time still indulges in =
multi-martini
lunches). Although I wonder how many of the companies that ship with a =
"deny
all" config will now be accused of being out of touch with the real =
world,
or at least the real world as defined by Gartner.
> But the 2nd statement is very odd, don't you think? Not only is it=20
> remarkably difficult to parse, but it flies in the face of (my)=20
> experience.
>=20
> Taking the source with a grain of salt, I find it hard to believe=20
> that most enterprises change security vendors every five years.=20
Well, the company at which I did my first firewall install replaced the
whole shebang within a year of my leaving, claiming that my rock-solid
Sidewinder infrastructure was too hard to manage, and putting in PIXen
instead. But I agree that *most* places don't do that. We're generally
content with the devil we know.
> Perhaps 100% of my clients buck this trend. Upgrades, yes.=20
> Forklifting firewalls? I have yet to see this except in circumstances=20
> where the prior firewall failed pitifully in enforcing policy.
I have seen several organizations replace firewall or VPN architectures, =
and
almost never for a technical reason - almost always for political or
financial ones.
--__--__--
Message: 4
Date: Fri, 10 Jun 2005 21:14:18 -0400
From: Chuck Swiger <chuck@codefab.com>
Organization: CodeFab
To: "Zurek, Patrick" <pzurek@uillinois.edu>
Cc: firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Host based vs network firewall in datacenter
Zurek, Patrick wrote:
> I graduated from university not long ago and assumed my first job as network
> administrator in a small datacenter. I've been lurking here for a while and
> reading the archives. I've learned a lot from what many of you have had to say,
> but I'm having difficulty making the jump from the theory behind the way things
> should be run (ie. the network design maps that show the little switch, router
> & firewall symbols) and the practical applications of that.
Well, congratulations on your new position. The best way to move from theory
to practice is to sent up a small test network or two, and see what "doing it
for real (almost)" is like.
There are two books that you need to get, read, and then re-read until you've
gotten their contents down: "TCP/IP Network Administration", and "Building
Internet Firewalls".
> I was also reluctant to make this post in fear of getting flamed for having
> what will come across as a cluess attitude about network security. Instead
> of flaming, please correct me, I want to learn.
While it's true that this list has some fine arguments, most of them are
friendly. :-)
> I'd like to solicit some advice on a firewall implementation. Our solaris
> only site has two main components, a web presence which connects to a backend
> application running on top of Oracle, and a custom application (which
> unfortunately also runs on the same host as the database) to which our clients
> connect. So all our servers need to be internet facing including the database.
OK. I would start by confirming the requirement for being Internet-routable,
especially with regard to the database, assuming that contains the stuff you
want to protect.
If you can put your DB on a private network and have just the few machines
which genuinely need access able to talk with it, that would probably help your
security out by a useful amount...
[ ... ]
> These are the options as I see them:
> 1) Wide open - keep the hosts locked down tight and keep open services to a minimum.
> 2) Host based firewall - put ipf on the hosts
> 3) Network firewall behind the router - ???
>
> 1) Does not seem feasible to continue to operate this way.
This approach can work for a while, but it's dangerous.
For instance, you can have services reappear after you apply a patch cluster,
as a new version of the /etc/init.d scripts might be plunked down and turn
stuff back on that you'd previous disabled....
> 2) As a short term measure I have applied ipfilter on several of our non
> production hosts. My manager has began to advocate putting it on all production
> systems now (about 15 hosts).
Host-based firewalls tend to be more useful on Windows boxes, since they can
reduce viruses propogating outwards. Not as important on a Solaris box. It's
better than nothing, but your network is still highly vulnerable a lot of
things like IP spoofing via source-routing.
> 3) This option is good because it will allow us to apply stateless ACLs at
> the gateway and centralize the management of firewall functions.
Yes. You can use a firewall as a bridge, not a router, if you don't want to
adjust your subnetting and have to renetwork your production boxes.
Whether you use stateless rules or dynamic ones is more a matter of taste and
how you've locked the boxes down. The important thing is that the firewall
will provide a chokepoint where you can inspect, block, and monitor traffic, as
well as a spot to prevent people from spoofing internal IP addresses.
--
-Chuck
--__--__--
Message: 5
Subject: Re: [fw-wiz] so much for "deny all"
From: Rob Hughes <rob@robhughes.com>
To: firewall-wizards@honor.icsalabs.com
Date: Sat, 11 Jun 2005 11:15:57 -0500
On Tue, 2005-06-07 at 09:41 -0700, Tina Bird wrote:
> From the TechTarget coverage of the Gartner Security Summit this week:
>
> "Next generation firewalls that do deep-packet inspections from vendors like
> Juniper Networks, Check Point and Fortinet employ a heuristics engine and
> allow all network traffic and behavior, except those which policy says it
> must block. Most enterprises, however, refresh their firewall purchases on a
> three- to five-year cycle and that makes it challenging to synch new
> features."
This would be incorrect, at least with regards to CheckPoint boxes. The
only way to produce the behavior they describe would be to add an
explicit any any accept rule in the security policy. Of course,
considering that it's Gartner, they may very well have done exactly
that.
--
Ignorance is a condition. Stupidity is a way of life.
--__--__--
Message: 6
From: "Dave Piscitello" <dave@corecom.com>
To: "Tina Bird" <tbird@precision-guesswork.com>
Date: Sun, 12 Jun 2005 09:12:07 -0400
Subject: RE: [fw-wiz] so much for "deny all"
Reply-To: dave@corecom.com
Cc: <firewall-wizards@honor.icsalabs.com>
On 10 Jun 2005 at 14:51, Tina Bird wrote:
> > From: Dave Piscitello [mailto:dave@corecom.com]
> >
> > This is very good publicity for firewall vendors not in the list who
> > provide a default "DENY ALL" in policy configuration. I'll enjoy
> > tormenting friends at these companies over this:-)
>
> I guess that's one way to look at it. I'd like to think that folks at
> those companies will be cringing
for the record, I did mention this to one of the companies listed and
they are moritified.
> real world as defined by Gartner.
strip the adjective
> Well, the company at which I did my first firewall install replaced
> the whole shebang within a year of my leaving, claiming that my
> rock-solid Sidewinder infrastructure was too hard to manage
This could begin an new thread entirely: change introduced under the
guise of "complexity" when it really is "we downsized our expertise
and can't do what we did before".
> I have seen several organizations replace firewall or VPN
> architectures, and almost never for a technical reason - almost always
> for political or financial ones.
I've seen SSL VPNs replace IPsec RA VPNs, but the firewall remains
and continues to terminate site-to-site IPsec.
--__--__--
Message: 7
From: "Paul Melson" <psmelson@comcast.net>
To: "'George J. Jahchan, Eng.'" <Firewall-Wizards@Compucenter.org>,
"'Firewall Wizards List'" <firewall-wizards@honor.icsalabs.com>
Subject: RE: [fw-wiz] Strange Pix behavior.
Date: Mon, 13 Jun 2005 12:48:29 -0400
This is the typical behavior of most stateful firewalls expressed through
log entries. What you're actually seeing is the firewall dropping the
RST+ACK packet coming back from the remote web server at the end of the
connection.
A stateful TCP session works something like this:
1. SYN packet leaves client and is picked up by firewall.
2. Packet src/dst addresses and ports compared to directional access-list.
3. Upon matching a 'permit' access-list, a state entry is created that acts
like an implicit access-list for the corresponding return traffic. (This
works by mapping information from the accepted packet to the new "state
table entry" access-list, like so:
inbound_if <-> outbound_if
dst_addr -> src_addr
dst_port -> src_port
src_addr_after_nat -> dst_addr
src_port_after_nat -> dst_port
4. Firewall counts packets and watches for RST packet from either src or dst
to know when the connection has ended.
5. When the RST is seen, the state table entry from #3 is deleted and the
process begins again.
If the firewall successfully deletes the state table entry before the remote
server can send an RST+ACK (which is what you want, you don't want your
firewall waiting for an untrusted system's predicted response before it
revokes its access), that packet will be compared to the access-lists that
allow traffic from the outside and if no match is found, it will be dropped
and logged.
Your firewall is working just fine, or at least, it's working as it was
designed to work. If you don't want to see it, I recommend using Kiwi or
syslog-ng to remove these entries from the syslog stream before they reach
your log analyzer.
PaulM
PS - Your reseller sucks.
-----Original Message-----
Subject: [fw-wiz] Strange Pix behavior.
We are using a pair of failover Pix 515s, and are consistently seeing denied
return traffic that theoretically should have been allowed.
Three zones are defined: LAN, DMZ and WAN and the policy is default deny.
For the allowed outbound protocols like http, we are seeing (on weekdays)
anywhere between 25,000 and 45,000 denials originating from web server
addresses on the Internet port 80 to the NAT'ed IP address of LAN users.
This is the return traffic in response to requests that originated from the
LAN.
Sample log entry follows:
... Deny tcp src outside:<www-server-IP>/80 dst LAN:<NAT-IP>/31997 by
access-group "WAN"
The corresponding rule in the LAN access-group is:
access-list LAN permit tcp host X.X.X.X gt 1023 any eq www
Not all traffic is blocked, only part of it, seemingly at random, otherwise
no one would have been able to surf the web, which is not the case.
We are also seeing denials generated by the return traffic of other allowed
outbound protocols such as pop3, imap4, smtp and dns (udp); in numbers that
seem to be proportional to the overall number of requests for each protocol.
On week-ends when the traffic is very low, we are still seeing denials, in
numbers proportional to overall requests.
We have monitored CPU and memory utilization on the Pix, they are low (CPU <
10% and memory < 25%).
The Cisco reseller has not come through with a credible explanation for this
behavior or made suggestions on course of action for diagnosing the problem.
Can anyone on this list help?
--__--__--
Message: 8
Date: Mon, 13 Jun 2005 13:08:51 -0400 (EDT)
From: "R. DuFresne" <dufresne@sysinfo.com>
To: Dave Piscitello <dave@corecom.com>
Cc: "Paul D. Robertson" <paul@compuwar.net>,
"Marcus J. Ranum" <mjr@ranum.com>,
Fritz Ames <fritzames@earthlink.net>, Ben Nagy <ben@iagu.net>,
firewall-wizards@honor.icsalabs.com
Subject: Re: [fw-wiz] Ok, so now we have a firewall, we're safe, right?
Organization: sysinfo.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well stated, and I understand the issues, but <with emphasis>
the user can't be held accountable for information the vendor fails to
provide or attempts to hide. In these situations the vendor then has
graciously abrogated the end users responsibility and maintained it for
themselves. We're not talking about tagging a routing device with enough
decals and warning labels such that it resembles a miniature NASCAR racer,
we're talking about providing the documentation that describe the product
and it 's setup, care and feeding with the fine points of security related
issues clearly located within, as well as in the table of contents, and
within the index. Hard cover manuals are a thing of the past, so getting
the online and CD ready pdf's redone should be minimal expense and
process. Failing to do so moves liability our of the end users realm,
even Marcus would have to agree there.
Thanks,
Ron DuFresne
On Fri, 10 Jun 2005, Dave Piscitello wrote:
> To a great extent, hiding complexity is intentional, and IMO a
> reaction to the scathing criticisms hurled at vendors time and again
> regarding product and UI complexity.
>
> Some folks on this list recall configuring ISDN adapters and bridge-
> routers, or early V. modems. The survivors from the "your UI bites!
> You can't expect our 10,000 reasonably intelligent users much less a
> consumer to change dipswitch settings and enter command line
> jibberish! We need something *intuitive* and *plug-and-play* or we'll
> take our business elsewhere" era are IMO permanently traumatized into
> believing they can't expose complexity (or they conceded long ago,
> made killings giving the customer what he thought he wanted, and are
> sipping champagne in sunny surrounds while we debate on maillists).
>
> I feel as if we're arguing over the road *not* travelled
> (distinguished from the road *less* travelled). I'm increasingly
> skeptical that it's possible to go back to the crossroad and make
> "secure" a priority over "easy". Too few people actually care, and
> our culture/society becomes more comfortable each day with solutions
> that absorb and amortize losses rather than mitigate them. Financials
> don't invest in stronger identity theft protection while their costs
> of doing business can tolerate loss. When losses exceed "tolerable"
> they still don't look for something bullet-proof, only something that
> reduces loss to below the magic threshold of "tolerable".
>
> My experience is that consumers, SMBs, and enterprises don't put even
> this much effort into assessing and mitigating risk. I might be in
> the minority, but the fact that 4 of 5 APs are still run wide open is
> as much an embarrassment to users as vendors.
>
> Our hands have to be placed on hot (regulatory) coals to implement
> security. Even then we procrastinate and lobby to reduce the
> requirements *and* accountability - and ask vendors to automate and
> hide complexity. Automation and security aren't good bedfellows.
>
> Where security is involved, otherwise rationale adults devolve into
> whining, rebellious, scheming, negotiating adolescents. The critical
> parent (regulatory) social style isn't working. The nurturing parent
> style isn't working. If you've know a way to create adult-adult
> conversations on the topic of network security, I'm eager to hear
> them.
>
>
>
> On 7 Jun 2005 at 3:00, R. DuFresne wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> [SNIP]
>>
>>>
>>> Good thing I scrolled down to find it! It's pretty well hidden for
>>> a "strong" recommendation. Took me 15 minutes to find, and that's
>>> all I was searching for.
>>>
>>
>> I wrote a few papers on wifi products a few years ago, and mentioned
>> that anything at all to do with securing these devices tends to be
>> hidden, if covered at all, and only touched on the the briefest sense,
>> deep down in the documentation. So, nothing has changed in recent
>> times, cool to note the consistency.
>>
>> Thanks,
>>
>> Ron DuFresne
>> - --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> admin & senior security consultant: sysinfo.com
>> http://sysinfo.com
>> Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
>>
>> ...We waste time looking for the perfect lover
>> instead of creating the perfect love.
>>
>> -Tom Robbins <Still Life With Woodpecker>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.4 (GNU/Linux)
>>
>> iD8DBQFCpUYOst+vzJSwZikRAhKFAJ9x9rdyONzvg/BeBXiY2jq/SruB/wCdGgPB
>> RcUGGqc70qMVsCQNoaEC574=
>> =x1fI
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> firewall-wizards mailing list
>> firewall-wizards@honor.icsalabs.com
>> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>>
>
>
>
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
...We waste time looking for the perfect lover
instead of creating the perfect love.
-Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCrb2nst+vzJSwZikRAhF7AJwP8EtHLpnZ4SUkdKPSLdvc9KnwdgCgmoP8
6gNQ/C8rIogx1BFCf4FYgis=
=ihZD
-----END PGP SIGNATURE-----
--__--__--
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
End of firewall-wizards Digest
No comments:
Post a Comment