Re: [c-nsp] ASA Firewalls placement in the network!
On Oct 10, 2009, at 10:06 AM, Brian Johnson wrote: So are you actually saying that DPI is a bad thing relative to server protection? What makes this a bad idea? In what way does it make them more vulnerable to attacks? DPI firewalls. My experience with crafted packet attacks (being attacked, not attacking others :P) tells me that this is a good layer of protection. Concur. Again, it has nothing to do with stateful firewalls. sarcasm What Arbor product would you like to sell me to accomplish this type of protection?/sarcasm I publicly held this position when I worked for the world's largest vendor of stateful firewalls. My position was based upon operational experience then, as now. In this threat, I stated that enforcing policy should be handled by stateless ACLs in hardware. Arbor Networks doesn't make routers. Not trying to be snide here (at least not anymore ;P), but I doubt that the majority of CFOs would be fine leaving their servers behind simple ACLs. I would never do that That's because you, like your hypothetical CFOs, obviously have no experience running large-scale public-facing Internet properties. Any large-scale, publicly-visible Web site you can name doesn't have stateful firewalls in front of its servers. For a server like a DNS server, a Web server, and so forth, every connection which comes into said server is by definition unsolicited. So, the entire purpose of stateful inspection in front of such servers is moot. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA Firewalls placement in the network!
On Oct 10, 2009, at 3:17 AM, nick hatch wrote: Are you saying that Arbor networks is misguided about their server protection devices, Roland? My position on this subject, based on hands-on operational experience, was the same when I worked for the world's largest vendor of stateful firewalls as it is now - namely, that policy enforcement for servers should be handled by stateless ACLs on hardware-based routers, *not* by stateful firewalls, because it makes no sense to put a stateful inspection firewall in front of Web servers, DNS servers, et. al., as *by definition*, every connection said servers receive is unsolicited, and therefore simply not a candidate for stateful inspection in the first place. Note that my employer, Arbor Networks doesn't make routers of any type, nor indeed any sort of policy-enforcement device at all; that's not what we do. Our TMS does in fact protect firewalls and everything behind them from DDoS; we've many customers who use them for this purpose. So, as you see, I've no pecuniary interest whatsoever in stating that it makes no sense to put stateful firewalls in front of servers, as it makes not one whit of difference to us - in fact, given the propensity of firewalls to collapse under DDoS, one could say *quite the opposite*. My purpose in stating that firewalls have no place in front of servers was meant to be educational in nature, nothing more. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA Firewalls placement in the network!
On Oct 10, 2009, at 4:05 PM, Roland Dobbins wrote: nor indeed any sort of policy-enforcement device at all This should read ' . . . any sort of server-oriented policy- enforcement device at all . . .', apologies for the typo. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SUP720 - 12.2(18)SXF17
On Fri, Oct 09, 2009 at 09:16:27AM -0400, Jared Mauch wrote: I think it's important to note that there are similar limiters in other devices, eg: Juniper m20/m40 that we've encountered over the years. This has caused customer confusion as they hit these, even in a fully distributed linecard environment. The reality is unless it's done in a low-level ASIC, it can easily turn into a security vulnerability. Drop 5 gigs of ttl=1 traffic at a device and it will fall over unless there is some protection. It may not even need to be as high as 5g. There are a lot of rate-limiters available, check out 'show mls rate- limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low to avoid problems. I find 100/10 works well. Juniper has some extremely low arbitrary hard-coded limits built in, as low as 50pps per FPC on M20/M40 type cards. Even on higher end boxes it's not much better, hardcoded at 250 or 500pps per FPC for 40g/slot cards. It only takes a couple of people on the internet running mtr to destroy those rate-limits and completely break your traceroute, to say nothing of what happens when you get a TTL expiring DoS or someone creates a forwarding loop. We routinely bump these limits, nearly 24/7 on some routers, which only serves to confuse/annoy customers (and other random people on the Internet who somehow managed to work a phone or email to complain about what you're doing to their gamer score). I can't even imagine configuring a 100/10 rate-limiter, it would get destroyed on any network with any amount of traceroute going through it. At least Cisco doesn't have those silly hard-coded limits, but on the other hand since the TTL expiration handling isn't distributed I'm sure it doesn't work out much better than a 500pps per FPC rate-limiter anyways. Some days I would pay good money for a traceroute handling ASIC, or at least some primitives for it in some microcode somewhere, so it isn't at the mercy of BGP scanner, someone running a complex sh ip bgp on the cli, or any random kid capable of generating 500pps. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SUP720 - 12.2(18)SXF17
On 2009-10-10 13:35, Richard A Steenbergen wrote: Some days I would pay good money for a traceroute handling ASIC, or at least some primitives for it in some microcode somewhere, so it isn't at the mercy of BGP scanner, someone running a complex sh ip bgp on the cli, or any random kid capable of generating 500pps. Then look no more :) Actually, the Sup6E is supposed to have the TTL expired and other stuff (including IP Options) support built in into the IPP ASIC (the one that handles all IP traffic). Unfortunately, Sup6E in Cat4500 or 4900M which is based on that is hardly a core router. However, there's sign that those things go into the ASICs with time. Next generation of hardware will propably have it also if that's already cheap enough to fit into generally orderable products. And yes, I agree, that CoPP or whatever-you-call-it should be always tuneable, to not bounce off some artificial limits that are not visible at the first, second and third look into the design. -- Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco Layer 3 and Giga
Arie Vayner (avayner) wrote: I would recommend that you take a look at the 4948 switches. They could be a good choice for small routing devices. Be aware that there is a relatively low limit for the number of routes they can support. No hardware IPv6 support. You shouldn't be buying hardware which doesn't do IPv6 properly now unless you are sure you won't have to replace it. 4948 is SupIV, so no IPv6. 4900M is Sup6E, so has hardware IPv6. You could also consider the 6524, or look at offerings from other vendors, as Cisco's product line is a bit rubbish in this space. adam. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Hidiing a traceroute
Dear All, I want to hide a traceroute hops inside my network i know you can hide the traceroute inside an MPLS network can we hide also the traceroute inside an IP network Thanks In advance Regards Jason CCIE#24775 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Hidiing a traceroute
On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex amr.c...@gmail.com wrote: Dear All, I want to hide a traceroute hops inside my network i know you can hide the traceroute inside an MPLS network can we hide also the traceroute inside an IP network Thanks In advance Regards Jason CCIE#24775 An MPLS network hides the network hops because as far as the packet is concerned, the MPLS network is a tunnel with no router hops. To hide a traceroute inside a L3 network, you need to block ICMP TTL-expired messages from the hops you want to hide. However, the hops will still be visible since every router decrements the TTL by one, and the traceroute source will notice it is missing TTL-expired messages from your hidden hops. Hector ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Hidiing a traceroute
Not so accurate, in an MPLS network you can disable the process which copies the IP TTL from the header to the label and vice verse. By doing that you are hiding the MPLS core routers from a traceroute operation. As for an IP network you can either discard or drop an ICMP type 8 (echo request) And by that block the traceroute operation, The user will get asterisks marks instead of the IP of the router. MTC. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hector Herrera Sent: Saturday, October 10, 2009 9:55 PM To: Jason Alex Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Hidiing a traceroute On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex amr.c...@gmail.com wrote: Dear All, I want to hide a traceroute hops inside my network i know you can hide the traceroute inside an MPLS network can we hide also the traceroute inside an IP network Thanks In advance Regards Jason CCIE#24775 An MPLS network hides the network hops because as far as the packet is concerned, the MPLS network is a tunnel with no router hops. To hide a traceroute inside a L3 network, you need to block ICMP TTL-expired messages from the hops you want to hide. However, the hops will still be visible since every router decrements the TTL by one, and the traceroute source will notice it is missing TTL-expired messages from your hidden hops. Hector ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Hidiing a traceroute
http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1013846 Not so accurate, in an MPLS network you can disable the process which copies the IP TTL from the header to the label and vice verse. By doing that you are hiding the MPLS core routers from a traceroute operation. As for an IP network you can either discard or drop an ICMP type 8 (echo request) And by that block the traceroute operation, The user will get asterisks marks instead of the IP of the router. MTC. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hector Herrera Sent: Saturday, October 10, 2009 9:55 PM To: Jason Alex Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Hidiing a traceroute On Sat, Oct 10, 2009 at 12:21 PM, Jason Alex amr.c...@gmail.com wrote: Dear All, I want to hide a traceroute hops inside my network i know you can hide the traceroute inside an MPLS network can we hide also the traceroute inside an IP network Thanks In advance Regards Jason CCIE#24775 An MPLS network hides the network hops because as far as the packet is concerned, the MPLS network is a tunnel with no router hops. To hide a traceroute inside a L3 network, you need to block ICMP TTL-expired messages from the hops you want to hide. However, the hops will still be visible since every router decrements the TTL by one, and the traceroute source will notice it is missing TTL-expired messages from your hidden hops. Hector ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.9/2427 - Release Date: 10/10/09 06:39:00 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
