[c-nsp] GEIP+ Prices
Why do GEIP+ cards go for so much money? There can't be *that* many people left on the 7500 platform... Peace... Sridhar ___ 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] MLS QoS 6500/7600
On 12/10/2009 05:20, Mark Tinka wrote: increasing bandwidth is probably more practical than implementing QoS or as some wags state differently: QoS really means quantity of service, because quality of service only ever becomes an issue if there is a shortage of quantity. /me runs and hides nick ___ 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] GEIP+ Prices
On Mon, Oct 12, 2009 at 06:04:35AM -0400, Sridhar Ayengar wrote: Why do GEIP+ cards go for so much money? There can't be *that* many people left on the 7500 platform... Because anyone still in the market for GEIP+ must be very very desperate? :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ 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] Unable To Use T3 Card (PA-MC-2T3-EC)
Gert Doering wrote: I am currently running (C7200P-SPSERVICESK9-M), Version 12.4(4)XD10 ... it might be that this software just doesn't know about this specific PA (which is very new, and anything based on 12.4(4) is a few years old now regarding hardware support). C7200P smells like NPE-G2, so you don't have that many options - I'm no NPE-G2 expert, but I think all you *can* use is 12.4T or 12.2SR - so I'd pick a recent one of either IOS versions and try that. Or go for 15.0(1)M, which might or might not be less bugged than 12.4(max)T. I agree. Dominic is running a code train that was put out just for the initial release of the NPE-G2. He's running a code train that's slated for death essentially and should move into a regular train such as 12.4 mainline, 12.4T or 12.2SR since G2 support has been rolled into them. I haven't yet loaded 15.0 on a G2 but I am running on one on 24T1 and that box has a PA-MC-2T3-EC in it. It of course has the NTP bug (and several others) that require 24T2 or 15.0 to fix. 12.4T has been fairly stable for me though. Justin ___ 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] GEIP+ Prices
On Mon, 12 Oct 2009, Sridhar Ayengar wrote: Why do GEIP+ cards go for so much money? There can't be *that* many people left on the 7500 platform... They are around 1kUSD on ebay, considering just the PA-GE goes for 800, I don't think that's expensive? They're actually increasing in price, the GEIP (not +) was 600 USD a year ago, now they seem to not be available even close to that price. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] GEIP+ Prices
On Mon, 12 Oct 2009, Mikael Abrahamsson wrote: On Mon, 12 Oct 2009, Sridhar Ayengar wrote: Why do GEIP+ cards go for so much money? There can't be *that* many people left on the 7500 platform... They are around 1kUSD on ebay, considering just the PA-GE goes for 800, I don't think that's expensive? They're actually increasing in price, the GEIP (not +) was 600 USD a year ago, now they seem to not be available even close to that price. Maybe not a whole lot were sold new, so there's limited supply. You do realize it talks GE, but can't actually do anywhere close to line rate? i.e. are you sure you really want one and it'll do what you need? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Shape traffic on 6500
I'm trying to limit traffic to certain ports of a 6500 switch. By reading manuals and posts to this list I came up with: Global: access-list 100 permit ip any any ! class-map m100 match access-group 100 ! policy-map p100 class m100 shape average 32000 This all looks fine. But when I apply this policy to an interface with: int gi3/1 service-policy input p100 the switch complains with shape average command is not supported for this interface Configuration failed! When I replace the 'shape' command with a 'police': police 32000conform-action transmit exceed-action drop the configuration is accepted Shaping looks nicer, as it does not drop packets, but delays them, having TCP better adapt to the bandwith. Any comments on this? What interfaces have the 'shape average' command supported? The manuals are very non-helpful on this, as they say 'This command is supported in the IOS 12.2SX train. Support in a specific 12.2SX release depends on your feature set, platform and platform hardware. No table of what is supported on what... Used hardware for my test config is: 6509 chassis, sup720 (WS-SUP720-3BXL), interfaces on WS-X6748-GE-TX board with Distributed Forwarding Card WS-F6700-DFC3A IOS 12.2(33)SXH2a ADVANCED ENTERPRISE SERVICES (s72033-advipservicesk9_wan-mz.122-33.SXH2a.bin) Anyone who can shine some light on this?? --maarten -- --- Maarten Carels XS4ALL Internet ___ 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] Shape traffic on 6500
On Mon, 12 Oct 2009, Maarten Carels wrote: Any comments on this? What interfaces have the 'shape average' command supported? The expensive ones. The cheap LAN interfaces generally do not support shaping because they don't have much buffering and are built to be cheap, thus limited support for a lot of the more advanced stuff. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Shape traffic on 6500
-Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Mikael Abrahamsson Sent: 12 October 2009 14:57 To: Maarten Carels Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Shape traffic on 6500 On Mon, 12 Oct 2009, Maarten Carels wrote: Any comments on this? What interfaces have the 'shape average' command supported? The expensive ones. The cheap LAN interfaces generally do not support shaping because they don't have much buffering and are built to be cheap, thus limited support for a lot of the more advanced stuff. [Ian MacKinnon] From http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801c8c4b.shtml :- The PFC3 supports both ingress and egress policing. Traffic shaping is only supported on certain WAN modules for the Catalyst 6500/7600 series, such as the Optical Services Modules (OSMs) and FlexWAN modules. Refer to the Cisco 7600 Series Router Module Configuration Notes for more information -- 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 sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ 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!
Ge Moua wrote: The worst thing you can do is put a stateful firewall in front of a busy DNS server - every single packet creating new state will bring most hardware-based firewalls to their knees, because session churn is usually handled at much lower packet rate as pure packet throughput for existing state... I concur and have battle scar to attest for this; we tried to put a stateful firewall in front of our public NTP server (which also happen to be our DNS servers) and the firewall tipped over within 5 minutes; state tables got exhausted quick. Is there a way to disable sessions for specific port or IP ? -- Best regards, Adrian Minta ___ 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!
Well, the point of a well-maintained server is that it is *open* to the world - if you want a web server to be visible by the world, then there isn't much you can do, besides open HTTP to it. And other services should not be running in the first place. Agree. Focusing server resource on its public service and remove all unnecessary should be first consideration other than putting in another box. The worst thing you can do is put a stateful firewall in front of a busy DNS server Yes. We do suffer from such solution years ago. At that time, when incoming request increases the firewall we use reaches its threshhold quickly and reject new ones. Now, we just connect DNS servers to cisco 6509 directly, ACL on interface protects server very well. On the other hand, tuning DNS server performance is relatively easily than application servers. But, it seems there needs new technology or method on detecting and controling abnormal incoming requests. Months ago, failure of primary DNS server for baofeng.com causes ISP cache server out of resource because too many clients resolve that domain recursively. Joe ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ ___ 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!
I have to agree here, good solid server administration and best practices are far superior to placing hardware in front to do your job for you. (Microsoft, are you listening?) The services running should be the bare minimum, should have their own internal ACLs properly configured (think SSH as an example) and the internal facility such as IPChains or IPF what ever should be used after the services are squared away. This is an art that seems lost on a lot of administrators.:( - Original Message - From: Joe Shen sj_h...@yahoo.com.cn To: Brian Johnson bjohn...@drtel.com; Gert Doering g...@greenie.muc.de Cc: Cisco-nsp cisco-nsp@puck.nether.net Sent: Monday, October 12, 2009 7:46 AM Subject: Re: [c-nsp] ASA Firewalls placement in the network! Well, the point of a well-maintained server is that it is *open* to the world - if you want a web server to be visible by the world, then there isn't much you can do, besides open HTTP to it. And other services should not be running in the first place. Agree. Focusing server resource on its public service and remove all unnecessary should be first consideration other than putting in another box. The worst thing you can do is put a stateful firewall in front of a busy DNS server Yes. We do suffer from such solution years ago. At that time, when incoming request increases the firewall we use reaches its threshhold quickly and reject new ones. Now, we just connect DNS servers to cisco 6509 directly, ACL on interface protects server very well. On the other hand, tuning DNS server performance is relatively easily than application servers. But, it seems there needs new technology or method on detecting and controling abnormal incoming requests. Months ago, failure of primary DNS server for baofeng.com causes ISP cache server out of resource because too many clients resolve that domain recursively. Joe ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ ___ 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/
Re: [c-nsp] ASA Firewalls placement in the network!
yes, but the whole point of public NTP services is to allow any IPv4 to do NTP sync. Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Adrian Minta wrote: Ge Moua wrote: The worst thing you can do is put a stateful firewall in front of a busy DNS server - every single packet creating new state will bring most hardware-based firewalls to their knees, because session churn is usually handled at much lower packet rate as pure packet throughput for existing state... I concur and have battle scar to attest for this; we tried to put a stateful firewall in front of our public NTP server (which also happen to be our DNS servers) and the firewall tipped over within 5 minutes; state tables got exhausted quick. Is there a way to disable sessions for specific port or IP ? ___ 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!
Joel M Snyder - If you do the job right, from a security point of view, you can certainly put a fine firewall in front of a very busy DNS server. (and when I say very busy I'm talking 10K queries a second, which is to say about 20Mbit/second sustained round-the-clock load, for less than $10K) what you recommend for this? Some of my colleague have suggested a redundant open-bsd cluster (with plenty of RAM b/c memory is cheap these days) with PF; I can see a scalable home grown solution that can address the exhausted state table issue; I'm just wondering if cheap fast CPU will be on par (performance and throughput wise) with fast ASIC like the big box vendor uses on their firewall products. What do you think? Regards, Ge Moua | Email: moua0...@umn.edu Network Design Engineer University of Minnesota | Networking Telecommunications Services Joel M Snyder wrote: The worst thing you can do is put a stateful firewall in front of a busy DNS server Well, as a security guy (rather than as a network guy), I would respectfully disagree. First of all, if your firewall is underspecified or underrated, then yes, you'll have problems. Secondly, if your firewall is misconfigured or mistuned, then yes, you'll have problems. Of course, both of these things are true of the network itself as everyone on this list knows very well. If you do the job right, from a security point of view, you can certainly put a fine firewall in front of a very busy DNS server. (and when I say very busy I'm talking 10K queries a second, which is to say about 20Mbit/second sustained round-the-clock load, for less than $10K) So then the question comes: well, what's the point? I think that a lot of the folks on this list feel that throwing an ACL in front of a box is effectively the same, from a security point of view, as a firewall and a hell of a lot cheaper. If you have a lousy firewall (i.e., one that is doing nothing more than keeping a UDP session open), yes, absolutely. However, good firewalls are doing a lot more than that. You may remember last year's the Internet is falling and only Dan Kaminsky can explain it flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly, by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). Similarly, a well-configured firewall would have per-IP rate limits in it, which would have been a second line of defense. Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. But if you do it right, there is value to be provided by a firewall. jms ___ 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-nsp Digest, Vol 83, Issue 39
The worst thing you can do is put a stateful firewall in front of a busy DNS server Well, as a security guy (rather than as a network guy), I would respectfully disagree. First of all, if your firewall is underspecified or underrated, then yes, you'll have problems. Secondly, if your firewall is misconfigured or mistuned, then yes, you'll have problems. Of course, both of these things are true of the network itself as everyone on this list knows very well. If you do the job right, from a security point of view, you can certainly put a fine firewall in front of a very busy DNS server. (and when I say very busy I'm talking 10K queries a second, which is to say about 20Mbit/second sustained round-the-clock load, for less than $10K) So then the question comes: well, what's the point? I think that a lot of the folks on this list feel that throwing an ACL in front of a box is effectively the same, from a security point of view, as a firewall and a hell of a lot cheaper. If you have a lousy firewall (i.e., one that is doing nothing more than keeping a UDP session open), yes, absolutely. However, good firewalls are doing a lot more than that. You may remember last year's the Internet is falling and only Dan Kaminsky can explain it flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly, by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). Similarly, a well-configured firewall would have per-IP rate limits in it, which would have been a second line of defense. Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. But if you do it right, there is value to be provided by a firewall. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms ___ 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] 7206VXR NPE for ~1000 RBE interfaces
An NPE400 should do fine if you're looking used or on a tight budget, but if you're looking to buy for growth, just get a G2 and be done with it. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Querubin Sent: Sunday, October 11, 2009 5:27 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces I'm researching upgrading a 7206VXR to handle about 1000 RBE interfaces off of either 2 T3 or 1 OC3 ATM line. Anybody got any recommendations on which NPE would handle this scenario? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.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/ ___ 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-nsp Digest, Vol 83, Issue 39
If you have a lousy firewall (i.e., one that is doing nothing more than keeping a UDP session open), yes, absolutely. However, good firewalls are doing a lot more than that. Some of us have seen too much damage done by firewalls to DNS, SMTP and a number of other protocols to really believe in this. Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. It would seem that the piece-o-crap firewalls vastly outnumber the good firewalls. See, for instance, the discussions on various DNS lists about firewalls and EDNS0. But if you do it right, there is value to be provided by a firewall. In some circumstances, agreed. For DNS servers (whether recursive or authoritative), absolutely not. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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-nsp Digest, Vol 83, Issue 39
And further more, why inject more points of failure for little to no value? Everything listed in the OP's message that he considers good things about firewalls in front can be done with a properly administered server and good patching habbits. Firewalls have their places but generally not in the front of DNS servers or servers in general. (Anything Microsoft could be an exception to this) As long as you're running a real OS and have decent to good clue firewalls are extra and offer almost nothing. Thank you Scott - Original Message - From: sth...@nethelp.no To: joel.sny...@opus1.com Cc: g...@greenie.muc.de; cisco-nsp@puck.nether.net Sent: Monday, October 12, 2009 12:37 PM Subject: Re: [c-nsp] cisco-nsp Digest, Vol 83, Issue 39 If you have a lousy firewall (i.e., one that is doing nothing more than keeping a UDP session open), yes, absolutely. However, good firewalls are doing a lot more than that. Some of us have seen too much damage done by firewalls to DNS, SMTP and a number of other protocols to really believe in this. Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. It would seem that the piece-o-crap firewalls vastly outnumber the good firewalls. See, for instance, the discussions on various DNS lists about firewalls and EDNS0. But if you do it right, there is value to be provided by a firewall. In some circumstances, agreed. For DNS servers (whether recursive or authoritative), absolutely not. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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/
Re: [c-nsp] Firewalls in front of Internet servers (was: cisco-nsp Digest, Vol 83, Issue 39)
On Mon, 2009-10-12 at 09:19 -0700, Joel M Snyder wrote: You may remember last year's the Internet is falling and only Dan Kaminsky can explain it flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly, by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). The Kaminsky attack only makes sense towards recursive resolvers, and I think most posters here are thinking about authoritative Internet facing nameservers. Who runs a recursive nameserver open towards the Internet now adays? Even so: The nameservers make outbound requests and for those it sort of does make sense to have stateful inspection. Except AFAIK the Kaminsky attack works with spoofed answers, i.e. spoofing both source IP and ports and query ID. How would a firewall (including DPI) catch this? By randomizing source ports or query IDs like TCP sequence number randomization? I'm not sure I agree that's a good idea. By denying all but one answers? Perfect way to DoS yourself. Similarly, a well-configured firewall would have per-IP rate limits in it, which would have been a second line of defense. Um... wouldn't that just make a DoS attempt even easier for an attacker? Now, if you put in a piece-o-crap firewall that is misconfigured, too slow, doesn't have a big enough session table, and doesn't do anything more than your average reflexive access control list, then you're right on: rip that junk out and go bareback. But if you do it right, there is value to be provided by a firewall. As always, costs are important. Why should I spend $$$ for a large enough firewall that doesn't give me any extra value? -- Peter ___ 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] filtering IPV6 for L2 bridged traffic ?
I am running SXI code on sup720-CXL and need to filter out certain IPV6 packets like MDNS on trunked L2 port? I was going to use an vlan access-map but it appears that it does not allow me to do a MATCH on an IPV6 acl, I guess I am stuck with a MAC ACL to filter bridged IPV6 traffic. Any ideas on this issue? How else can it be done? Thanks in advance Jeff Fitzwater OIT Network Systems Princeton University ___ 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-nsp Digest, Vol 83, Issue 39
However, good firewalls are doing a lot more than that. You may remember last year's the Internet is falling and only Dan Kaminsky can explain it flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly As I read it, the discussion here was a public/authoritative name server. The only thing those servers would have seen from the attack is backscatter. by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). Which product's 'deep packet smarts' catch a duplicate transaction ID? For that matter, does anyone know of a breakdown of _actual_ protocol analysis applied by different products? The few I've poked at fail to catch many deviations of well-formed and common protocols. Egress traffic -- firewall to death (especially if you can offload heavy lifting to a full ALG), but inbound is much more effectively addressed by application / server administration with a tight ingress and egress ACL. But if you do it right, there is value to be provided by a firewall. Similarly, a well-configured firewall would have per-IP rate limits in it, which would have been a second line of defense. ...and now we're back to Arbor, which get this w/o being in the forwarding path. That said, there are lots of places where I'd love to be able to apply QoS policies on a per-address (rather than per-flow or per-acl) basis both for security and performance motivations. ___ 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] About WAAS and File Sharing
Hi Guys, I'm testing WAAS performance with sharing Word and pdf files, and it is working as I expected. But when I share an *.exe file or *.bin file the result is not the same. I can't see any improvement. Please help me to understand that. Waas works nice with data files (word, power point, pdf, txt, etc) and not with *.bin or *.exe files? Thanks a lot guys David ___ 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] Firewalls in front of Internet servers
Peter Rathlev wrote: On Mon, 2009-10-12 at 09:19 -0700, Joel M Snyder wrote: You may remember last year's the Internet is falling and only Dan Kaminsky can explain it flap around DNS. Well, a lot of the discussion around this bug/problem/issue ignored the truth that a good firewall prevented the attack directly, by knowing enough 'deep packet smarts' around the DNS protocol that the attack scenario was effectively blocked (hey, that's why we have a session table in the first place!). The Kaminsky attack only makes sense towards recursive resolvers, and I think most posters here are thinking about authoritative Internet facing nameservers. Who runs a recursive nameserver open towards the Internet now adays? Well, if nowadays is the day before the Kaminsky press... then I'd say all kinds of people. Including prominent NANOG contributors. I suspect most of those folks have cleaned up their acts since then, but I have learned never to be surprised at the level of security as actually deployed. And I don't even have a seat-of-the-pants number to throw out, but I'd bet that you'd be surprised if you did a little survey at how many recursive resolvers are reachable from the general purpose Internet. Even so: The nameservers make outbound requests and for those it sort of does make sense to have stateful inspection. Except AFAIK the Kaminsky attack works with spoofed answers, i.e. spoofing both source IP and ports and query ID. How would a firewall (including DPI) catch this? By randomizing source ports or query IDs like TCP sequence number randomization? I'm not sure I agree that's a good idea. By denying all but one answers? Perfect way to DoS yourself. I don't see that as a DoS issue. Let's say that the firewall has an idea that a DNS query should have only one answer (which would be correct). If you start to get multiple answers for each query, then wouldn't that be something you'd want to know about? We're not talking about port scanning here; we're talking about clearly broken behavior--either a broken DNS server which is multi-replying to queries or some third party trying to inject bad juju. Yes, it turns out that almost anything the security people put in place can be used by a malicious attacker to create a DoS. For example, if I know you have a deleted brand firewall, I can send a medium-size ZIP files, better double-ZIPped (more is suspicious), through the firewall with email and watch those little files have an impact equal to 10x their normal bandwidth. Even if you have NO security hardware in place, by knowing your routing infrastructure and desire to patch, I can cause DoS attacks with crafty choice of traffic designed to either cause disproportionate load or, even better, a nice reload every once in a while. Yes, I'll acknowledge that the security hardware is MUCH more susceptible to this kind of attack. I was in the lab a few months ago with a massive IPS from deleted and accidentally chose the wrong port to send throughput test traffic on, and watched that box go from 40Gbps to about 2Gbps. Now, maybe this is NANOG and ISPs operate in a 'we're just a utility company; you buy your own water softener or surge suppressor' mindset. But a lot of the thinking that goes into engineering large ISP networks is applicable to large enterprise networks, and vice versa. I see organizations in the carrier business who a few years ago would never dream of anything but the lightest of ACLs across their infrastructure now investing in big firewalls and other tools to provide security. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms ___ 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] Firewalls in front of Internet servers
Sorry: Now, maybe this is NANOG and ISPs operate in a 'we're just a utility Meant maybe this is cisco NSP ... Apologies for the obvious stupid error. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms ___ 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] Cisco routers can do more than just route...
Everyone wants a piece of the Linux action http://www.h-online.com/security/Cisco-routers-can-do-more-than-just-route--/news/114437 ___ 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/
