Please unsubscribe me from your list for the last time.
Curtis Hunt
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 09, 2002 3:54 PM
To: [EMAIL PROTECTED]
Subject: Firewalls digest, Vol 1 #449 - 9 msgs
Send Firewalls mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnac.net/mailman/listinfo/firewalls
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Firewalls digest..."
Today's Topics:
1. Re: [Security for] Analysis port for 3com 3300 was Re: (no
subject) (Ken Milder)
2. Cisco Security Advisory: Multiple Vulnerabilities in Cisco SN 5420
Storage Router (Cisco Systems Product Security Incident Response Team)
3. Subject: PIX Access list (Chew, Freeland (Roanoke))
4. Stateful Pix (Chew, Freeland (Roanoke))
5. Re: Subject: PIX Access list (Network Operations)
6. Re: [Security for] Analysis port for 3com 3300 was Re: (no subject)
(Paul Robertson)
7. Re: Subject: PIX Access list (Network Operations)
8. Re: Stateful Pix (Network Operations)
--__--__--
Message: 1
Date: Wed, 09 Jan 2002 13:02:26 -0700
To: [EMAIL PROTECTED]
From: Ken Milder <[EMAIL PROTECTED]>
Subject: Re: [Security for] Analysis port for 3com 3300 was Re: (no
subject)
Cc: <[EMAIL PROTECTED]>
--=====================_618238029==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Because this is a firewalls list, this thread can serve as a good segue
into a question about switch security that has been on my mind for some
time:
Most switches support remote management features like web interfaces, SNMP,
telnet, etc. If these switches hacked, someone can not only cause a denial
of service, but use the port mirroring feature to sniff traffic. So, I am
curious to know the thoughts of others in addressing this issue. (I know
that some of the more expensive switches and routers can utilize encrypted
passwords, but I believe community strings are still clear text, correct?)
At 1/4/2002 12:10 PM, [EMAIL PROTECTED] wrote:
>With the 3com 3300, in order to monitor the network traffic that is
>traversing the 3com 3300 switch, one must configure what is called a
>monitor port or analysis port (under the Roving Analysis Setup) using the
>3com Switch Management Software. One has to define an Analysis port (the
>port that is connected to the Sniffer) and a monitor port (the port that
>is being monitored). Once the two are defined, and it is enabled via the
>Switch Management software, the stack passes all the traffic going in and
>out of the monitor port and copies it to the analysis port.
>
>If you are attempting to monitor traffic across multiple VLANs, an
>analysis port must be setup in each VLAN used by the 3com 3300.
>
>Note: The analysis port should be configured to have a higher bandwidth
>than the monitor port, otherwise, not all traffic that is being analyzed
>will be captured entirely.
>
>/hope this helps
>
>/cheers,
>
>*useless memorization of switch/router configuration options.. * (these
>type of questions never appear on a CISSP exam.:-)
>
>/m
>
>At 11:53 AM 1/4/2002 -0800, William Stackpole wrote:
>>Daniel,
>>
>>Most switches will allow one or more ports to be combined or cross
connected
>>for this very purpose. If this isn't possible then the best you can do is
>>put the sniffer on the backbone segment attached to the switch. You
>>wouldn't be able to see the traffic between individual switch nodes but
you
>>will be conversations out to servers, Internet connections etc. The other
>>alternative, if this is a temporary situsation for troubleshooting
purposes,
>>you could replace the switch with a hub.
>>
>>-- Bill Stackpole, CISSP
>>
>>
>>----- Original Message -----
>>From: <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Friday, January 04, 2002 11:14 AM
>>Subject: (no subject)
>>
>>
>> > Hi,
>> >
>> > how do I use snnifer in a switch in a way that permits to capture all
>> > traffic ? (3com 3300)
>> >
>> > Thank's in advance,
>> > Daniel
>> >
>> > _______________________________________________
>> > Firewalls mailing list
>> > [EMAIL PROTECTED]
>> > http://lists.gnac.net/mailman/listinfo/firewalls
>>
>>_______________________________________________
>>Firewalls mailing list
>>[EMAIL PROTECTED]
>>http://lists.gnac.net/mailman/listinfo/firewalls
>
>_______________________________________________
>Firewalls mailing list
>[EMAIL PROTECTED]
>http://lists.gnac.net/mailman/listinfo/firewalls
*********************************************************************
Kenneth H. Milder
Los Alamos National Laboratory
Computing, Communications & Networking Division (CCN)
Network Engineering Group(CCN-5)
Network Support Team (NST)/X Division Computing Services Team (XCS)
MS-F645
Los Alamos, New Mexico 87545-0010
Office: (505)667-2552
Fax: (505)665-3389
E-mail: [EMAIL PROTECTED]
*********************************************************************
--=====================_618238029==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Because this is a firewalls list, this thread can serve as a good segue
into a question about switch security that has been on my mind for some
time:<br>
<br>
Most switches support remote management features like web interfaces,
SNMP, telnet, etc. If these switches hacked, someone can not only cause a
denial of service, but use the port mirroring feature to sniff traffic.
So, I am curious to know the thoughts of others in addressing this issue.
(I know that some of the more expensive switches and routers can utilize
encrypted passwords, but I believe community strings are still clear
text, correct?)<br>
<br>
At 1/4/2002 12:10 PM, [EMAIL PROTECTED] wrote:<br>
<blockquote type=cite class=cite cite>With the 3com 3300, in order to
monitor the network traffic that is traversing the 3com 3300 switch, one
must configure what is called a monitor port or analysis port (under the
Roving Analysis Setup) using the 3com Switch Management Software.
One has to define an Analysis port (the port that is connected to the
Sniffer) and a monitor port (the port that is being monitored).
Once the two are defined, and it is enabled via the Switch Management
software, the stack passes all the traffic going in and out of the
monitor port and copies it to the analysis port.<br>
<br>
If you are attempting to monitor traffic across multiple VLANs, an
analysis port must be setup in each VLAN used by the 3com 3300.<br>
<br>
Note: The analysis port should be configured to have a higher
bandwidth than the monitor port, otherwise, not all traffic that is being
analyzed will be captured entirely.<br>
<br>
/hope this helps<br>
<br>
/cheers,<br>
<br>
*useless memorization of switch/router configuration options.. * (these
type of questions never appear on a CISSP exam.:-)<br>
<br>
/m<br>
<br>
At 11:53 AM 1/4/2002 -0800, William Stackpole wrote:<br>
<blockquote type=cite class=cite cite>Daniel,<br>
<br>
Most switches will allow one or more ports to be combined or cross
connected<br>
for this very purpose. If this isn't possible then the best you can
do is<br>
put the sniffer on the backbone segment attached to the switch.
You<br>
wouldn't be able to see the traffic between individual switch nodes but
you<br>
will be conversations out to servers, Internet connections etc. The
other<br>
alternative, if this is a temporary situsation for troubleshooting
purposes,<br>
you could replace the switch with a hub.<br>
<br>
-- Bill Stackpole, CISSP<br>
<br>
<br>
----- Original Message -----<br>
From: <[EMAIL PROTECTED]><br>
To: <[EMAIL PROTECTED]><br>
Sent: Friday, January 04, 2002 11:14 AM<br>
Subject: (no subject)<br>
<br>
<br>
> Hi,<br>
><br>
> how do I use snnifer in a switch in a way that permits to capture
all<br>
> traffic ? (3com 3300)<br>
><br>
> Thank's in advance,<br>
> Daniel<br>
><br>
> _______________________________________________<br>
> Firewalls mailing list<br>
> [EMAIL PROTECTED]<br>
>
<a href="http://lists.gnac.net/mailman/listinfo/firewalls";
eudora="autourl">http://lists.gnac.net/mailman/listinfo/firewalls</a><br>
<br>
_______________________________________________<br>
Firewalls mailing list<br>
[EMAIL PROTECTED]<br>
<a href="http://lists.gnac.net/mailman/listinfo/firewalls";
eudora="autourl">http://lists.gnac.net/mailman/listinfo/firewalls</a></block
quote><br>
_______________________________________________<br>
Firewalls mailing list<br>
[EMAIL PROTECTED]<br>
<a href="http://lists.gnac.net/mailman/listinfo/firewalls";
eudora="autourl">http://lists.gnac.net/mailman/listinfo/firewalls</a><br>
</blockquote>
<x-sigsep><p></x-sigsep>
<font face="Arial Unicode MS, Helvetica"
size=4>*********************************************************************
<br>
Kenneth H. Milder<br>
Los Alamos National Laboratory<br>
Computing, Communications & Networking Division (CCN)<br>
Network Engineering Group(CCN-5)<br>
Network Support Team (NST)/X Division Computing Services Team (XCS)<br>
MS-F645<br>
Los Alamos, New Mexico 87545-0010<br>
<br>
Office: (505)667-2552<br>
Fax:<x-tab> </x-tab>
(505)665-3389<br>
E-mail: [EMAIL PROTECTED]<br>
*********************************************************************</font>
</html>
--=====================_618238029==_.ALT--
--__--__--
Message: 2
Date: Wed, 9 Jan 2002 20:09:31 GMT
To: [EMAIL PROTECTED]
Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco SN 5420
Storage Router
From: Cisco Systems Product Security Incident Response Team
<[EMAIL PROTECTED]>
Reply-To: Cisco Systems Product Security Incident Response Team
<[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
-----BEGIN PGP SIGNED MESSAGE-----
Cisco Security Advisory: Multiple Vulnerabilities in Cisco SN 5420 Storage
Routers
Revision 1.0
For Public Release 2002 January 09 08:00 (UTC -0800)
Summary
Three vulnerabilities have been discovered in Cisco SN 5420 Storage
Router software releases up to and including 1.1(5). Two of the
vulnerabilities can cause a Denial-of-Service attack. The other allows
an access to the SN 5420 configuration if it has been previously saved
on the router.
There is no workaround for these vulnerabilities.
No other Cisco product is vulnerable.
This advisory is available at the
http://www.cisco.com/warp/public/707/SN-multiple-pub.shtml
Affected Products
Cisco SN 5420 Storage Routers running software release up to and
including 1.1(5) are affected by the vulnerabilities. Please note that
1.1(6) version of the software was never released by Cisco.
To determine your software release, type show system at the command
prompt.
No other Cisco products are affected.
Details
CSCdv24925
It is possible to read stored configuration file from the
Storage Router without any authorization.
CSCdu32533
By sending a HTTP request with a huge headers it is possible to
crash the Storage Router.
CSCdu45417
It is possible to halt the Storage Router by sending a
fragmented packet over the Gigabit interface.
Impact
CSCdv24925
An unauthorized person may read the configuration of the
Storage Router. That may lead to unauthorized access of a
storage space.
CSCdu32533
By exploiting this vulnerability an attacker can cause
Denial-of-Service.
CSCdu45417
By exploiting this vulnerability an attacker can cause
Denial-of-Service.
Software Versions and Fixes
All three vulnerabilities are fixed in the release 1.1(7) of the
software, which is available on CCO. Please note that version 1.1(6)
of the software was never released by Cisco.
Obtaining Fixed Software
Cisco is offering free software upgrades to eliminate this
vulnerability for all affected customers.
Customers with contracts should obtain upgraded software through their
regular update channels. For most customers, this means that upgrades
should be obtained through the Software Center on Cisco's Worldwide
Web site at http://www.cisco.com.
Customers whose Cisco products are provided or maintained through
prior or existing agreement with third-party support organizations
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for assistance with the
upgrade, which should be free of charge.
Customers who purchase direct from Cisco but who do not hold a Cisco
service contract and customers who purchase through third party
vendors but are unsuccessful at obtaining fixed software through their
point of sale should get their upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows:
* +1 800 553 2447 (toll-free from within North America)
* +1 408 526 7209 (toll call from anywhere in the world)
* e-mail: [EMAIL PROTECTED]
Please have your product serial number available and give the URL
of this notice as evidence of your entitlement to a free upgrade. Free
upgrades for non-contract customers must be requested through the TAC.
Please do not contact either "[EMAIL PROTECTED]" or
"[EMAIL PROTECTED]" for software upgrades.
Workarounds
CSCdv24925
It is possible to mitiagte this vulnerability by blocking
access on the network's edge and by using hard to guess names
for saved configuration.
CSCdu32533
There is no workaround for this vulnerability.
CSCdu45417
There is no workaround for this vulnerability.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerabilities described in this advisory.
These vulnerabilities were found internally during product testing.
Status of This Notice: FINAL
This is a final notice. Although Cisco cannot guarantee the accuracy
of all statements in this notice, all of the facts have been checked
to the best of our ability. Cisco does not anticipate issuing updated
versions of this notice unless there is some material change in the
facts. Should there be a significant change in the facts, Cisco may
update this notice.
A standalone copy or paraphrase of the text of this security advisory
that omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.
Distribution
This notice will be posted on Cisco's Worldwide Web site at
http://www.cisco.com/warp/public/707/SN-multiple-pub.shtml. In
addition to Worldwide Web posting, a text version of this notice is
clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients:
* [EMAIL PROTECTED]
* [EMAIL PROTECTED]
* [EMAIL PROTECTED] (includes CERT/CC)
* [EMAIL PROTECTED]
* comp.dcom.sys.cisco
* [EMAIL PROTECTED]
* Various internal Cisco mailing lists
Future updates of this notice, if any, will be placed on Cisco's
Worldwide Web server, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the URL given above for any updates.
Revision History
Revision 1.0 2002-Jan-09 08:00 GMT-0800 Initial public release
Cisco Security Procedures
Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and
registering to receive security information from Cisco, is available
on Cisco's Worldwide Web site at
http://www.cisco.com/warp/public/707/sec_incident_response.shtml.
This includes instructions for press inquiries regarding Cisco
security notices.
All Cisco Security Advisories are available at
http://www.cisco.com/go/psirt
_________________________________________________________________
This notice is Copyright 2002 by Cisco Systems, Inc. This notice may
be redistributed freely after the release date given at the top of the
text, provided that redistributed copies are complete and unmodified,
and include all date and version information.
_________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3
iQEVAwUBPDyfZQ/VLJ+budTTAQGPlQf/QcizC19+IoYmFuauri5RmYL2+vMqi50g
rdDpDR02tHrn13lTUMQz0sqqXSjfl/iGle6nmua1buVfWnQbUWceD3PhMYU47r2v
rBzroMA6JZN9cVYK6Iyn1p0m6N0RYYoHOg6Fh2Wcc4WoH+NltUzrJigBmqtrfNlZ
NJuLX2OQg/SvdOodqBEO8WfazYwI4tXWhMVVz9CZCtCvSrV6Bbj8IdxZd/PLmPIS
9vrS8cjRC7xQCSPK38NnXzzhqnMWn5aWurfkOplu0aY6E5mrWpEfskiW/IU2xX9O
CRvqvqbSWyXFw1lk/0hvb4wVhhGu5TrbdXu3fTirFHGtem9mnOVqQw==
=D/rj
-----END PGP SIGNATURE-----
--__--__--
Message: 3
From: "Chew, Freeland (Roanoke)" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Subject: PIX Access list
Date: Wed, 9 Jan 2002 15:34:27 -0500
In the PIX configuration Access Lists are for outbound traffic. Use the
Conduit command for inbound controls.
Message: 3
Date: Wed, 9 Jan 2002 10:27:49 -0200 (BRST)
From: Edson Yamada <[EMAIL PROTECTED]>
To: lista fw <[EMAIL PROTECTED]>
Subject: PIX Access list
Hello,
Cisco routers access lists allow the administrator
define if the list must be applied to the INcoming
or OUTcoming traffic of a given interface.
It seems that PIX access lists dont permit that.
So, my question is: if I bind a list to a interface,
this list is applied against the outcoming, incoming
or both kind of traffic?
Thank you
Edson
-- __--__--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
--__--__--
Message: 4
From: "Chew, Freeland (Roanoke)" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Stateful Pix
Date: Wed, 9 Jan 2002 15:36:41 -0500
Yes the PIX will allow the answers to the DNS queries back in without any
other configuration.
Message: 4
Date: Wed, 9 Jan 2002 10:32:19 -0200 (BRST)
From: Edson Yamada <[EMAIL PROTECTED]>
To: lista fw <[EMAIL PROTECTED]>
Subject: Stateful inspection on PIX
Hello again,
Sorry if this is a stupid question.
I=B4ve been reading the PIX docs and it=B4s written
that PIX is stateful.
Let=B4s suppose that a host (behind the internal
interface) queries a DNS server that is located behind a outside
interface.
By default, all traffic that comes from the inside interface
to the outside is allowed, so the query passes through the
firewall, right?
What about the answer? As PIX is stateful, this means
that the answer for this specific query is allowed?
If not, do I have to apply an access list to allow the
answers?
Thanks
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
--__--__--
Message: 5
Date: Wed, 09 Jan 2002 13:14:45 -0800
From: "Network Operations" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: Subject: PIX Access list
In newer PIX code (5.3x + I think) you can use access-lists both ways...you=
can do away with conduit commands all together if you wish..
cheers..
>>> "Chew, Freeland (Roanoke)" <[EMAIL PROTECTED]> 01/09 12:34 PM >>>
In the PIX configuration Access Lists are for outbound traffic. Use the
Conduit command for inbound controls.
Message: 3
Date: Wed, 9 Jan 2002 10:27:49 -0200 (BRST)
From: Edson Yamada <[EMAIL PROTECTED]>
To: lista fw <[EMAIL PROTECTED]>
Subject: PIX Access list
Hello,
Cisco routers access lists allow the administrator
define if the list must be applied to the INcoming
or OUTcoming traffic of a given interface.
It seems that PIX access lists dont permit that.
So, my question is: if I bind a list to a interface,
this list is applied against the outcoming, incoming
or both kind of traffic?
Thank you
Edson
-- __--__--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com=20
**********************************************************************
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]=20
http://lists.gnac.net/mailman/listinfo/firewalls
--__--__--
Message: 6
Date: Wed, 9 Jan 2002 16:18:40 -0500 (EST)
From: Paul Robertson <[EMAIL PROTECTED]>
To: Ken Milder <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: [Security for] Analysis port for 3com 3300 was Re: (no
subject)
On Wed, 9 Jan 2002, Ken Milder wrote:
> Because this is a firewalls list, this thread can serve as a good segue
> into a question about switch security that has been on my mind for some
time:
>
> Most switches support remote management features like web interfaces,
SNMP,
> telnet, etc. If these switches hacked, someone can not only cause a denial
> of service, but use the port mirroring feature to sniff traffic. So, I am
> curious to know the thoughts of others in addressing this issue. (I know
> that some of the more expensive switches and routers can utilize encrypted
> passwords, but I believe community strings are still clear text, correct?)
My take-
If you need to "manage" a switch, you've got WAY too much time on your
hands. I've never put an IP address on a switch, and can't see any valid
reason for doing so that isn't better done at some other level or via a
different vector (such as a terminal server wired to console ports.)
In-band management wasn't good for the phone system, and it's not good for
IP
networks.
Paul
----------------------------------------------------------------------------
-
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
--__--__--
Message: 7
Date: Wed, 09 Jan 2002 13:25:24 -0800
From: "Network Operations" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: Subject: PIX Access list
Ok let me clarify something, I sense a bit of confusion here..
You need to free yourself from this INcomming/OUTgoing concept you are =
using, when referring to the PIX ok?
Because you can only ever see ONE interface depending on which side of the =
device youre on (if your architecture is designed properly).
You apply your access lists to the interface...period...the direction for =
data flow is irrelevant. If you want to restrict what traffic enters your =
network from the OUTSIDE (usually the internet) you apply the access-list =
to that interface (Usually OUTSIDE interface or Eth0)..
If you want to restrict what traffic goes out of your network from your =
internal hosts you apply the access-list to the interface that your =
internal hosts are hitting. (Usually the INSIDE interface or Eth1).
clear as mud??
Date: Wed, 9 Jan 2002 10:27:49 -0200 (BRST)
From: Edson Yamada <[EMAIL PROTECTED]>
To: lista fw <[EMAIL PROTECTED]>
Subject: PIX Access list
Hello,
Cisco routers access lists allow the administrator
define if the list must be applied to the INcoming
or OUTcoming traffic of a given interface.
It seems that PIX access lists dont permit that.
So, my question is: if I bind a list to a interface,
this list is applied against the outcoming, incoming
or both kind of traffic?
Thank you
Edson
-- __--__--
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com=20
**********************************************************************
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]=20
http://lists.gnac.net/mailman/listinfo/firewalls
--__--__--
Message: 8
Date: Wed, 09 Jan 2002 13:44:44 -0800
From: "Network Operations" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: Stateful Pix
Not a stupid question at all,
The default configuration will let DNS queries pass yes..However if you =
use the defualt config, you might as well put your PIX back in the box and =
return it, and get your 15k back.
You need to create access lists to DENY EVERYTHING. first. Then add =
access-lists for the traffic you want to allow. For example if you want to =
enable web traffic you need to create acces-lists to allow UDP domain =
queries, and another access-list to allow web (eq www) queries..
Now if you have devices in your DMZ and/or are running NAT it gets =
slightly more complicated, but not much..
cheers..
Marc..
Date: Wed, 9 Jan 2002 10:32:19 -0200 (BRST)
From: Edson Yamada <[EMAIL PROTECTED]>
To: lista fw <[EMAIL PROTECTED]>
Subject: Stateful inspection on PIX
Hello again,
Sorry if this is a stupid question.
I ve been reading the PIX docs and it s written
that PIX is stateful.
Let s suppose that a host (behind the internal
interface) queries a DNS server that is located behind a outside
interface.
By default, all traffic that comes from the inside interface
to the outside is allowed, so the query passes through the
firewall, right?
What about the answer? As PIX is stateful, this means
that the answer for this specific query is allowed?
If not, do I have to apply an access list to allow the
answers?
Thanks
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com=20
**********************************************************************
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]=20
http://lists.gnac.net/mailman/listinfo/firewalls
--__--__--
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
End of Firewalls Digest
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
