My background is Pure/Applied Mathematics, not Computer Security or Networking, but I do have questions concerning this portion of a previous post which I have copy/pasted. Please read it:
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 My questions are the following: 1. Should, God forbid, the unauthorized user send an HTTP request with a huge header, is this an example of Buffer Overflow? 2. Has the unauthorized user gained access to the "Storage Router" precisely because he previously gained access to the sequence number(s) in the three way handshake (Syn/Ack)? Yes, or no? Any responses to these two questions would be greatly appreciated. Robert Betts University of Massachusetts/Boston Harbor Campus. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 09, 2002 4:53 PM 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
