Opinions: To NAT or not to NAT?

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Greetings,


I'm looking for some expert opinions on the following question:

Should individual departments in a large university be behind NAT firewalls
or transparent firewalls?

Proposal (1):

The university assigns every PC (and Mac, and network printer, and whatnot)
an IP address from its allocation, and DHCP-serves the PC from its central
DHCP server, which also serves as an inventory of networked computers on
campus. Departments are encouraged to get firewalls, which must be
transparent and capable of DHCP relaying. Departmental subnets work whether
or not a firewall is present.

Proposal (2):

The university assigns the minimum number of IP addresses (often just one)
to each department, and the department uses a NAT firewall to assign
internal IP addresses to the computers behind it. (Just like we do at home
with cable modems.)


My impression is that (1) is easier to troubleshoot and manage from a
central location, but (2) is more convenient (you can just bring your laptop
and plug it in, without registering with the central DHCP server).

Is (2) also safer? In the long run, which do you think is the best
proposal?


Many thanks,

Michael A. Covington - Artificial Intelligence Ctr - University of Georgia

(N.B. The university I'm talking about is not necessarily my own. Consider
this a theoretical long-term question.)

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

"Michael A. Covington" <look@www.covingtoninnovations.com.for.address> wrote in message news:<cMmdneoaGdGXHEnd4p2dnA@speedfactory.net>...
> Greetings,
>
>
> I'm looking for some expert opinions on the following question:
>
> Should individual departments in a large university be behind NAT firewalls
> or transparent firewalls?
>
> Proposal (1):
>
> The university assigns every PC (and Mac, and network printer, and whatnot)
> an IP address from its allocation, and DHCP-serves the PC from its central
> DHCP server, which also serves as an inventory of networked computers on
> campus. Departments are encouraged to get firewalls, which must be
> transparent and capable of DHCP relaying. Departmental subnets work whether
> or not a firewall is present.
>
> Proposal (2):
>
> The university assigns the minimum number of IP addresses (often just one)
> to each department, and the department uses a NAT firewall to assign
> internal IP addresses to the computers behind it. (Just like we do at home
> with cable modems.)
>
>
> My impression is that (1) is easier to troubleshoot and manage from a
> central location, but (2) is more convenient (you can just bring your laptop
> and plug it in, without registering with the central DHCP server).
>
> Is (2) also safer? In the long run, which do you think is the best
> proposal?
>
>
> Many thanks,
>
> Michael A. Covington - Artificial Intelligence Ctr - University of Georgia
>
> (N.B. The university I'm talking about is not necessarily my own. Consider
> this a theoretical long-term question.)

Personally, I would use the 2nd option with a caveat. I would have
Core FWs which were managed by the central admin group of the
university. The responsibility of the core firewalls would be as
follows (all that I have time to list right now).

Firstly - provide screened CIDR address space to each and every
department requesting it. For this I would recommend the use of a
Class B (or poss an A depending on your scheme/usage) at the central
location, which you chopped up into per-department VLSM's. So long as
you did proper aggregation of the Class B, all departments would only
need a single route to any other location on campus(as using this
method would allow you to dictate a relatively straight forward
routing topology - ie. OSPF Backbone with /29 or 30 handoffs to each
departmental FW, and a Class C (or several) behind each)

Secondly, any access to the internet from any departmental lan, could
be directed via the Core Firewalls - in this way, you get to dictate a
single central policy for management of all remote departmental
gateways - thus preventing the nightmare of autonomous, unrestricted
internet access.

Thirdly, seperating address space at layer 3 neatly seperates
collision and broadcast domains - thus you dont have weird arp
issues/cam aging problems/dhcp relay failures/weird spanning tree
configurations.

Fourthly, firewalls which operate in transparent mode often fail-open.
That is to say if the FW module fails packets are still forwarded --
obviously not a great idea. With NAT, you have much more flexibility
to operate fail-safe mechanisms in the event of FW inspection failure
(ie. ACLs).

Finally (well not really, but Ive added enough for now), Central
Management of a University Security Policy would be very easy to
deploy, manage and maintain using a Centrally administered policy.
You will find a gadzillion campus networks have been designed with a
lot of what you have put forward in your second option. However, I
doubt you will find too many large scale deployments of Transparent
designs.

Good Luck

SysAdm

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

"SysAdm" <willgeeza@yahoo.com> wrote in message
news:a23233af.0406191536.4619b975@posting.google.com...

> Fourthly, firewalls which operate in transparent mode often fail-open.
> That is to say if the FW module fails packets are still forwarded --
> obviously not a great idea. With NAT, you have much more flexibility
> to operate fail-safe mechanisms in the event of FW inspection failure
> (ie. ACLs).

Just what I was thinking. With a transparent system, a bad guy could go in
and remove the firewall (!) and we might not know it. With a NAT system, as
long as the NAT is working, we have appreciable protection, regardless of
what other firewall features may be dysfunctional.

> Finally (well not really, but I've added enough for now), Central
> Management of a University Security Policy would be very easy to
> deploy, manage and maintain using a Centrally administered policy.
> You will find a gadzillion campus networks have been designed with a
> lot of what you have put forward in your second option. However, I
> doubt you will find too many large scale deployments of Transparent
> designs.

Where can I find some specific examples?

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Michael A. Covington" <look@www.covingtoninnovations.com.for.address> writes:

>I'm looking for some expert opinions on the following question:

>Should individual departments in a large university be behind NAT firewalls
>or transparent firewalls?

>Proposal (1):

>The university assigns every PC (and Mac, and network printer, and whatnot)
>an IP address from its allocation, and DHCP-serves the PC from its central
>DHCP server, which also serves as an inventory of networked computers on
>campus. Departments are encouraged to get firewalls, which must be
>transparent and capable of DHCP relaying. Departmental subnets work whether
>or not a firewall is present.

>Proposal (2):

>The university assigns the minimum number of IP addresses (often just one)
>to each department, and the department uses a NAT firewall to assign
>internal IP addresses to the computers behind it. (Just like we do at home
>with cable modems.)

The router boxes you use with cable modems are designed for cable
modem speeds. You may find that they cannot keep up with 100Mbs
ethernet, or even 10MBs ethernet. Thus they may be constraining in
speed unless your department throughput is modest.

If you go for bigger NAT boxes, you may need to have someone on had
for their care and feeding.

One of the major risks today is email carried virus/worm/trojan
software, and trojans installed by malevolent web pages. A NAT box
won't protect you from those.

If one of your department machines is compromized, your central
network administrators may have to block your NAT box to protect the
rest of the campus. They will, in effect, be blocking the whole
department.

Your NAT box prevents network central from scanning your individual
machines for security problems. It may give you a false sense of
security, and leave you with insecure boxes because you have not kept
up with security patching.

And, of course, if somebody brings in compromised laptop, and
connects to your department network behind your NAT box, the NAT
arrangement will not prevent your other machines from being
compromised.

>My impression is that (1) is easier to troubleshoot and manage from a
>central location, but (2) is more convenient (you can just bring your laptop
>and plug it in, without registering with the central DHCP server).

Unless you have tight control over who can plug in which laptops,
this extra convenience might introduce serious risk. As people
carry their laptops to meetings in other departments, they can
still spread their virus infections across the campus.

>(N.B. The university I'm talking about is not necessarily my own. Consider
>this a theoretical long-term question.)

Long term, we don't know what the threats will be. It is difficult
enough to deal with the short term.

NAT gives some protection, but it is not a panacea. I would think it
makes more sense to use NAT as part of a campus-wide firewall, rather
than to use on a departmental basis. That protects you from attacks
coming from outside. But it recognizes that the campus is a
community, and needs a community wide security policy.

That's just my opinion.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (SunOS)

iD8DBQFA1K71vmGe70vHPUMRAjOvAKDH22l/fQB29zdLygzWub9ouc+f3ACcCBEA
kt0rlc36HFNp8MiEFOv0GZw=
=FBOo
-----END PGP SIGNATURE-----

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Thanks, Neil. That's a good statement of the case against NAT.

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

In article <cb2ato$j98$1@usenet.cso.niu.edu>, rickert+nn@cs.niu.edu
says...
> Your NAT box prevents network central from scanning your individual
> machines for security problems. It may give you a false sense of
> security, and leave you with insecure boxes because you have not kept
> up with security patching.

Actually, NAT'ing departments might be a good thing. If each department
has it's own subnet and IT can VPN between them it would help to isolate
traffic and compromised machines. If one department gets hacked the
others still remain untouched in some cases.

> And, of course, if somebody brings in compromised laptop, and
> connects to your department network behind your NAT box, the NAT
> arrangement will not prevent your other machines from being
> compromised.

See the above - depending on the forwarding/routing rules, NAT'ing
buildings or departments, depending on the sized of the networks, might
just be a good idea. Security by isolation from other departments /
buildings.

I would not use NAT alone, I would install firewall appliances in select
zones to isolate in/out bound traffic from those areas, give each it's
own subnet, and use VPN's to the firewalls to provide management /
support of those networks.


--
--
spamfree999@rrohio.com
(Remove 999 to reply to me)

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

> See the above - depending on the forwarding/routing rules, NAT'ing
> buildings or departments, depending on the sized of the networks, might
> just be a good idea. Security by isolation from other departments /
> buildings.
>
> I would not use NAT alone, I would install firewall appliances in select
> zones to isolate in/out bound traffic from those areas, give each it's
> own subnet, and use VPN's to the firewalls to provide management /
> support of those networks.

Thanks, Leythos, for stating the other side.

Central staff could VPN and remote administration to get into, and behind,
departmental NAT firewalls.

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

"Michael A. Covington" <look@www.covingtoninnovations.com.for.address> wrote in message news:<nqidnVDCHbveQkndRVn-uA@speedfactory.net>...
> "SysAdm" <willgeeza@yahoo.com> wrote in message
> news:a23233af.0406191536.4619b975@posting.google.com...
>
> > Fourthly, firewalls which operate in transparent mode often fail-open.
> > That is to say if the FW module fails packets are still forwarded --
> > obviously not a great idea. With NAT, you have much more flexibility
> > to operate fail-safe mechanisms in the event of FW inspection failure
> > (ie. ACLs).
>
> Just what I was thinking. With a transparent system, a bad guy could go in
> and remove the firewall (!) and we might not know it. With a NAT system, as
> long as the NAT is working, we have appreciable protection, regardless of
> what other firewall features may be dysfunctional.

great minds...

<snip>

> Where can I find some specific examples?

Google is your friend... try punching in "Campus network design
example" and you get lots (no, make that more than lots)... With that
specific search phrase you will find plenty of live examples from
other Universities.

http://www.washington.edu/networking/overview.html
www.usg.edu/conferences/networking/campus_design.pdf
http://searchnetworking.techtarget.com/originalContent/0,289142,sid7_gci803121,00.html

I would also recommend a couple of CiscoPress books:
Top Down Network Design (2nd edition)
General Design Considerations for Secure Networks

both can be purchased via amazon or ciscopress.

Lastly, although security is a very important factor, you should
consider your Layer 1-3 requirements before thinking about applying a
security policy. However, that is another discussion completely.

SysAdm

 

[Alec]

Archived from groups: comp.security.firewalls (More info?)

"Michael A. Covington" <look@www.covingtoninnovations.com.for.address> wrote
in message news:nqidnVDCHbveQkndRVn-uA@speedfactory.net...
> "SysAdm" <willgeeza@yahoo.com> wrote in message
> news:a23233af.0406191536.4619b975@posting.google.com...
>
> > Fourthly, firewalls which operate in transparent mode often fail-open.
> > That is to say if the FW module fails packets are still forwarded --
> > obviously not a great idea. With NAT, you have much more flexibility
> > to operate fail-safe mechanisms in the event of FW inspection failure
> > (ie. ACLs).
>
> Just what I was thinking. With a transparent system, a bad guy could go
in
> and remove the firewall (!) and we might not know it. With a NAT system,
as
> long as the NAT is working, we have appreciable protection, regardless of
> what other firewall features may be dysfunctional.
>

I'm not sure what "most" transparent mode firewalls do, or why SysAdm said
what he did... but NetScreen firewalls can operate in a layer 2, or
"transparent" mode and they do not fail open. There really are only a
handful of firewall vendors that offer a transparent mode, as far as I know.
NetScreen is one of the few that offers it as a serious alternative.

> > Finally (well not really, but I've added enough for now), Central
> > Management of a University Security Policy would be very easy to
> > deploy, manage and maintain using a Centrally administered policy.
> > You will find a gadzillion campus networks have been designed with a
> > lot of what you have put forward in your second option. However, I
> > doubt you will find too many large scale deployments of Transparent
> > designs.
>
> Where can I find some specific examples?
>
You might be surprised. I know of at least one Fortune 100 company that
specifically desired transparent mode firewall functionality for a wide
variety of reasons. In fact, from my (albeit limited) perspective,
transparent mode is increasingly considered a legitimate, desirable
alternative... rather than less so. People are discovering that even with
support for dynamic routing protocols like OSPF and BGP, integrating
route-based firewalls into complicated route environments can sometimes be
more problematic than initially thought.

 

[mailMan]

Archived from groups: comp.security.firewalls (More info?)

To NAT or not to NAT, that is the question

....unfortunately it is probably not the right one!

You really need to consider this in the context of your network requirements
before you can come up with a reasonable answer. For example:

- what resources do the people need to access outside their "workgroups"? Is
it only to browse the Internet, or do you actually need something more,
such as disk/print servers, databases, etc.

- what is it you are trying to protect? Is this just a defence against a
virus spreading, or are there some private resources at risk such as grades
databases, academic papers in progress, etc?

- what do the users actually need? Just an example: do they expect to move
from workgroup to workgroup, plug their laptop in and have instant access
to their (remotely served) home directory? Single sign-on perhaps?

All these questions can influence the sort of security solution you'll use.
It is important to design security into an installation right from the
start, but you still need to consider it in a larger context. The questions
above (and a whole bunch of others) will allow you to deduce what kind of
bandwidth you need, internal IP address exposure/reverse NAT, security
risks, etc.

From experience: if your security solution does not serve the users' needs
they'll find a way to circumvent it. Work with your users, not against
them.
--
Mailman

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

"Alec" <alec@nospam.com> wrote in message news:<Q8qBc.2076$vU2.593@newssvr23.news.prodigy.com>...
> "Michael A. Covington" <look@www.covingtoninnovations.com.for.address> wrote
> in message news:nqidnVDCHbveQkndRVn-uA@speedfactory.net...
> > "SysAdm" <willgeeza@yahoo.com> wrote in message
> > news:a23233af.0406191536.4619b975@posting.google.com...
> >
> > > Fourthly, firewalls which operate in transparent mode often fail-open.
> > > That is to say if the FW module fails packets are still forwarded --
> > > obviously not a great idea. With NAT, you have much more flexibility
> > > to operate fail-safe mechanisms in the event of FW inspection failure
> > > (ie. ACLs).
> >
> > Just what I was thinking. With a transparent system, a bad guy could go
> in
> > and remove the firewall (!) and we might not know it. With a NAT system,
> as
> > long as the NAT is working, we have appreciable protection, regardless of
> > what other firewall features may be dysfunctional.
> >
>
> I'm not sure what "most" transparent mode firewalls do, or why SysAdm said
> what he did... but NetScreen firewalls can operate in a layer 2, or
> "transparent" mode and they do not fail open. There really are only a
> handful of firewall vendors that offer a transparent mode, as far as I know.
> NetScreen is one of the few that offers it as a serious alternative.
<snip>

NetScreen were the vendor I was actually thinking about when I made my
remarks about transparent mode and failing open. I think it was back
in October/November of last year when I first found that out - I do
not know whether the latest ScreenOS has since cured this problem.
Nokia/Checkpoint, Nortel and Lucent also offer Transparent Mode (at
enterprise class).

> >
> > Where can I find some specific examples?
> >
> You might be surprised. I know of at least one Fortune 100 company that
> specifically desired transparent mode firewall functionality for a wide
> variety of reasons. In fact, from my (albeit limited) perspective,
> transparent mode is increasingly considered a legitimate, desirable
> alternative... rather than less so. People are discovering that even with
> support for dynamic routing protocols like OSPF and BGP, integrating
> route-based firewalls into complicated route environments can sometimes be
> more problematic than initially thought.

Just about all RFI's that I have seen requesting Transparent Mode have
come from ISP-type environments. That isnt to say that Transparent
Mode doesn't have its uses in the enterprise. I like the idea myself,
but then I see too many caveats with regards to its use with the
Firewall software (ie. what exactly is supported when using
transparent mode compared to what is supported when using a NAT mode).
Maybe as it matures as a technology within the firewall arena, it
will be deployed at a greater number of sites.

Im not sure what you mean by route-based firewalls so I cant comment.
What I would say is that most firewalls today provide support for
certain Routing Protocols (both unicast and multicast). One of the
reasons why this has occured is because it saves companies having to
buy extra L3 hardware to cover their site(s) routing requirements (and
money$ is king). Firewalls which support routing protocols were not
available when books like Building Internet Firewalls was published.
It is certainly no longer inconceivable (and has been this way for a
good few years) to run routing protocols on firewalls.

anyway - i'll stop rambling now. things to do

SysAdm

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

On 21 Jun 2004 04:23:03 -0700, willgeeza@yahoo.com (SysAdm) wrote:

>"Alec" <alec@nospam.com> wrote in message news:<Q8qBc.2076$vU2.593@newssvr23.news.prodigy.com>...

>NetScreen were the vendor I was actually thinking about when I made my
>remarks about transparent mode and failing open. I think it was back
>in October/November of last year when I first found that out - I do
>not know whether the latest ScreenOS has since cured this problem.

Being Netscreen, you more than likely have to swap out your firewalls to
ones containing yet another ASIC revision to find out.



greg

--
"vying with Platt for the largest gap
between capability and self perception"

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

Greg Hennessy <me@privacy.net> wrote in message news:<gtldd01vd2346370ofrrrkp02q3jepu7rt@4ax.com>...
> On 21 Jun 2004 04:23:03 -0700, willgeeza@yahoo.com (SysAdm) wrote:
>
> >"Alec" <alec@nospam.com> wrote in message news:<Q8qBc.2076$vU2.593@newssvr23.news.prodigy.com>...
>
> >NetScreen were the vendor I was actually thinking about when I made my
> >remarks about transparent mode and failing open. I think it was back
> >in October/November of last year when I first found that out - I do
> >not know whether the latest ScreenOS has since cured this problem.
>
> Being Netscreen, you more than likely have to swap out your firewalls to
> ones containing yet another ASIC revision to find out.
>
> greg

I thought that was a feature

ps. weve just added network processors into our biggest box (IP2250).
....7.5Gb/s (1518byte frame) and almost 2Gb/s VPN (3DES). IPSO 3.8 is
looking very nice as well. Clustering has come a long way since 3.6.

 

[Alec]

Archived from groups: comp.security.firewalls (More info?)

"Greg Hennessy" <me@privacy.net> wrote in message
news:gtldd01vd2346370ofrrrkp02q3jepu7rt@4ax.com...
> On 21 Jun 2004 04:23:03 -0700, willgeeza@yahoo.com (SysAdm) wrote:
>
> >"Alec" <alec@nospam.com> wrote in message
news:<Q8qBc.2076$vU2.593@newssvr23.news.prodigy.com>...
>
> >NetScreen were the vendor I was actually thinking about when I made my
> >remarks about transparent mode and failing open. I think it was back
> >in October/November of last year when I first found that out - I do
> >not know whether the latest ScreenOS has since cured this problem.

Not to be rude, but do you have any proof of that? I have worked with
NetScreen firewalls for nearly 2 years now and I have never seen or heard of
one in transparent mode failing open. I could just be misinformed, my
apologies, and in which case I would like the details so that I can rectify
my ignorance; or you could be misinformed, in which case I think that you do
a disservice by making statements without substantiation.

Perhaps you are confusing "failing open" with the way a NetScreen device
handles non-IP layer 2 traffic (ie, alternative protocols such as IPX,
NetBEUI, AppleTalk DDP, etc.) ? The user can configure the device to either
block non-IP layer 2 traffic or permit non-IP layer 2 traffic. Or, perhaps,
you are confusing the way a NetScreen device can handle unicast packets it
receives which aren't yet in its layer 2 forwarding table (eg, the hosts
devices have already performed ARP queries and have entries in their
respective ARP caches, but the NetScreen device has for example just been
rebooted and does not have similar information developed yet in its
forwarding table)? Once again the behavior in such a circumstance is user
configurable.

In many ways the failing open claim doesn't make much sense to me because
even in transparent mode, the NetScreen device will not pass packets without
an explicit policy that permits them (ie, it operates on a default deny
basis). Moreover, "fail open" implies that there has been some sort of
hardware or OS failure, and in most cases of such failure, I really cannot
comprehend that it would continue to pass any traffic at all. But, as I say,
I remain happy to read any technical evidence to the contrary regarding this
issue.

> Being Netscreen, you more than likely have to swap out your firewalls to
> ones containing yet another ASIC revision to find out.

Sounds like some with an anti-NetScreen axe to grind? It's a pretty silly
statement given that the ASIC only really performs repetitive, well-defined
chores common to nearly firewall/vpn devices... that is, things like session
table scanning, DES/3DES/AES encryption, MD5/SHA/RC4 hashing, etc. I suppose
no other vendor recommneds hardware assist for the encryption and hashing
algorithms underlying IPSec VPN technology?

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

"Alec" <alec@nospam.com> wrote in message news:<EqEBc.7778$Tx3.3582@newssvr24.news.prodigy.com>...
> "Greg Hennessy" <me@privacy.net> wrote in message
> news:gtldd01vd2346370ofrrrkp02q3jepu7rt@4ax.com...
> > On 21 Jun 2004 04:23:03 -0700, willgeeza@yahoo.com (SysAdm) wrote:
> >
> > >"Alec" <alec@nospam.com> wrote in message
> news:<Q8qBc.2076$vU2.593@newssvr23.news.prodigy.com>...
>
<snip>
I had a sniff back through my mail archives and came up with this:
http://lists.netsys.com/pipermail/full-disclosure/2003-July/006402.html

and its more formal version:
http://www.securitytracker.com/alerts/2003/Jul/1007148.html

My memory was a bit out, it was July last year when I got this, not
november. The disclosure noted that:
"...brodcast frames carrying protocols like SNA, IPX CDP, CDP, VST ...
will all happily cross the firewall in and out without being checked
nor logged, possibly reaching remote parts of corporate networks. Even
the zone used for managing the firewall is not immune !!!"

What I found far worse than this was the author went on to note that:

"...Not only is the flaw infamous, but here is the worst:
NetScreen devised a FAKE, dummy screening option: "bypass non-IP
traffic". Toggling it on or off has absolutely no effect..."

But anyhow - rather than copy paste, it would be worth reading the
article. It seems that the testing was carried out using Bridge mode.
This was where my memory failed me with my reference to fail-open.
The exploit patently didnt even need the firewall module to fail in
order to be effective.

So, fail-open or not it seems that the flaw was even more serious.
Again, this was last July. I am uncertain at this time whether the
bug has been rectified. According to the report, Netscreen were
notified.

ps. hope I wasnt rude...

SysAdm

 

[Guest]

Archived from groups: comp.security.firewalls (More info?)

On Mon, 21 Jun 2004 16:56:04 GMT, "Alec" <alec@nospam.com> wrote:

>

>> Being Netscreen, you more than likely have to swap out your firewalls to
>> ones containing yet another ASIC revision to find out.
>
>Sounds like some with an anti-NetScreen axe to grind?

No, just real world practical experience from having to swap out NS 10s
because no code newer than 2.0 would run on them.

A pix 506 of the same age would have no issues running 6.x.


greg

--
"vying with Platt for the largest gap
between capability and self perception"

 

[Alec]

Archived from groups: comp.security.firewalls (More info?)

"SysAdm" <willgeeza@yahoo.com> wrote in message
news:a23233af.0406211436.4f27bed4@posting.google.com...
> "Alec" <alec@nospam.com> wrote in message
news:<EqEBc.7778$Tx3.3582@newssvr24.news.prodigy.com>...

<snip>

> "...Not only is the flaw infamous, but here is the worst:
> NetScreen devised a FAKE, dummy screening option: "bypass non-IP
> traffic". Toggling it on or off has absolutely no effect..."
>
> But anyhow - rather than copy paste, it would be worth reading the
> article. It seems that the testing was carried out using Bridge mode.
> This was where my memory failed me with my reference to fail-open.
> The exploit patently didnt even need the firewall module to fail in
> order to be effective.
>
> So, fail-open or not it seems that the flaw was even more serious.
> Again, this was last July. I am uncertain at this time whether the
> bug has been rectified. According to the report, Netscreen were
> notified.
>
> ps. hope I wasnt rude...
>
> SysAdm

No problems. This was the issue I thought you might have been referring to,
however non-IP protocol processing is not the same as saying "fails open".
Those concepts are very different in my mind, although I do agree that
passing non-IP protocols without the user aware of (and in control of) that
behavior is a very serious security breach in its own right. However, I do
believe the information is out-of-date. Although I haven't done exhaustive
testing with many non-IP protocols, I nevertheless feel fairly confident
that at least in version 5.0 of ScreenOS that the "unset interface vlan1
bypass-non-ip-all" function does indeed block all non-IP and non-ARP
traffic. I think one of the difficulties is in configuring the device to
properly block most non-ip protocols and yet still support some perhaps
desired layer 2 non-ip protocols like the Spanning Tree Protocol. There
could, perhaps, still be finer grained layer 2 non-ip blocking mechanisms,
but I do believe the full block does now work.

I didn't mean to be rude either, I just had never had any real problems with
a transparent mode firewall of the type you mentioned and so I was certainly
interested. I believe that there are certain positives, and negatives, to
almost all of the firewall devices out there right now. Competition has been
good for the firewall market, IMHO. I certainly hope the Nokia's work out
well for you. They have some good gear, although I don't think its right for
every situation... just as I don't think that NetScreen is right for every
situation. I am just trying to be objective. The initial question involved
transparent firewalling and NetScreen happens to be one of the first I think
of when it comes to transparent mode firewalling. That's all.

Alec