EvilZone

Hi duder,


What specific type of network course is it? Is it general networking (COMPTIA Network+) or a vendor-specific curriculum (Cisco CCENT)?


I would highly recommend Danscourses. He does some really nice, slow, intro-esque videos which can really help out a newcomer to the practice of networking.

I saw this product in use at a competition.


Red team bypassed it by base64 encoding their payloads.


But that aside, it does a fairly good job.

WOOO first post!

But seriously, This is just the demo section we appended quickly at the end of a report I had to create last year, some of it wont make much sense (like why i mention the wastefulness of tcp, which is bs) since I needed to remove the main report (it is publically hosted and this would lead right to me IRL).

But I figured I would throw this much up to show you what GNS3 can do, everything should be pretty clear, and for those that don't know GNS3 is a network simulator that is absolutely BOSS.

Some Shitty Demof

Anywho.. GNS3, it's awesome.

First of all, I absolutely need to bump this dead thread and say what a pleasure it was reading over that other HDLC thread. Why in the world someone would want to know the inner-workings of HDLC is beyond me -- but mad kudos for doing that.


This thread I might add, I really like. The "Wastefulness of TCP" made me lol.


BGP is one bad-ass protocol. Unfortunately, the nature of GNS3 and the old, OLD code you're forced to run on that platform don't quite give one the glimpse into the new(ish) capabilities which have been added to the stack.


Cisco came out with VIRL, which is basically a really new version of GNS-3 which they've built in support for IOS, IOS-XE, IOS-XR, blah blah blah. Unfortunately, that costs money (thanks, Cisco). It would almost be cheaper to pick up a 2811 on EBay for $50, toss in 512MB of RAM, and load on the newest 15.x code.


Either way, thanks for the BGP mention. Made me happy

Well, over the weekend i was watching dwshift replay of afew documentaries. They included a small vilage that had setup its own ISP and got themselves some real fast internetz for its users and wireless everywhere.
I don't seem to locate that documentary on the internet now but lel.

My question is what could it take to set this up, maintain it plus anything you could add. I hve been afew yers away from the networking field so something good for a proposal could be handy.
Fire away.

EDIT: A simple google search makes my balls quack.

Okay, I'll bite.


Tell me the exact requirements that you have for this scenario.






You can get a 1Gb/s ethernet off-net handoff with 100Mb/s commit in the US for probably about $2,000/mo. Depends on where you are.


You'll need something that is capable of routing 1Gb/s, so at the very least something like a Catalyst 6500 with SUP720's.


You can piece one of those together on EBay for about $700. You don't really need to run BGP unless you have multiple providers, but really -- what's the point of that. Or, just set up an IP SLA to track the next hop and fail over to some slower, less expensive backup link.


Wireless is tricky. You'd need a wireless controller. You can go with cheap shit like Ruckus - or go big with Cisco. Once again, Ebay is your friend.


At that point, you just need to run a lot of cable. From the technical perspective, it's really simple.


As for costing $2,000,000 -- I don't think so. Maybe if you need to dig shit up to lay cable, but just from an infrastructure perspective, I couldn't see that exceeding $300,000.

In addition to the quality of the router / AP, it also depends on the clients associating to the device.


If a 802.11b client associates to a device which only has one radio dedicated to the 2.4GHz band (most home routers/AP's), it will bring the entire channel down to 802.11b speeds.

If not Windows firewall as another user mentioned, my money would be on a permissions issue. Consider tcpdump'ing the traffic and attaching the pcap to the thread so that we can see the handshake happen and determine if it is in fact a connectivity issue.

Additionally, check the Windows side for any logs which would indicate a failed login. I'm assuming you're not in a domain environment here.

I hate to bump a dead topic, but seeing as there's been no reply - I figured it would be nice to drop my 2c for future readers who may come across this thread.

So! Layer 2 attacks against any network device can take many forms. One could leverage the age-old ARP poisoning method to modify the CAM table of your layer-2 medium between your target and its gateway, flood CDP messages to the upstream device (as OP mentioned) in an effort to exhaust device resources, try to negotiate a trunk by sending DTP's, flooding traffic which hits the control plane of a device resulting in a DoS, and so on. It's a pretty expansive topic, but the good news is that most vendors have enabled software features to mitigate such attack vectors with relative ease. For the duration of this post, I will be using Cisco syntax to describe the steps to resolution. If there's any other attack methodologies or vectors anyone can think of that they would like addressed, feel free to post 'em.

So how does one devour an elephant... Bite by bite I suppose. So here goes. Feel free to skip down to the "mitigation" section if you are already familiar with DTP, VTP, Trunks, vlans (802.1Q ... no ISL here :3 ).



Sending DTP's to a switch to form a trunk for VLAN hopping, etc.

Before we can dive into the specifics for defeating a DTP-based attack vector against a switch, we need to address the following:

• What is a trunk?
• What is a VLAN?
• What is VLAN pruning on a Trunk?
• How does DTP work?
• Cross-Protocol Dependencies (VTP)

What is a trunk?
A Trunk is a layer-2 interface which passes multiple VLAN's across it. This is extremely handy when designing a network where you may want to push separate layer-2 broadcast domains through a set of switches, and only selectively allow hosts onto said network on a per-port basis. In simpler terms, you can have - for example - one port per building on an entirely separate management network, which is completely separate from all other systems, while still allowing direct layer-2 communication between end hosts.  It's a pretty simple concept really, but in production they can be absolutely ridiculous to manage.


What is a Vlan?
A Vlan (802.1q)  is basically an encapsulated ethernet frame which informs the network how to properly handle the traffic being received / forwarded. If you're familiar with the layout of an Ethernet frame, then just picture an additional 32-bit header being inserted between the Source MAC and Ethertype sections of the frame. This 32-bit header contains something called a TPID and TCI - which is getting about as technical as I want to take this. Long and short here is that this 32-bit header informs a network device what VLAN ID said traffic belongs to, and as such determines what access said member has access to. The Vlan is a building block of sorts in network designs which allows for LAN segmentation, minimization of broadcast domains, and even some policy-based routing.



What is VLAN pruning on a Trunked interface?

VLAN Pruning on a Trunk allows an administrator to selectively exclude Vlans from traversing a trunked interface. This of course improves security, and allows for tighter control of broadcast domains and network engineering. This is also pretty important when you consider the impact this has on the spanning-tree process when running either MST or some variant of PVST. I'm going to avoid getting too deep into spanning-tree in here given the fact that I've been typing for quite a while already, and am not even half way done  T-T.


DTP - How does it work?
Dynamic Trunking Protocol is one of those ideas that someone came up with that was pretty good in the beginning - but very quickly became a pain in the ass of anyone wanting to build a secure access layer. In short, it allows a device connected to a switch port to negotiate and form a trunk, thereby allowing said device access to ALL vlans that exist within that switch's VLAN database (and if it's running VTP, that's a lot).
So, DTP will only form a trunk with a device which has the same VTP domain configured... so that seems secure enough right? lolno...
In the packets that DTP will send out, the VTP domain will actually be right there! In clear text no less! So a would-be attacker could very easily respond to this DTP-enabled device with a forged packet indicating the same VTP domain - and BAM. You've got yourself a trunk.


Cross-Protocol Dependencies?

As discussed previously, DTP does rely on VTP (the VLAN trunking protocol) in order to dynamically form a trunk with an adjacent device. VTP in short, is a protocol which facilitates the propagation of VLAN data (VLAN ID's, VLAN names) across a switched network. It will actually add the VLAN information to the local vlan database, and any non-pruned trunk ports will begin allowing said tagged traffic across the trunk. Additionally, VTP is in and of itself a huge vulnerability. I can't tell you how many networks I've seen get blown out due to a new switch being added to the network in the "VTP Server" mode - and proceeding to erase all VLAN databases across the layer-2 switched network. But, I can't complain too much. It guarantees me a job so long as customers don't RTFM.



So to recapitulate, (and stay with me here, this is going to be verbiage-dense): DTP relies on VTP domains to form dynamic trunks with devices adjacent to DTP-enabled ports. This allows said device to form a non-pruned 802.1q-enabled trunk allowing for tagged vlan traffic to originate from the end-device and potentially gain access to LAN segments that should otherwise be off-limits. In addition to this, the protocols that DTP relies on are inherently vulnerable - or just plain dangerous. VTP allows for VLAN's to be learned *and deleted* dynamically. DTP runs by default on all Cisco switch ports.




Scenarios wherein CDP or MAC tables are filled resulting in resource exhaustion:


As OP highlighted, there do exist scenarios in which a local attacker (or remote attacker who loaded malware onto a local system) could create a scenario resulting in a DoS. Flooding the CDP table - at least on today's equipment is not likely going to impact much of anything, as the majority of forwarding decisions are made in hardware - called TCAM. The CDP table does not exist in TCAM, and would only impact memory-centric applications, such as BGP, EEM, etc.
As for flooding the CAM table - this too is a viable attack vector that could do quite a bit of damage. BUT - it's pretty easy to solve at the same time.




Mitigation:

• CDP Table Flood

This is kind of an interesting one to me. Off the top of my head, there are no real built-in ways to police CDP traffic. I can however think of two ways (aside from disabling CDP on access ports) that would work. NOTE: Cisco IP Phones rely on CDP to pull their voice vlan for their multi-access port, so disabling CDP isn't always a solution.

One could write an EEM applet to periodically check for CDP table changes over a certain threshold, and proceed to disable the port in question. In addition to this, you could blast out a syslog notification, or even send an email to the administrator ... all from your network device.

The other option that would be interesting to check out would be to implement CoPP to rate-limit CDP.  I found the below config snippet in a Cisco IOS-XE 3.3 doc here on page 4:  http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/15-1/XE_330SG/configuration/guide/config/cntl_pln.pdf

Switch# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#qos
Switch(config)#macro global apply system-cpp
Switch(config)#policy-map system-cpp-policy
Switch(config-pmap)#class system-cpp-cdp
Switch(config-pmap-c)#police 32000 1000 conform-action transmit exceed-action drop
Switch(config-pmap-c)#end
Switch#

• CAM Table Flood and ARP Poisoning

To defeat the common CAM table flooding tactic, it is a simple task to configure access ports with something called sticky arp, or port-security. One could also turn in DAI (dynamic ARP inspection) which integrates into the DHCP snooping daemon to validate all IP/MAC bindings on the network by tracking every DHCP request / reply, and ensuring that every device adheres to this. One could also enable CoPP (control-plane policing) to ensure the device wouldn't be adversely affected by a sudden flood of traffic. This can be easily comprehended if you were to check out the MSFC on the Catalyst 6500 architecture.

6500 architecture: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/prod_white_paper0900aecd80673385.html

ARP options on ASR: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_arp/configuration/xe-3s/asr1000/arp-xe-3s-asr1000-book/arp-config-arp.html#GUID-EE3D7DB6-AD44-4AD5-8F83-7B58CAE1974C

Old Cisco whitepaper on DAI w/ Ettercap: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_603839.html

• "Securing" DTP, VTP, STP, CDP:

So, I use the term securing with Doctor Evil quotation fingers. Generally speaking, I like to just disable DTP, CDP and VTP altogether, as the only real benefit they offer is to try to automate the job of a network engineer - which sadly doesn't work as well as they intended.


Here is an example of one of my switchport configurations on one of my access switches:

core01.nj(config)#do show run int g3/12
Building configuration...

Current configuration : 188 bytes
!
interface GigabitEthernet3/12
 switchport
 switchport access vlan 200
 switchport trunk encapsulation dot1q
 switchport mode access
 spanning-tree bpduguard enable

 spanning-tree portfast edge
 switchport nonegotiate  **DTP
 no cdp enable  **CDP
core01.nj(config)#do show run | s vtp
vtp domain null
vtp mode off  *note* mode transparent would work as well



What I did not list here were STP-related configurations. I'll leave that for another day. If you're interested and want to learn more however, check out features such as "bpduguard, rootguard, bpdufilter".

So, when it comes to protocol-level manipulation of a network, the only real exploitable scope would be the human stupidity that went into deploying and maintaining the network. The great news for me (job security) and you (schadenfreude)  is that there's a whole lot of people, VAR's, etc that have no idea how these protocols inter-operate and function. Don't be one of those people :3


Nord