#SecureSenses --verbose

There are multiple ways to secure OSPF.  The essential one is authentication. By default there isn't any validation to assure legitimacy of an OSPF topology update. Basically an attacker or a bored employee could install a physical router and become a member of a routing system. Alternately a tool such as LOKI ( http://www.ernw.de/content/e6/e180/index_eng.html ) could be used. LOKI provides a GUI and is very simple to use, I however found it a bit buggy. More on that can be found in my Attacking OSPF - route injection post. Other tools that could be used include:  SCAPY  http://www.secdev.org/projects/scapy/  - very advanced and fairly complicated packet generation tool, to craft OSPF packets it requires OSPF extension TCPREPLAY -  http://tcpreplay.synfin.net/  - a legitimate OSPF adjacency set up and database exchange could be captured, modified and replayed (I had limited success with this technique) On a Cisco router we can use the following to secure our OSPF routi

LOKI and author's Black Hat presentation can be downloa ded here:   http://www.ernw.de/content/e6/e180/index_eng.html   Falsifying routing information can have disastrous consequences to network stability. For example an attacker could reroute traffic through a monitoring station and capture traffic for later analysis. An attacker could also reroute traffic to a black hole or reroute a 10 Gig transit link traffic towards a 1 GB link causing a Denial of Service (DoS) condition.  Both network topology and scenario presented in this post are extremely simplistic but should be sufficient to present potential implications. Our topology: R1's routing table looks as follows: R1#show ip route C    20.0.0.0/8 is directly connected, FastEthernet1/0      172.16.0.0/24 is subnetted, 1 subnets C       172.16.0.0 is directly connected, FastEthernet0/0 O    192.168.5.0/24 [110/2] via 172.16.0.1, 00:00:01, FastEthernet0/0      10.0.0.0/32 is subnetted, 1 subnets C       10.0.

Distribution layer aggregates access layer switches. This is where all packet manipulation that hasn’t already been performed in access layer should take place. I’m focusing here on infrastructure protection rather than device hardening. Everything below is of little benefit if default passwords are used! Even though, properly configured ACLs restricting access to management interfaces would in some cases effectively prevent an attacker from being able to login to a switch. Hardening is essential. This is what we call defence in depth. -           Routing infrastructure protection o      Authenticate routing neighbours with MD5 (prevents rouge routing info injection and routing table manipulation) o     implement route filtering (as above) o     use default passive interfaces (tells an interface not to listen to or distribute routing protocols, this prevents infection and interception of routing data, furthermore it makes determining what routing protocol is in use mo

The campus access layer switching infrastructure must be resilient to attacks including direct, indirect, intentional, and unintentional types of attacks. In addition, they must offer protection to users and devices within the Layer 2 domain. The below terminology is Cisco specific, however similar features are available in products of other brands.  The key measures for providing switching security on the access switches include the following: • Restrict broadcast domains • Spanning Tree Protocol (STP) Security -        Rapid Per-VLAN Spanning Tree (Rapid PVST+)  (fast convergence) -        BPDU Guard (shuts port down if a BPDU is received, prevents STP manipulation)  -        Root Guard to protect against inadvertent loops (prevents other switches from becoming root bridge) -        BPDU filter (stops BPDUs from being broadcast to access ports) • DHCP Protection -        Implement DHCP snooping on access VLANs to protect against DHCP starvation and rogue DHCP s

In previous post I went over attacking HSRP using default authentication of "cisco". In this post I'll go over defenses. HSRP attacks are performed at Layer 2 so the attacker must be on the same L2 domain (same VLAN/subnet). Probably this is the reason no one pays much attention to it. "It's our LAN, it's behind firewall so it's safe. Right?" Maybe, but there are bored employees, there are misconfigurations, and there could be malware that would mess up your network. Either way, if it can be more secure it should be. That's what "defense-in-depth" is all about. HSRP supports authentication. Either a plain-text or md5 ca be used. Plain text option provides little to no protection as the plain text password is sent in clear text with every HSRP packet. MD5 authentication solves the problem. It uses a secret key to generate a keyed MD5 hash of the packet that is part of the outgoing packet. A keyed hash of an incoming packet is ge

Hot Standby Router Protocol (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault-tolerant default gateway, and has been described in detail in RFC 2281 Source: https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol HSRP is used in enterprise networks to provide default gateway redundancy in access layer. Enabling HSRP is as simple as executing two commands. The problem is that by default it uses clear text authentication with password of "cisco".  This can be captured as seen below and used to inject malicious HSRP packets. We will use "Yersinia" http://www.yersinia.net/ to capture and inject our own packets (this is always fun). Our network topology looks as follows: Let's ping the  two "real" addresses .2 & .3 and the vitual IP .1 to confirm everything is working: Now let's fire up Yersinia in GUI mode (the GUI is a bit buggy and sometimes crashes): # yersinia -G  Let's go to "

I’ve been working on LAN infrastructure security assessment recently. As a part of it I’d been looking for bullet point-type summary of main threats to the 3 network architecture layers.  I couldn’t find anything like that which led me to compiling my own list. The below points don’t follow standard access, distribution, core split but Cisco’s “modular design” principle.  Below points are based on “Cisco SAFE Design Reference Guide”.   http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap1.html     Enterprise Core: The following are some of the threat vectors affecting the enterprise core: Service disruption—DoS and DDoS attacks on the infrastructure. Unauthorized access—Intrusions, unauthorized users, escalation of privileges, unauthorized access to restricted infrastructure, and routing protocol attacks. Data disclosure and modification—Packet sniffing, man-in-the-middle (MITM) attacks of data while in transit.   Enterprise Campus:

Recently I needed to enable logging of failed logon attempts in Cisco IOS. There is a "login on-failure log" configuration command which helped me accomplish my goal. While testing I noticed that enabling it on its own didn't produce expected results. Basically failed login attempts didn't show up in the log upon enabling it. In the end I found out that it must be used in conjunction with "login block-for" command to actually log logon attempts. R3#show login failures *** No logged failed login attempts with the device.*** This the defualt configuration: R4#sh login      No login delay has been applied.      No Quiet-Mode access list has been configured.      Router NOT enabled to watch for login Attacks This is what we see after enabling "login on-failure log": R3#sh login      No login delay has been applied.      No Quiet-Mode access list has been configured.      All failed login is logged.      Router NOT enabled to watch