Yeah i guess there is nothing to do about it. As long as you want to keep the server running. what kind of pages are you serving? maybe you can switch to apache. anyway if you need any patch for your IIS Server, just log into www.microsoft.com/technet or use microsoft new software to detect server flaws "MBSA (Microsoft Baseline Security Analyzer)" download from here... http://download.microsoft.com/download/win2000platform/Install/1.0/NT5XP/EN- US/mbsasetup.msi
----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 5:57 PM Subject: Firewalls digest, Vol 1 #675 - 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: Attack through Port 80 (Clifford Thurber) > 2. Re: Bridging vs. Routing Firewalls. (Clifford Thurber) > 3. Re: Cisco IDS (Paul D. Robertson) > 4. Re: Bridging vs. Routing Firewalls. (Alexander.O'[EMAIL PROTECTED]) > 5. RE: Cisco IDS (Noonan, Wesley) > 6. Re: Bridging vs. Routing Firewalls. (Diederik Schouten) > 7. Re: Bridging vs. Routing Firewalls. (Clifford Thurber) > 8. Re: Bridging vs. Routing Firewalls. (Diederik Schouten) > 9. RE: Cisco IDS (Paul Robertson) > > --__--__-- > > Message: 1 > Date: Fri, 12 Apr 2002 09:46:38 -0400 > From: Clifford Thurber <[EMAIL PROTECTED]> > Subject: RE: Attack through Port 80 > To: [EMAIL PROTECTED], Fei Yang <[EMAIL PROTECTED]> > Cc: firewalls <[EMAIL PROTECTED]> > > How did you arrive at the fact that this IS a nimda attack? It could be > anything that's exploiting web directory traversal? > > At 11:01 AM 4/10/2002 +0530, vishal pranjale wrote: > >Hi Fei, > >That's nimda attack > >Nimda worm is attacking on your web server. > >So nothing to do with pix > >If your web server is not patched for Nimda then you will be in big trouble > >so just patch it for nimda. > >Urlscan is also much better option but test it before installing. > > > >Regards > >Vishal > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED]]On Behalf Of Fei Yang > >Sent: Tuesday, April 09, 2002 12:26 AM > >To: [EMAIL PROTECTED] > >Subject: Attack through Port 80 > > > > > >Last week I checked our IIS web server's log file and found the following > >attack logs. I am using a Cisco PIX and opened port 80 for our web server. > >Could anyone tell me what kind of attack these are and how to block them out > >of my network by PIX? > > > >#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem > >cs-uri-query sc-status cs(User-Agent) > >2002-03-29 01:39:24 24.157.182.174 - 24.157.93.95 80 GET > >/scripts/..%5c../winnt/system32/cmd.exe /c+dir 500 - > >2002-03-29 01:39:24 24.157.182.174 - 24.157.93.95 80 GET > >/scripts/..%5c../winnt/system32/cmd.exe /c+dir 500 - > >2002-03-29 01:39:24 24.157.182.174 - 24.157.93.95 80 GET > >/scripts/..%5c../winnt/system32/cmd.exe /c+dir 500 - > >2002-03-29 01:39:24 24.157.182.174 - 24.157.93.95 80 GET > >/scripts/..%2f../winnt/system32/cmd.exe /c+dir 500 - > > > >Thansk, > >Fei. > > > > > > > >_______________________________________________ > >Firewalls mailing list > >[EMAIL PROTECTED] > >http://lists.gnac.net/mailman/listinfo/firewalls > > > >_______________________________________________ > >Firewalls mailing list > >[EMAIL PROTECTED] > >http://lists.gnac.net/mailman/listinfo/firewalls > > > --__--__-- > > Message: 2 > Date: Fri, 12 Apr 2002 10:06:42 -0400 > From: Clifford Thurber <[EMAIL PROTECTED]> > Subject: Re: Bridging vs. Routing Firewalls. > To: Diederik Schouten <[EMAIL PROTECTED]>, > "Georges J. JAHCHAN P. Eng." <[EMAIL PROTECTED]> > Cc: Firewalls List <[EMAIL PROTECTED]> > > How about the practicality of managing one of these from thousands of miles > away? No IP means that someone needs to be in physical proximity. > > At 11:09 AM 4/12/2002 +0200, Diederik Schouten wrote: > >Bridging vs Riuting firewalls... > > > > > >The main strength of a bridged firewall to me is the fact that it only > >exists virtually on the network. > >How to attack a firewall that you cannot address directly? > >Even when you are connected to the same network/switch you will not be > >able to find the firewall, unless you know what you are > >looking for. > > > >Implementation wise a bridging/routing firewall offers you a few > >advantages over a routed one. > > > >1. when you have to add the firewall to an already existing network, you > >do not need to reconfigure any other device on the > >network, your addressing schemes and routing stays exactly the same, the > >only downtime you will have is due to the fact that > >you have to connect the cabels. (and even that can be solved by using > >vlan's on your switches and just swapping the upstream > >routers interface into a separate vlan together with the downstream > >interface of the firewall. > > > >- Since you do not need to change your routing topology you do not need to > >creat more transit subnets, and thus you save IP > >addresses. > >- When changing routing topologies often many devices will have to have > >their configuration changed. With a bridged firewall > >this is not needed. > > > >2. Putting multiple firewalls in series to create for example more ports > >becomes very easy, although for example with the > >Lucent BRICK this isnot necesary since it supports VLAN tagging and with a > >VLAN capable switch you can create virtually any > >number of "virtual" firewalls you might need, and give them all their own > >ruleset. > >No need for recabling and expensive upgrades. > > > >3. In general purpose build devices are less vulnerable, a purpose build > >firewall does not depend on the operating system of > >the router/platform it is running at, lowering the chance of being > >penetrated due to bugs in code other than for the firewall. > >(as Nokia, Checkpoint, Cisco etc.) > > > >4. When both your routing services and firewall services are based on one > >device, then everytime you need to make changes to > >the routing you will probably also have to change your firewwall > >configuration, creating more downtime. > > > >Of course not all bridging firewalls are the same, my only bridging > >firewall experience is with the Lucent Managed Firewall or > >BRICK which does both bridging and routing at the same time if need, and > >therefor can be easily deployed in any situation, I > >have not come across a setup that I could not realise. > > > >Greetings, > > > > Diederik Schouten > >_______________________________________________ > >Firewalls mailing list > >[EMAIL PROTECTED] > >http://lists.gnac.net/mailman/listinfo/firewalls > > > --__--__-- > > Message: 3 > Date: Fri, 12 Apr 2002 08:41:17 -0400 (EDT) > From: "Paul D. Robertson" <[EMAIL PROTECTED]> > To: Gary Flynn <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Subject: Re: Cisco IDS > > On Fri, 12 Apr 2002, Gary Flynn wrote: > > > I'm certainly not going to argue with you about other means of > > segmentation being more secure but > > I'm wondering what the actual risk level is. The only vulnerability > > report I've seen requires the > > following conditions: > > > [snip] > > > > Are you aware of any other vulnerabilities or exploits? > > The ability to DoS the internal network if you can make the switch too > busy is the most obvious one- and that can be pretty easy in some > scenerios. > > There've been rumbles of very interesting taged queueing issues > (802.1q) for ~4 years now, I highly doubt the DoS attacks Cisco fixed are > the end of that train. > > I wouldn't put money on either spanning tree or Cisco Discovery Protocol not > having a problem or two even this late in the game (heck SNMP has been > around for ever and the last round of stuff *only* looked at V1 of the > protocol.) > > I'm not sure how the "fill up the CAM table" thing works these days, but I > doubt that the default "broadcast on every port" logic is completely > ripped out of the switch code for each set of things that would ever > trigger it. > > The most important thing though is that a single configuration change > completly and utterly destroys your security posture. Think about the > last few worms which have gotten to internal networks, add a switch > component to the mix and think about how "safe" that architecture is > (disallowing remote access to a DMZ-only switch is pretty easy, internal > switches all tend to have IP addresses and SNMP on these days.) > > One bug, one mistake, one malicious act - mix it with one single point > of failure, and everything's exposed. Hell, a dumb switch for the DMZ is > a *trivial* ammount of money these days. > > Paul > -------------------------------------------------------------------------- --- > Paul D. Robertson "My statements in this message are personal opinions > [EMAIL PROTECTED] which may have no basis whatsoever in fact." > > > --__--__-- > > Message: 4 > Subject: Re: Bridging vs. Routing Firewalls. > To: [EMAIL PROTECTED] > Cc: Diederik Schouten <[EMAIL PROTECTED]>, > Firewalls List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], > "Georges J. JAHCHAN P. Eng." <[EMAIL PROTECTED]> > From: Alexander.O'[EMAIL PROTECTED] > Date: Fri, 12 Apr 2002 15:41:17 +0100 > > > No IP doesn't mean you cant manage the device remotely, what about a > terminal server with a console connection > > Sorry just my 2p worth > > > > > > Clifford Thurber > <cthurber@edisonscho To: Diederik Schouten <[EMAIL PROTECTED]>, "Georges J. JAHCHAN P. > ols.com> Eng." <[EMAIL PROTECTED]> > Sent by: cc: Firewalls List <[EMAIL PROTECTED]> > firewalls-admin@list Subject: Re: Bridging vs. Routing Firewalls. > s.gnac.net > > > 12/04/2002 15:06 > > > > > > > How about the practicality of managing one of these from thousands of miles > > away? No IP means that someone needs to be in physical proximity. > > At 11:09 AM 4/12/2002 +0200, Diederik Schouten wrote: > >Bridging vs Riuting firewalls... > > > > > >The main strength of a bridged firewall to me is the fact that it only > >exists virtually on the network. > >How to attack a firewall that you cannot address directly? > >Even when you are connected to the same network/switch you will not be > >able to find the firewall, unless you know what you are > >looking for. > > > >Implementation wise a bridging/routing firewall offers you a few > >advantages over a routed one. > > > >1. when you have to add the firewall to an already existing network, you > >do not need to reconfigure any other device on the > >network, your addressing schemes and routing stays exactly the same, the > >only downtime you will have is due to the fact that > >you have to connect the cabels. (and even that can be solved by using > >vlan's on your switches and just swapping the upstream > >routers interface into a separate vlan together with the downstream > >interface of the firewall. > > > >- Since you do not need to change your routing topology you do not need to > > >creat more transit subnets, and thus you save IP > >addresses. > >- When changing routing topologies often many devices will have to have > >their configuration changed. With a bridged firewall > >this is not needed. > > > >2. Putting multiple firewalls in series to create for example more ports > >becomes very easy, although for example with the > >Lucent BRICK this isnot necesary since it supports VLAN tagging and with a > > >VLAN capable switch you can create virtually any > >number of "virtual" firewalls you might need, and give them all their own > >ruleset. > >No need for recabling and expensive upgrades. > > > >3. In general purpose build devices are less vulnerable, a purpose build > >firewall does not depend on the operating system of > >the router/platform it is running at, lowering the chance of being > >penetrated due to bugs in code other than for the firewall. > >(as Nokia, Checkpoint, Cisco etc.) > > > >4. When both your routing services and firewall services are based on one > >device, then everytime you need to make changes to > >the routing you will probably also have to change your firewwall > >configuration, creating more downtime. > > > >Of course not all bridging firewalls are the same, my only bridging > >firewall experience is with the Lucent Managed Firewall or > >BRICK which does both bridging and routing at the same time if need, and > >therefor can be easily deployed in any situation, I > >have not come across a setup that I could not realise. > > > >Greetings, > > > > Diederik Schouten > >_______________________________________________ > >Firewalls mailing list > >[EMAIL PROTECTED] > >http://lists.gnac.net/mailman/listinfo/firewalls > > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > http://lists.gnac.net/mailman/listinfo/firewalls > > > > > > --__--__-- > > Message: 5 > From: "Noonan, Wesley" <[EMAIL PROTECTED]> > To: "'Paul D. Robertson'" <[EMAIL PROTECTED]>, > Gary Flynn <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: RE: Cisco IDS > Date: Fri, 12 Apr 2002 09:50:45 -0500 > > > -----Original Message----- > > From: Paul D. Robertson [mailto:[EMAIL PROTECTED]] > > Sent: Friday, April 12, 2002 07:41 > > To: Gary Flynn > > Cc: [EMAIL PROTECTED] > > Subject: Re: Cisco IDS > > > > On Fri, 12 Apr 2002, Gary Flynn wrote: > > > > > I'm certainly not going to argue with you about other means of > > > segmentation being more secure but > > > I'm wondering what the actual risk level is. The only vulnerability > > > report I've seen requires the > > > following conditions: > > > > > [snip] > > > > > > Are you aware of any other vulnerabilities or exploits? > > > > The ability to DoS the internal network if you can make the switch too > > busy is the most obvious one- and that can be pretty easy in some > > scenerios. > > Where is that one? How does one DoS a switch that generally has a >3GB > backplane with traffic that comes from a generally <100MB pipe? > > > There've been rumbles of very interesting taged queueing issues > > (802.1q) for ~4 years now, I highly doubt the DoS attacks Cisco fixed are > > the end of that train. > > Rumbles don't always mean anything. People have been rumbling about how > Linux is the next end all be all for years too. Still not seeing that. > > > I wouldn't put money on either spanning tree or Cisco Discovery Protocol > > not > > having a problem or two even this late in the game (heck SNMP has been > > around for ever and the last round of stuff *only* looked at V1 of the > > protocol.) > > This is a bad jump of logic. The SNMP "stuff" has existed and been *known* > for over 10 years. It's only when a vendor came out with a product to scan > for the vulnerabilities that they suddenly became issues. > > > I'm not sure how the "fill up the CAM table" thing works these days, but I > > doubt that the default "broadcast on every port" logic is completely > > ripped out of the switch code for each set of things that would ever > > trigger it. > > You are making an uninformed statement here. Either it is, or it isn't but > saying "I doubt" isn't really a credible statement in this context. > > > The most important thing though is that a single configuration change > > completly and utterly destroys your security posture. Think about the > > last few worms which have gotten to internal networks, add a switch > > component to the mix and think about how "safe" that architecture is > > (disallowing remote access to a DMZ-only switch is pretty easy, internal > > switches all tend to have IP addresses and SNMP on these days.) > > This is true in separate switch environments. > > > One bug, one mistake, one malicious act - mix it with one single point > > of failure, and everything's exposed. Hell, a dumb switch for the DMZ is > > a *trivial* ammount of money these days. > > No doubt on this point. Heck, a hub in my mind makes an even better > solution. > > Wes Noonan, MCSE/MCT/CCNA/CCDA/NNCSS > Senior QA Rep. > BMC Software, Inc. > (713) 918-2412 > [EMAIL PROTECTED] > http://www.bmc.com > > --__--__-- > > Message: 6 > Date: Fri, 12 Apr 2002 17:10:31 +0200 > From: Diederik Schouten <[EMAIL PROTECTED]> > To: Clifford Thurber <[EMAIL PROTECTED]> > Cc: "Georges J. JAHCHAN P. Eng." <[EMAIL PROTECTED]>, > Firewalls List <[EMAIL PROTECTED]> > Subject: Re: Bridging vs. Routing Firewalls. > > Hello, > > > How about the practicality of managing one of these from thousands of miles away? No IP means that someone needs to be in > physical proximity. > > For management all bridged firewalls are layer3 capable, with the LSMS I currently manage over 200 firewalls in various > countries, no need to be on site. > > Your switches are also manageable on their IP address, correct? They are layer 2 devices. > Same applies for bridged firewalls, it has nothing to do with being layer 3 capable, but with the design of the box, to base > the way packets are handled on the bridging or routing principles. > > Greetings, > > Diederik > > --__--__-- > > Message: 7 > Date: Fri, 12 Apr 2002 11:15:49 -0400 > From: Clifford Thurber <[EMAIL PROTECTED]> > Subject: Re: Bridging vs. Routing Firewalls. > To: Diederik Schouten <[EMAIL PROTECTED]> > Cc: "Georges J. JAHCHAN P. Eng." <[EMAIL PROTECTED]>, > Firewalls List <[EMAIL PROTECTED]> > > So if you assign this firewall a management it is just a susceptible as any > other firewall, so much for being "invisible" ? > > > At 05:10 PM 4/12/2002 +0200, Diederik Schouten wrote: > >Hello, > > > > > How about the practicality of managing one of these from thousands of > > miles away? No IP means that someone needs to be in > >physical proximity. > > > >For management all bridged firewalls are layer3 capable, with the LSMS I > >currently manage over 200 firewalls in various > >countries, no need to be on site. > > > >Your switches are also manageable on their IP address, correct? They are > >layer 2 devices. > >Same applies for bridged firewalls, it has nothing to do with being layer > >3 capable, but with the design of the box, to base > >the way packets are handled on the bridging or routing principles. > > > >Greetings, > > > > Diederik > >_______________________________________________ > >Firewalls mailing list > >[EMAIL PROTECTED] > >http://lists.gnac.net/mailman/listinfo/firewalls > > > --__--__-- > > Message: 8 > Date: Fri, 12 Apr 2002 17:31:16 +0200 > From: Diederik Schouten <[EMAIL PROTECTED]> > To: Clifford Thurber <[EMAIL PROTECTED]> > Cc: "Georges J. JAHCHAN P. Eng." <[EMAIL PROTECTED]>, > Firewalls List <[EMAIL PROTECTED]> > Subject: Re: Bridging vs. Routing Firewalls. > > > So if you assign this firewall a management it is just a susceptible as any other firewall, so much for being "invisible" ? > > No, since it will not show up as a gateway anyware. Traceroutes won't show it is there etc. > > Unless you know it's IP address already you will not be able to find it. > > Routed firewalls will always be detectable, or at least they'll be suspected to be a firewall. > When mapping a network with a bridged firewall the suspection of which device is the firewall will more likely fall upon the > devices in front or behind the firewall, without giving away any hint of the real firewall. > > Diederik > > --__--__-- > > Message: 9 > Date: Fri, 12 Apr 2002 11:49:45 -0400 (EDT) > From: Paul Robertson <[EMAIL PROTECTED]> > To: "Noonan, Wesley" <[EMAIL PROTECTED]> > Cc: Gary Flynn <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > Subject: RE: Cisco IDS > > On Fri, 12 Apr 2002, Noonan, Wesley wrote: > > > > The ability to DoS the internal network if you can make the switch too > > > busy is the most obvious one- and that can be pretty easy in some > > > scenerios. > > > > Where is that one? How does one DoS a switch that generally has a >3GB > > backplane with traffic that comes from a generally <100MB pipe? > > Historically, "strange" 802.1q packets on Cisco switches have worked do > DoS the switch. Historically, forged spanning tree packets have worked to > DoS the switch. I believe there was also an interesting MAC address > attack using the switch's MAC, but I don't recall the details. The > backplane isn't the issue if you can make the CPU too busy to do its job, > especially if doing so places the device into broadcast mode. > > > > There've been rumbles of very interesting taged queueing issues > > > (802.1q) for ~4 years now, I highly doubt the DoS attacks Cisco fixed are > > > the end of that train. > > > > Rumbles don't always mean anything. People have been rumbling about how > > Linux is the next end all be all for years too. Still not seeing that. > > By the same token, rumbles sometimes mean a storm is coming. If you've > some information that gives an assurance that 802.1q issues have been > examined in more significant depth, please present it. > > > > I wouldn't put money on either spanning tree or Cisco Discovery Protocol > > > not > > > having a problem or two even this late in the game (heck SNMP has been > > > around for ever and the last round of stuff *only* looked at V1 of the > > > protocol.) > > > > This is a bad jump of logic. The SNMP "stuff" has existed and been *known* > > for over 10 years. It's only when a vendor came out with a product to scan > > for the vulnerabilities that they suddenly became issues. > > Which doesn't say that the same sort of thing won't happen for CDP (and > the product wasn't from a vendor per-se.) The logic "Vendors who make > switches have had issues with longer-lived protocols than the ones their > switches use as a default to do topology related things, and it will > likely happen again" isn't a bad jump. Please cite an SNMP ASN.1 issue > from 10 years ago. > > > > I'm not sure how the "fill up the CAM table" thing works these days, but I > > > doubt that the default "broadcast on every port" logic is completely > > > ripped out of the switch code for each set of things that would ever > > > trigger it. > > > > You are making an uninformed statement here. Either it is, or it isn't but > > saying "I doubt" isn't really a credible statement in this context. > > The FACT stands that switches have traditionally had failure modes that > resulted in every packet going out of every port (historically, for Cisco > the easiest of those was filling up the CAM table- there have been > others and Cisco isn't the only vendor.) Absent evidence that > such failure modes have been changed due to the proliferation of VLANs on > switches, there exists doubt. Your evaluation of the credibility of the > statement is neither here nor there in regards to how it is offered. > Since I SAID "I'm not sure...," it's obviously not completely informed- > which is WHY I said it that way- sheesh. > > > > The most important thing though is that a single configuration change > > > completly and utterly destroys your security posture. Think about the > > > last few worms which have gotten to internal networks, add a switch > > > component to the mix and think about how "safe" that architecture is > > > (disallowing remote access to a DMZ-only switch is pretty easy, internal > > > switches all tend to have IP addresses and SNMP on these days.) > > > > This is true in separate switch environments. > > It is *sometimes* true, however it is possible to engineer multiple switch > environments where this isn't the case, *and* in a multiple switch > enviornment, unless you're creating one big logical switch by hooking them > directly together, there's a layer 3 device in the middle that will likely > have more security attention paid to it (in the specific example in this > thread it was a PIX) than the switch generally gets- especially when the > switch's maintenance is dictated by any issues on the internal network. > > Paul > -------------------------------------------------------------------------- --- > Paul D. Robertson "My statements in this message are personal opinions > [EMAIL PROTECTED] which may have no basis whatsoever in fact." > > > > --__--__-- > > _______________________________________________ > 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
