[c-nsp] Cisco Security Advisory: Cisco Secure Access Control System SQL Injection Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Secure Access Control System SQL Injection Vulnerability Advisory ID: cisco-sa-20150211-csacs http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150211-csacs Revision 1.0 For Public Release 2015 February 11 16:00 UTC (GMT) +- Summary === Cisco Secure Access Control System (ACS) prior to version 5.5 patch 7 is vulnerable to a SQL injection attack in the ACS View reporting interface pages. A successful attack could allow an authenticated, remote attacker to access and modify information such as RADIUS accounting records stored in one of the ACS View databases or to access information in the underlying file system. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150211-csacs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (SunOS) iQIVAwUBVNtpuopI1I6i1Mx3AQJ6/A/+JIKuQxiLmALGpAfX04MpmVAEQy5lntFb 4zNxT0JxqOXzXjYaGBC+8e/Ld0SXUi4sCuewQEXHTeEBSEQfyyGjk9tnjmSaMy6z Qp7lAB/6qZEFHnVLbwhCoAAQiYheIk18jt7fdZM6jJ4sW8mjUx6LmIcPgdURDyQT bZ8lTvmQNF6c/lBtIdbhxfMjOJYz1i5L5bjM0NrO0HH80jfgD7hYeNO0olROwo9D ICDRz5w07UQ949/YRLG901UAIOs0Cyodnwy44ERJ3iH0bglvFIdeGyFlfzs0wnpT /3XiAOJPnun9Uc6HZBbpgb1Y9ojITaxaT+OzOqi0CWG8rRqKyh1i+pO6ucmq3feE h85uBW2T0cRemgf8zMNI+fH1lLgnhCZ32gxVsOnzreSET11kcecAFkAVWmYwo4sL PornqaV3tRJDXpAsBVceMfGIhPz8GvFii8ZqaGaF+tCl7KuRtiXYeCOdVWHZMPie vtfYgB2il/KpB6fy9tGpQ3YmBl3n+T3oOawdIAdMuxhHYm9owZIfk7K9VC2xCbY8 96xhmJFsOZErdP1vlc4HHgUeJGWhzNvdBiPUF+V1JcdqGldA7/92SmXigbDh8Lr/ spMQBnLhuyqV7ghL6zx5HLhlwOH2Ub3dS26Fxm2GeUa1fcAIgd4ME58hSt+T3J2l pJXLh5SWb0w= =KXWL -END PGP SIGNATURE- ___ 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] Storm-Control
Hi I am configuring storm-control for broadcast and multicast traffic The service is affected even on the unicast frames If thats the case, its obviously not expected behavior. I don't have any issues with storm-control on my ME3400 boxes though. ___ 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
Maybe this is a semantics thing, but isn't implicit rule of 'allow to any less secure interface' replaced by an implicit deny once you apply an inbound access-list to an interface? To some people that might be considered negating the security level of the interface (since the security level doesn't really do anything anymore). Once you have inbound ACLs everywhere you may as well not even have security levels.Hopefully today will be the day I learn there's a knob to turn that implicit deny into an implicit allow-to-less-secure which will make me regret all those hours spent tuning DMZ inbound access-lists. On Wed, Feb 11, 2015 at 8:57 AM, David White, Jr. (dwhitejr) dwhit...@cisco.com wrote: On 2/11/2015 7:29 AM, Joshua Riesenweber wrote: This has a few good examples:http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_extended.html I might very well be wrong, but I believe the security levels are negated if an access list is applied to an interface. That is incorrect. Security levels are not negated or affected by applying an ACL (or not) to an interface. Sincerely, David. Cheers,Josh Date: Wed, 11 Feb 2015 20:43:37 +1100 From: dale.shaw+cisco-...@gmail.com To: madu...@gmail.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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/ ___ 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] ibgp on 6509 with sup2?
Hi, On Wed, Feb 11, 2015 at 10:45:44AM -0800, Joe Pruett wrote: If I remember right, Sup2 had 256k FIB, going to half that if you enable uRPF. So if you set your iBGP-sessions to max-prefix 23 (or 115000), and then experiment with feeding it more and more routes, you should be fairly safe... my reading of max-prefix doesn't make it very useful. either you reset the session after hitting the max, or you just log a warning and then continue accepting prefixes. i'll just be very stingy with my export to begin with and see how things go. Well, you reset it, to avoid the 6509 falling over. It will burn CPU cycles, and fall back to the default route, but it will *not die*... [..] oh, and i run full ipv6 as well, just to make it interesting. Sup2 and IPv6 is software forwarding, so that might be some reason to upgrade eventually... so far my cpu is not breathing hard, and i run a routed vlan (with software shaping) for every port. but, overall routed traffic is under 100mb. even my layer 2 traffic rarely makes the little bar graph on the sup2 card flicker. i'm hoping i have years left on this setup. if the ibgp pushes things too hard, i'll just live with the inefficient traffic. 6500s never die, they just retire one day when you want more shiny things :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpVoBmixfnuJ.pgp Description: PGP signature ___ 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] ibgp on 6509 with sup2?
On Wed, Feb 11, 2015 at 10:45 AM, Joe Pruett j...@spiretech.com wrote: my reading of max-prefix doesn't make it very useful. either you reset the session after hitting the max, or you just log a warning and then continue accepting prefixes. i'll just be very stingy with my export to begin with and see how things go. It's there as a safety valve, to prevent the boiler from exploding, not as a normally used tool to protect from a few bad routes. The alternative is you exhaust fib space, the 6500 proceeds to forward in software, and likely hard crashes due to the load. Even if it doesn't hard crash, until recent software it required a hard reset to resolve the exhaust condition even if the route count receded back to manageable levels. Personally, I'd take the session loss over network self destruction, but YMMV. -Blake ___ 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] ibgp on 6509 with sup2?
On 02/11/2015 09:56 AM, Gert Doering wrote: Hi, On Tue, Feb 10, 2015 at 03:42:23PM -0800, Joe Pruett wrote: with bgp filtering might i be able to install just routes of /20 or shorter (hoping that is a small enough number of routes). or would bgp still consume all the routes before it filters and thus run out of ram? i'd don't think i want to experiment with this in production :-). The easiest way is to filter on *export* from the 7200s, so the 6509 has no chance to see the refused routes at all :-) yep, i realized that i should control export after i got some other off list responses. If I remember right, Sup2 had 256k FIB, going to half that if you enable uRPF. So if you set your iBGP-sessions to max-prefix 23 (or 115000), and then experiment with feeding it more and more routes, you should be fairly safe... my reading of max-prefix doesn't make it very useful. either you reset the session after hitting the max, or you just log a warning and then continue accepting prefixes. i'll just be very stingy with my export to begin with and see how things go. [..] and from my reading it sounds like even going to a sup 2t wouldn't really solve the problem? although most of that discussion seems to be external bgp, maybe ibgp wouldn't run into issues? A sup2t(-xl) can handle 1 million routes, so that's plenty, but most serious overkill to get it only for the routing table memory. and it sounds like my line cards might have to be replaced... oh, and i run full ipv6 as well, just to make it interesting. Sup2 and IPv6 is software forwarding, so that might be some reason to upgrade eventually... so far my cpu is not breathing hard, and i run a routed vlan (with software shaping) for every port. but, overall routed traffic is under 100mb. even my layer 2 traffic rarely makes the little bar graph on the sup2 card flicker. i'm hoping i have years left on this setup. if the ibgp pushes things too hard, i'll just live with the inefficient traffic. ___ 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
Hi Matt, You are correct. Once you apply an ACL (any ACL) to an interface, there is an implicit deny ip any any at the end of that ACL. So, that will always take effect when an ACL is applied. It isn't a function of security levels, but rather the ACL itself. Security levels do a few things: 1) permit (or deny) traffic - when no ACLs are applied -- that is what we have mainly been talking about here 2) Determine if you can administer the ASA via that interface over Telnet (a legacy rule, but still there) 3) Affect some policy actions: ie - service reset[inbound|outbound] 4) Affect connection display information and a few more... But, the most noticeable to most people is indeed the permission of traffic based on the security level. Sincerely, David. On 2/11/2015 1:33 PM, Matt Addison wrote: Maybe this is a semantics thing, but isn't implicit rule of 'allow to any less secure interface' replaced by an implicit deny once you apply an inbound access-list to an interface? To some people that might be considered negating the security level of the interface (since the security level doesn't really do anything anymore). Once you have inbound ACLs everywhere you may as well not even have security levels.Hopefully today will be the day I learn there's a knob to turn that implicit deny into an implicit allow-to-less-secure which will make me regret all those hours spent tuning DMZ inbound access-lists. On Wed, Feb 11, 2015 at 8:57 AM, David White, Jr. (dwhitejr) dwhit...@cisco.com wrote: On 2/11/2015 7:29 AM, Joshua Riesenweber wrote: This has a few good examples:http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_extended.html I might very well be wrong, but I believe the security levels are negated if an access list is applied to an interface. That is incorrect. Security levels are not negated or affected by applying an ACL (or not) to an interface. Sincerely, David. Cheers,Josh Date: Wed, 11 Feb 2015 20:43:37 +1100 From: dale.shaw+cisco-...@gmail.com To: madu...@gmail.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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/ ___ 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] ibgp on 6509 with sup2?
Hi, On Tue, Feb 10, 2015 at 03:42:23PM -0800, Joe Pruett wrote: with bgp filtering might i be able to install just routes of /20 or shorter (hoping that is a small enough number of routes). or would bgp still consume all the routes before it filters and thus run out of ram? i'd don't think i want to experiment with this in production :-). The easiest way is to filter on *export* from the 7200s, so the 6509 has no chance to see the refused routes at all :-) Seriously: unless you configure soft reconfiguration on your peers, a route that is dropped will go away, without any traces. But it *will* consume CPU (some tiny amount), so if you already know what the downstream router wants, just not sending it from upstream is easier. If I remember right, Sup2 had 256k FIB, going to half that if you enable uRPF. So if you set your iBGP-sessions to max-prefix 23 (or 115000), and then experiment with feeding it more and more routes, you should be fairly safe... [..] and from my reading it sounds like even going to a sup 2t wouldn't really solve the problem? although most of that discussion seems to be external bgp, maybe ibgp wouldn't run into issues? A sup2t(-xl) can handle 1 million routes, so that's plenty, but most serious overkill to get it only for the routing table memory. oh, and i run full ipv6 as well, just to make it interesting. Sup2 and IPv6 is software forwarding, so that might be some reason to upgrade eventually... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpyfoGEqdYXm.pgp Description: PGP signature ___ 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
On 2/11/2015 7:29 AM, Joshua Riesenweber wrote: This has a few good examples:http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_extended.html I might very well be wrong, but I believe the security levels are negated if an access list is applied to an interface. That is incorrect. Security levels are not negated or affected by applying an ACL (or not) to an interface. Sincerely, David. Cheers,Josh Date: Wed, 11 Feb 2015 20:43:37 +1100 From: dale.shaw+cisco-...@gmail.com To: madu...@gmail.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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/ ___ 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
Correct. David. On 2/11/2015 4:22 AM, Alan Buxey wrote: Going from 0 to 100 . That's a default block on the ASA platform isn't it? alan ___ 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
First, a couple things to be aware of on the ASA: 1) All inbound traffic (from unprotected -- protected network) is Denied by default. You must explicitly permit the traffic you want via an interface ACL. 2) All outbound traffic (from protected network -- unprotected network) is Permitted by default 3) Security levels determine what is the protected vs. unprotected network. So, assuming you are permitting those ports in access-list outside-in (via a more broad ACE), then you can explicitly deny them by entering the following: access-list outside-in deny tcp any any eq 135 access-list outside-in deny ucp any any eq 135 [repeat for the other port numbers]. Note: these new ACEs would need to be placed 'above' any existing rules which 'permit' traffic to those ports, as the access-list is evaluated based on first match in the rule table. Finally, I highly suggest upgrading the software to a more recent release. 7.2.3 is extremely old. Sincerely, David. On 2/11/2015 3:26 AM, madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall interface GigabitEthernet0/0 nameif outside security-level 0 ip address 10.16.0.4 255.255.255.0 standby 10.16.0.5 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.6.80.5 255.255.255.0 standby 10.6.80.6 ! access-group outside-in in interface outside route outside 10.1.0.0 255.255.0.0 10.16.0.250 1 route outside 10.1.0.0 255.255.0.0 10.16.1.250 10 WAN-ASA# sh ver Cisco Adaptive Security Appliance Software Version 7.2(3) Device Manager Version 5.2(3) Regards, ___ 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
Thanks David and Matt for clearing that up. I only mention it because, in the OP's case, he has an ACL applied to the outside interface. So, it would seem more pertinent than the security levels (at least in the direction outsideinside). Cheers,Josh Date: Wed, 11 Feb 2015 14:00:28 -0500 From: dwhit...@cisco.com To: matt.addi...@lists.evilgeni.us CC: joshua.riesenwe...@outlook.com; dale.shaw+cisco-...@gmail.com; madu...@gmail.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi Matt, You are correct. Once you apply an ACL (any ACL) to an interface, there is an implicit deny ip any any at the end of that ACL. So, that will always take effect when an ACL is applied. It isn't a function of security levels, but rather the ACL itself. Security levels do a few things: 1) permit (or deny) traffic - when no ACLs are applied -- that is what we have mainly been talking about here 2) Determine if you can administer the ASA via that interface over Telnet (a legacy rule, but still there) 3) Affect some policy actions: ie - service reset[inbound|outbound] 4) Affect connection display information and a few more... But, the most noticeable to most people is indeed the permission of traffic based on the security level. Sincerely, David. On 2/11/2015 1:33 PM, Matt Addison wrote: Maybe this is a semantics thing, but isn't implicit rule of 'allow to any less secure interface' replaced by an implicit deny once you apply an inbound access-list to an interface? To some people that might be considered negating the security level of the interface (since the security level doesn't really do anything anymore). Once you have inbound ACLs everywhere you may as well not even have security levels.Hopefully today will be the day I learn there's a knob to turn that implicit deny into an implicit allow-to-less-secure which will make me regret all those hours spent tuning DMZ inbound access-lists. On Wed, Feb 11, 2015 at 8:57 AM, David White, Jr. (dwhitejr) dwhit...@cisco.com wrote: On 2/11/2015 7:29 AM, Joshua Riesenweber wrote: This has a few good examples:http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_extended.html I might very well be wrong, but I believe the security levels are negated if an access list is applied to an interface. That is incorrect. Security levels are not negated or affected by applying an ACL (or not) to an interface. Sincerely, David. Cheers,Josh Date: Wed, 11 Feb 2015 20:43:37 +1100 From: dale.shaw+cisco-...@gmail.com To: madu...@gmail.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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/ ___ 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/
[c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in Cisco ASA Software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Multiple Vulnerabilities in Cisco ASA Software Advisory ID: cisco-sa-20141008-asa Revision 2.0 Last Updated 2015 February 11 17:54 UTC (GMT) For Public Release 2014 October 8 16:00 UTC (GMT) Summary === *** Revision 2.0 Note: Please see the Software Versions and Fixes section, Important Note about Cisco ASA Clientless SSL VPN Portal Customization Integrity Vulnerability for updated information. *** Cisco Adaptive Security Appliance (ASA) Software is affected by the following vulnerabilities: Cisco ASA SQL*NET Inspection Engine Denial of Service Vulnerability Cisco ASA VPN Denial of Service Vulnerability Cisco ASA IKEv2 Denial of Service Vulnerability Cisco ASA Health and Performance Monitor Denial of Service Vulnerability Cisco ASA GPRS Tunneling Protocol Inspection Engine Denial of Service Vulnerability Cisco ASA SunRPC Inspection Engine Denial of Service Vulnerability Cisco ASA DNS Inspection Engine Denial of Service Vulnerability Cisco ASA VPN Failover Command Injection Vulnerability Cisco ASA VNMC Command Input Validation Vulnerability Cisco ASA Local Path Inclusion Vulnerability Cisco ASA Clientless SSL VPN Information Disclosure and Denial of Service Vulnerability Cisco ASA Clientless SSL VPN Portal Customization Integrity Vulnerability Cisco ASA Smart Call Home Digital Certificate Validation Vulnerability These vulnerabilities are independent of one another; a release that is affected by one of the vulnerabilities may not be affected by the others. Successful exploitation of the Cisco ASA SQL*NET Inspection Engine Denial of Service Vulnerability, Cisco ASA VPN Denial of Service Vulnerability, Cisco ASA IKEv2 Denial of Service Vulnerability, Cisco ASA Health and Performance Monitor Denial of Service Vulnerability, Cisco ASA GPRS Tunneling Protocol Inspection Engine Denial of Service Vulnerability, Cisco ASA SunRPC Inspection Engine Denial of Service Vulnerability, and Cisco ASA DNS Inspection Engine Denial of Service Vulnerability may result in a reload of an affected device, leading to a denial of service (DoS) condition. Successful exploitation of the Cisco ASA VPN Failover Command Injection Vulnerability, Cisco ASA VNMC Command Input Validation Vulnerability, and Cisco ASA Local Path Inclusion Vulnerability may result in full compromise of the affected system. Successful exploitation of the Cisco ASA Clientless SSL VPN Information Disclosure and Denial of Service Vulnerability may result in the disclosure of internal information or, in some cases, a reload of the affected system. Successful exploitation of the Cisco ASA Clientless SSL VPN Portal Customization Integrity Vulnerability may result in a compromise of the Clientless SSL VPN portal, which may lead to several types of attacks, which are not limited to cross-site scripting (XSS), stealing of credentials, or redirects of users to malicious web pages. Successful exploitation of the Cisco ASA Smart Call Home Digital Certificate Validation Vulnerability may result in a digital certificate validation bypass, which could allow the attacker to bypass digital certificate authentication and gain access inside the network via remote access VPN or management access to the affected system via the Cisco Adaptive Security Device Management (ASDM). Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate some of these vulnerabilities are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141008-asa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJU28PLAAoJEIpI1I6i1Mx3bSMP/jgP01l+AENISH9LbqQRgYLO hJJ5VrI0wnHt/wrb9kMbOrixjhOOMgSOuUm9xmMFymLje060Z4QbJaV2fPh/G6Po 71pOrlUWqnx8DrAJyowBvp/57X9JSeRHRbEIuLY0yHv3DEqFPL2HcBHLcs6rTMSV mbTDRVVMXCPOhqwbVygEgEHn6WNfP4sfZ39KYDbn4Z9aHXdZSa1gX0Mrw0vPq3Sx KAUUDJDnYKD7RaoobjV5z23/fb8G5E212Jql82x4QOswu+tCUT0H2E03aGBd7p3S VDa+VHGOVdg98kvg/fasNahYBdEcNjJOsP2XRFTr32jjEOAgAlZxH+G+6Azl+FCU dMNSeFADerAkYM6yRq/VdkhDqWd4mLmVUKlj7xa8S7tmlGl/6+x/nIhnKLNfoFHu AJpWAha175j02uLSICiVLUhs3v+Nypx8eV59X6M/XqNvfkFrqPq8jDIY9PDdm6ed HyVx4/Fqc8cyDNuwvX0a1lj6ZKb31kESjd0YYvT7FSPtnqtPwR+U6R/3KS4YI0eU LkrBmZ6rl5C5o3y716crF4WVVZCir7kBVmqKyjfLpVQ3p3yUJQ0gQiqFU1+i9GYh voLtT2FZH7n2+pJujar28EsL4PfTee243svrPrgVLgi3SomiGR/ue1ZG0xbJYS5V gCXy4KinIGorvsF/VJ+C =bTcn -END PGP SIGNATURE- ___ 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
Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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] Storm-Control
I have ME3400 with one of the connections is configured as trunk and port-type nniI applied storm-control on the interface and service was degraded , when I make the port access everything is fine , is there any restriction on the trunk/access setup on the port? ___ 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
Going from 0 to 100 . That's a default block on the ASA platform isn't it? alan ___ 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] ASA
I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall interface GigabitEthernet0/0 nameif outside security-level 0 ip address 10.16.0.4 255.255.255.0 standby 10.16.0.5 ! interface GigabitEthernet0/1 nameif inside security-level 100 ip address 10.6.80.5 255.255.255.0 standby 10.6.80.6 ! access-group outside-in in interface outside route outside 10.1.0.0 255.255.0.0 10.16.0.250 1 route outside 10.1.0.0 255.255.0.0 10.16.1.250 10 WAN-ASA# sh ver Cisco Adaptive Security Appliance Software Version 7.2(3) Device Manager Version 5.2(3) Regards, ___ 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] Storm-Control
I have ME3400 with one of the connections is configured as trunk and port-type nniI applied storm-control on the interface and service was degraded What exact storm-control configuration did you apply (there are many) and what exactly do you mean when you say the service degraded (was unicast traffic degraded or broadcast/multicast)? when I make the port access everything is fine , is there any restriction on the trunk/access setup on the port? No. But when you have bogus incoming broadcast traffic on an unused vlan, storm-control will start dropping broadcast on all Vlans, because there is no fairness within storm-control. It just starts dropping packets. Lukas ___ 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] Storm-Control
Hi I am configuring storm-control for broadcast and multicast trafficThe service is affected even on the unicast frames From: luky...@hotmail.com To: gunner_...@live.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Storm-Control Date: Wed, 11 Feb 2015 12:52:51 +0100 I have ME3400 with one of the connections is configured as trunk and port-type nniI applied storm-control on the interface and service was degraded What exact storm-control configuration did you apply (there are many) and what exactly do you mean when you say the service degraded (was unicast traffic degraded or broadcast/multicast)? when I make the port access everything is fine , is there any restriction on the trunk/access setup on the port? No. But when you have bogus incoming broadcast traffic on an unused vlan, storm-control will start dropping broadcast on all Vlans, because there is no fairness within storm-control. It just starts dropping packets. Lukas ___ 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] CCNA certification training recommendations
Am 11.02.15 um 00:09 schrieb Eric Louie: Would anyone like to recommend a CCNA certification training course? Preferably one that you took that helped you with your certification. Hi Eric, recently I have taken part in a Video Boot Camp for preparation on a CCNP exam. It was from Chris Bryant and offered via www.udemy.com Chris Bryant in my opinion is an excellent teacher and brings the certification-relevant things into focus. He has got a similar Video Boot Camp for CCNA as well on the mentioned website. -- Stefan -- Stefan Giera, BelWü NOC BelWü-Koordination, Universität Stuttgart Industriestr. 28, 70565 Stuttgart Tel: +49 711/685-65797 | Durchwahl Tel: +49 711/685-88030 | NOC, Netzbetrieb, Router Tel: +49 711/685-88020 | (Schul)Hotline Fax: +49 711/678 83 63 E-Mail: i...@belwue.de - http://www.belwue.de ___ 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
This has a few good examples:http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/acl_extended.html I might very well be wrong, but I believe the security levels are negated if an access list is applied to an interface. Cheers,Josh Date: Wed, 11 Feb 2015 20:43:37 +1100 From: dale.shaw+cisco-...@gmail.com To: madu...@gmail.com CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA Hi madunix, On Wed, Feb 11, 2015 at 7:26 PM, madu...@gmail.com madu...@gmail.com wrote: I would like to block the following ports: 135,137,138,139,445,593, tcp/udp on my Firewall [...] Well, what you need to do, is figure out how to block those ports, perhaps by modifying the 'in' access-list you've applied to your outside interface. You might even need to Google That. That's assuming it's that direction (outside inside) that you want to block the traffic. Cheers, Dale ___ 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/
