<![CDATA[Network Defense Blog - Transport Networking & Cyber Security]]>https://www.carspecrelease.com/?exampass=blogRSS for NodeThu, 09 Apr 2020 20:55:16 GMT<![CDATA[Troubleshooting with Wireshark: The Case of the TCP Challenge ACK ]]> preferences > protocols > TCP. By default this feature will be enabled which causes wireshark to show sequence numbers that are more human friendly; however sometimes things will not match up, therefore its recommended to disable this feature for this scenario. Another tip is to create columns for each of the sequence numbers. To do this click on any type of TCP packet and open it, then click on the data you want, finally right-click and select "apply as column". So in this case we would want to create a column for the sequence number, acknowledgement number, and next-sequence number. I generally always run these columns in my captures when troubleshooting. Note: you can do this for many different parameters - try it. When doing a packet capture on a firewall you will most likely setup filters. This is so you can only capture the desired traffic. Although there are ways to do this in wireshark, when capturing on a client machine you might not have this luxury, so a quick way to find the flow you are looking for is by going to the conversations tab and filter there. Statistics > Conversations > click the flow you want after the window pops up > then click follow stream. note: this is also useful to find the largest flow by sorting by # of packets or Bytes etc. if you were looking for a large download or upload. Closing Notes With the way the internet landscape is these days it's not surprising that you'd run into something like this. It's understandable that the server side of things would want to protect themselves from different transport control attacks or have a mechanism to free up socket space in the TCP stack when receiving large amounts of requests. However if you are running a solution like this where the challenge ACK is explicitly configured or something - like on a load-balancer, I feel you should have some sort of article or note in your service system in order to allow your help desk to possibly assist in identifying this is the issue. This would be valuable in helping the user/customer. The fact we couldn't get anywhere with support was somewhat frustrating, so hopefully operators can add additional info for this in the future, even though this vulnerability is over 10 years old. Like I had mentioned try googling for this problem and you will have mixed results. Although there are some arguments about not enabling some of the features that allow non-standard TCP behavior the likeliness of this type of attack is low compared to some others, and the threat sometimes is there with the feature enabled or not. There are definitely TCP related configurations I would never enable on internet facing interfaces though like full state-bypass. In my case the behavior was already allowed but after a firewall upgrade to a higher version a new feature needed to be enabled and committed to allow it. At first there was some head scratching but as you can see from the packet capture and the references the nature of the flow is to be expected in some cases. Although an acceptable root cause was determined, there were still some things left unanswered for me in this case; however, without further visibility into the provider network or help from support I likely will not dig any further to analyze this. Plus the customer is happy now that they can access the web page - another ticket closed. Hopefully this article helps you if you run into this type of issue or something similar. If you have any further information on vendor mechanisms for RFC 5961 please share them here for educational purposes but also on the web to improve the google results. Thank you Further reading: ASA troubleshooting slide deck Palo Alto troubleshooting via CLI Palo Alto in-depth flow explanation CVE info #firewall #cisco #paloalto #dataconservation #cybersecurity #TCP #netsec Don't forget to vote for network defense blog in the Cisco IT blog awards! Much appreciated!]]>https://www.carspecrelease.com/?exampass=post/wireshark-tcp-challenge-ackhttps://www.carspecrelease.com/?exampass=post/wireshark-tcp-challenge-ackThu, 28 Nov 2019 03:16:04 GMTBrandon Hitzel<![CDATA[Cisco IT Blog Award Finalist in "Best Analysis" Vote Now!]]>https://www.carspecrelease.com/?exampass=post/cisco-it-blog-award-finalisthttps://www.carspecrelease.com/?exampass=post/cisco-it-blog-award-finalistSat, 23 Nov 2019 04:39:12 GMTBrandon Hitzel<![CDATA[5 Easy Router Protection Techniques - includes Attack and Packet Analysis ]]>"), or by disabling it all together on an interface. (check this, old but educational article on ICMP crafted messages) Proceeding on, if you are using an ACL to restrict access or for traffic in/out of an interface, when a block entry is hit the device will respond with a type 3 code 13 " Communication administratively prohibited". This might be unwanted behavior as an attacker could utilize this to their advantage to find open ports or certain types of allowed flows. Here are the results of the first ping test which is dropped via an access-list. As mentioned you can disable the ICMP type 3 replies on an interface, which might be a good consideration for a edge router that typically has an inbound access list screening some of the internet traffic as it reaches the network. Below you can observe that after disabling unreachables there are no ping responses in the second ping test, so scanners would likely not even detect there is a device active if their traffic was dropped; however in the previous scenario the scanner would detect there was a device there even if it's traffic was dropped by the access list because of the ICMP reply. Additionally, notice the difference between the first and second traceroutes where the second traceroute did not have a packet from the first hop router due to the ICMP type 3 replies being disabled. The final hop still had them enabled though. Here is how the tests looked from the end host perspective. From the top down: Ping without ACL - successful Ping with ACL - Code 13 reply from first hop router Traceroute normal Traceroute with "no IP unreachables" on first hop interface Ping with ACL but with no ICMP replies - unsuccessful Out of the Box Review Kali linux has a variety of tools that are shipped with it that can literally exploit and devastate a variety of targets. However in my testing I found the tools had more exploits for Soho routers than for Cisco routers. The programs tested were cisco-torch, cisco global exploit (CGE), and metasploit framework. Moreover, a lot of the vulnerabilities seemed aged based on the listed date (if there was one). This is why its important to keep your software up to date, because as these issues with the code arise the vendors (hopefully) patch and protect against them. You wouldn't want to be taken down from an old vulnerability that was patched years ago because you neglected to update. Back to the aged scripts, for example the cisco global exploit showed one option to be for catOS which is old and probably wouldn't be seen by most people and it had a few old HTTP CVEs from the early 2000s. I found one funny in that it sent a HTTP GET with a tons of AAAAAAAAAs which I assume did something once upon a time. The router responded with a 401 bad request and seemed unchanged after a few attempts (this could also be because it is a virtual device but I doubt it). I'm not really familiar with that CVE either. Most the assaults I tried with cisco-torch and CGE were ineffective, except for the telnet buffer overflow when left unchecked (but like we discussed - disable unused services, Telnet should not be used because it is not secure). I even tried some NTP vulnerabilities which I expected my IOS to effected by like ntp_overflow and ntpd_reserved_dos but no dice. This is how the Syslog #9 vulnerability looked from GCE. You can see on metasploit there are a lot of options to choose from, but like with the previous examples the attacks I tried didn't do much against a more up to date (although still older IOS) protected device; although I only tested on virtual instances of Cisco routers. I'm sure some of those Soho scripts for D-links or the new Cisco RV small business devices are potent though. Closing I hope this post helps you in reviewing your routers or other Layer 3 network devices in order to better protect management access, along with your infrastructure's availability from Denial of Service attempts. Additionally, in the future I'm sure there will be more effective additions to the Kali distribution against enterprise routers vs. small business routers. In this post we went through some packets and got down to the detailed level for a few of the offensive actions in order to better understand why we implement some of these security controls. Disabling unused services that broadcast out like CDP/LLDP and protecting your router using ACLs are simple yet effective means of network defense. If a protocol supports authentication then its wise to use it where possible. Also take into account the implications of leaving ICMP type 3 messages enabled on external facing interfaces. The next post in this area I will probably do a write up about Control Plane Policing to protect the control/data planes, since that topic isn't covered a lot from what I've seen. Finally, this should be a given but keep your devices patched and up to date! Good luck out there. Would you like to know more? Juniper device hardening checklist Comprehensive Cisco configuration guide for hardening devices Configuration guide for hardening Cisco IOS-XR devices Mikrotik Router OS hardening guide #networkdefense #cybersecurity #kalilinux #wireshark #packetanalysis #networking #netsec]]>https://www.carspecrelease.com/?exampass=post/5-easy-router-attacks-and-protectionshttps://www.carspecrelease.com/?exampass=post/5-easy-router-attacks-and-protectionsFri, 27 Sep 2019 02:25:51 GMTBrandon Hitzel<![CDATA[The Art of Cyber War and Cyber Battle: Deception Operations]]>https://www.carspecrelease.com/?exampass=post/art-of-cyber-war-deceptionhttps://www.carspecrelease.com/?exampass=post/art-of-cyber-war-deceptionSun, 29 Dec 2019 18:18:20 GMTBrandon Hitzel<![CDATA[The Art of Cyber War and Cyber Battle: Formations ]]>https://www.carspecrelease.com/?exampass=post/art-of-cyber-war-formationshttps://www.carspecrelease.com/?exampass=post/art-of-cyber-war-formationsSat, 10 Aug 2019 23:50:37 GMTBrandon Hitzel<![CDATA[CCDP Certification Study Material]]>https://www.carspecrelease.com/?exampass=post/ccdp-study-materialhttps://www.carspecrelease.com/?exampass=post/ccdp-study-materialTue, 18 Jun 2019 00:10:42 GMTBrandon Hitzel<![CDATA[Network Design Scenario #2: DMZ Design]]>https://www.carspecrelease.com/?exampass=post/design-scenario-2-dmz-designhttps://www.carspecrelease.com/?exampass=post/design-scenario-2-dmz-designSat, 28 Sep 2019 01:46:30 GMTBrandon Hitzel<![CDATA[Challenge Labs #2: Switching & Layer 2]]>https://www.carspecrelease.com/?exampass=post/challenge-labs-layer-2-labshttps://www.carspecrelease.com/?exampass=post/challenge-labs-layer-2-labsFri, 01 Feb 2019 02:45:50 GMTBrandon Hitzel<![CDATA[The Art of Cyber War and Cyber Battle - Series Introduction]]>https://www.carspecrelease.com/?exampass=post/the-art-of-cyber-war-and-cyber-battlehttps://www.carspecrelease.com/?exampass=post/the-art-of-cyber-war-and-cyber-battleMon, 21 Jan 2019 15:12:29 GMTBrandon Hitzel<![CDATA[Network Defense Against Perception - Updated]]>https://www.carspecrelease.com/?exampass=post/network-defense-against-perceptionhttps://www.carspecrelease.com/?exampass=post/network-defense-against-perceptionWed, 19 Dec 2018 05:44:50 GMTBrandon Hitzel<![CDATA[Network Design Scenario #1: Redundant OSPF Point-to-MultiPoint WAN]]>https://www.carspecrelease.com/?exampass=post/network-design-scenario-1-redundant-ospf-point-to-multipoint-wanhttps://www.carspecrelease.com/?exampass=post/network-design-scenario-1-redundant-ospf-point-to-multipoint-wanWed, 25 Sep 2019 17:52:15 GMTBrandon Hitzel<![CDATA[Certification Comparison: SSCP vs. CCNA Security]]>https://www.carspecrelease.com/?exampass=post/certification-comparison-sscp-vs-ccna-securityhttps://www.carspecrelease.com/?exampass=post/certification-comparison-sscp-vs-ccna-securityTue, 18 Dec 2018 05:20:24 GMTBrandon Hitzel<![CDATA[Challenge Labs #1: CCNA/CCNP Labs]]>https://www.carspecrelease.com/?exampass=post/challenge-labs-part-1-ccna-ccnp-labshttps://www.carspecrelease.com/?exampass=post/challenge-labs-part-1-ccna-ccnp-labsWed, 05 Sep 2018 03:09:25 GMTBrandon Hitzel<![CDATA[How to Disable Password Recovery on Cisco Devices]]>https://www.carspecrelease.com/?exampass=post/cisco-devices-disable-password-recoveryhttps://www.carspecrelease.com/?exampass=post/cisco-devices-disable-password-recoveryMon, 03 Sep 2018 03:05:09 GMTBrandon Hitzel<![CDATA[Knowledge is power - lots of links]]>https://www.carspecrelease.com/?exampass=post/links-to-everythinghttps://www.carspecrelease.com/?exampass=post/links-to-everythingSat, 01 Sep 2018 03:04:36 GMTBrandon Hitzel<![CDATA[Hello World: Internet Plumbing & Data Conservation ]]>https://www.carspecrelease.com/?exampass=post/hello-world-networkdefensebloghttps://www.carspecrelease.com/?exampass=post/hello-world-networkdefenseblogThu, 06 Sep 2018 02:02:22 GMTBrandon Hitzel