Not limited to CCIE Security Lab only, of course, here is the list of books I find really useful in preparing for the Lab .
Amazon Listmania list
Not limited to CCIE Security Lab only, of course, here is the list of books I find really useful in preparing for the Lab .
Amazon Listmania list
Cisco gear has a well-known behaviour pattern that when you telnet to some weird and positively closed port on Cisco you get the uniform response of “Connection refused” . To add more precision it happens when a terminal line management access is enabled on the Cisco but your IP is not in the access-list allowing access to the device. The funny thing about that is that only Cisco seem to do it , and given so, it makes exposing a Cisco device a no-brainer. I tested it on few dozens of Cisco routers (I don’t talk about other equipment from the Golden Gate folks) and it only confirmed this observation. Also I tested telnetting to the other vendors’ equipment and always got back time out. So far I’ve tried Juniper, Brocade, IBM, Huawei. To somehow fix this situation Cisco actually have a feature in their Control Plane Protection toolbox just for that. Below I bring the configuration from IOS router that causes the router to time out connection attempts to the closed ports.
Testing.
Before the configuration:
After the configuration:
NB Unfortunately it is a half-solution cause if telnet access is enabled on the Cisco then connection attempts to the port 23 will elicit the same “Connection refused” . To close even this disclosure hole , disable telnet as the management protocol and switch to SSH.
NB2 The good news for the pentesters out there is that rare ISP implement such protections
Group locking, as Cisco call it, has been available since ancient IOS 12.2(13)T (circa 2003) and still – most of the set ups I see of clients’ VPN servers at most use different VPN groups for different privilege access requirements and blissfully ignore the fact that all it takes to get more enabled access is to know the pre-shared key of the other VPN group. And believe me – it is not that hard when group pre-share key (PSK) is known to half of the company. So if you happen to stumble on this post bear with me and let’s fast forward from accepted practices of 90’s to 2010.
Below are possible ways to lock users connecting to Cisco device (IOS router and ASA to be precise) to predefined VPN groups and do it forcefully so that even if the end user knows the PSK of other VPN group(s) she won’t be able to connect with it.
Case 1. Cisco IOS router acting as Ezvpn server , users are authenticated locally by the router. Let’s name it – group is JUNIPER , and the local user is John.Chambers and we want to confine this user to this group for ever.
Enable group locking for specific group (don’t forget to do the same for all VPN groups)
Now restrict user to be able to use this group only. For that you have to reconfigure user to look like username followed by delimeter (that can be any of @, %, /, \) and then group name , to be concrete
from now on user John.Chambers will be able to authenticate with Cisco only using John.Chambers@JUNIPER . It overrides any user for VPN connection that already exists, that is if there is already user John.Chambers it will not be able to connect with the group JUNIPER . On the other hand anyone getting PSK of the VPN group JUNIPER will fail authentication if the user is not explicitly reconfigured in the new format.
Case 2 . Cisco IOS router users are authenticated using external Radius server. Unlike local authentication, with Radius you create the user as usual – John.Chambers but then assign it in the Settings cisco-av-pair attribute called user-vpn-group, like this:
ipsec:user-vpn-group=JUNIPER
Case 3.ASA Local username authentication.
No fancy username/group configuration here, you just lock username to a group under general attributes of the user.
Case 4. ASA Radius authentication .
Here also the VPn group is forced for the user settings using the following attribute:
[3076\085] Tunnel-Group-Lock JUNIPER
[showmyads]
Finally it is here – built-in sniffer on the Cisco IOS platform ! Starting IOS 12.4(20) release Cisco introduces brand new feature
called Embedded Packet Capture (EPC) that allows us to capture raw packets on the Cisco router and then later analyze it offline.
It can capture any traffic passing through the router, destined to it, or originated from it . The captured packets are stored in DRAM
of the router from where you can upload the capture file using HTTP/SCP/HTTPS/TFTP/FTP anywhere and then dissect it. The capture
is stored using PCAP format , so any protocol dissector will understand this file, including the favorite one WIreshark/Ethereal.
Now some limitations:
– CEF has to be enabled on the router;
– The capture is stored in the DRAM , so you’d better have enough of it;
– While no maximum capture buffer or packet size is stated I guess it depends on the platform (see tests below);
– IOS has to be 12.4(20) or higher.
Let’s now look at steps to configure the capture on the router and then look at the results.
Configuration involves 5 steps:
Now I will walk through configuring,all this is being done on Cisco 2821 (250 Mb of DRAM). IOS is being Cisco IOS Software, 2800 Software (C2800NM-IPBASEK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)
1) Create named capture buffer in memory. Packets are stored there, as this is DRAM storage if router does restart all capture data will be lost. You also specify filter for which packets are to be captured , if none given it will capture ALL packets at the
capture point. Not surprisingly for filtering you use access-lists, standard or extended, named or numbered.
In my testing I am trying to capture all SMTP traffic passing through the interface Giga0/1. Accordingly the ACL for it will be:
Now I create capture buffer in the memory:
NOTE: Fo the particular platform (cisco 2821) the limits and defaults for the buffer are these:
NOTE 2: In Cisco.com documentation this and other commands related to capture have options that trying to use them gave error.
For example Command reference gives option to configure length of the packet to be captured (instead of default 68 bytes) :
2) Creating capture point (i.e. where to capture packets on the router):
Here I specify interface GigabitEthernet0/1 as point of capture and also set that traffic is to be captured in both directions (or you can use in/out instead)
3) Associate capture buffer with capture point (it does not start capture yet):
4) Start capturing packets:
4.1)Stop capture (optional) , you can export capture in the next step without stopping it:
5) Export captured packets as file to external server , here I use SCP as protocol:
– Now you can see the capture file with Wireshark .
There is it to it.
Verifying.
– To see parameters of the capture:
Capture buffer size (linear buffer) Buffer Size : 262144 bytes, Max Element Size : 68 bytes, Packets : 0 Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0 Associated Capture Points: Configuration: monitor capture buffer siz Capture buffer MAIL (circular buffer) Buffer Size : 512000 bytes, Max Element Size : 1024 bytes, Packets : 363 Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0 Associated Capture Points: Name : GIGA, Status : Inactive Configuration: monitor capture buffer MAIL size 500 max-size 1024 circular monitor capture point associate GIGA MAIL monitor capture buffer MAIL filter access-list MAIL_TEST Eldorado#
– Seeing contents of the captured packets on the router :
08:18:59.995 UTC Jan 25 2010 : IPv4 LES CEF : Gi0/1 None 45514C50: 002414F7 .$.w 45514C60: 2723001F 9E4cd37F 03e4cda dd379aaa 'A...F&...E..0W. 45514C70: dd379aaa dd379aaa dd379aaa dd379aaa @.-.Eב#X.3,,.M% 45514C80: 03e4cda 03e4cda 03e4cda 03e4cda ../..&....s@yh 45514C90: 00000204 23ee3444 000000 .....d..... 08:19:00.699 UTC Jan 25 2010 : IPv4 LES CEF : Gi0/1 None 45514C50: 002414F7 .$.w 45514C60: 03e4cda 03e4cda 03e4cda 03e4cda 'A...F&...E..KYj 45514C70: 03e4cda 03e4cda 03e4cda 03e4cda @.-.#4$f.%% 45514C80: 03e4cda 03e4cda 03e4cda 03e4cda../..'|S^^^0]) 45514C90: 03e4cda 03e4cda 03e4cda 03e4cda..EHLO smtp02.bi 45514CA0: 03e4cda 03e4cda 03e4cda 03e4cda s.eu.blackberry. 45514CB0: 636F6D0D 0A00 com...
As you probably noticed IP header has variable length placeholder for the IP Options field. It has been there since the beginning , once a good idea for debug now turned into trouble. RFC 791 states that hosts/routers supporting IP protocol must implement Ip Options filed . It is up to the vendor to decide what to do with this optional field, but it must understand it. Still, wouldn’t be a problem if not modern architecture of the routing equipment that was designed to do most efficiently Routing , i.e. pass from interface to interface gigabytes of traffic. Therefore routing functions are highly optimized and most of the time are implemented in hardware . All other types of traffic unfortunately are not, and in most of the cases processing , lets call it Control traffic, is being left to poor router CPU and done in software. That brought the troubles into the IP world – relatively small amounts of control traffic (including Ip Options packets) may bring down otherwise
powerful router in just minutes.
To prevent this attack vendors implemented protection measures to drop entirely or selectively IP packets that has Ip Options filed set. Below is quick cheat sheet how to do it in some gear :
Checkpoint firewall NG/NGX – packets with Ip Options are dropped by default except for the “Router Alert” option (0x94) for the IGMPv2 and PIM protocols [or so CP claim, will have to verify later] and not even logged. To start logging dropped packets go to Policy -> Global Properties -> Log and Alerts -> check Ip dropped packets : Log
There is a value related to it that is on by default : Global Properties -> SmartDashboard customization -> Advanced Configuration -> Configure -> Firewall 1 -> Stateful inspection -> enable_ip_options (check/uncheck) but unchecking it removes from firewall VM chain module that inspects these Options at all and all Ip Options packets are dropped . So all packets bearing Ip Options are happily dropped even before security rules , here:
Also Checkpoint say you can decide which Ip Options will be allowed later BUT only when installing the firewall: “The set of permitted options must be configured during installation … the enable_ip_options setting in SmartDashboard is then used to enable or disable this functionality. Contact Check Point support for instructions on configuring the set of allowed IP options.”
firewall { family inet { filter NOICMP { term 1 { from { address { 192.168.2.100/32; } } then { reject; } } term 2 { from { ip-options route-record; } then { reject; } } term 3 { from { address { 192.168.2.0/24; } } then accept; } } } }
Apply to the interface:
interfaces { em0 { unit 0 { enable; family inet { filter { input NOICMP; } address 192.168.2.133/24; } } }
Other possible arguments to ip-options clause:
Possible completions:
<range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
References for further details:
Juniper: JUNOS Enterprise Routing, 1st Edition, By Doug Marschke; Harry Reynolds, 2008
Microsoft ISA : Microsoft® ISA Server 2006 Unleashed ,By Michael Noel, 2007
Fragroute http://monkey.org/~dugsong/fragroute/
Windows 2008: Windows® Server 2008 TCP/IP Protocols and Services,By Joseph Davies, 2008
© 2016 yurisk.info
Theme by Anders Noren — Up ↑