Super-Networking Blog

So as many of you know who have used it in the past netflow is a great tool. Netflow gives you detailed information about traffic flowing through your routers. You can find out what IPs the traffic is coming from and going to, you can see what protocols, what ports and how much traffic is going through that router. Big help if you are trying to find what a traffic spike is or why your Internet connection is maxed out.

Typically you need software to collect the exported netflow data and then compile it into some easy to read form. This software isn’t typically cheap or what if you need it now and don’t have time to install a collector. I will give you the commands you need to get a quick look at the traffic flowing right now.

First thing you have to do is have the router watch the flows:

Under each interface type the command “ip route-cache flow”

Exit the interface config and add the command “ip flow-export version 5” to select a version.

Let is collect traffic for a little bit, shouldn’t impact the performance or your router.

Then to see the traffic break down type the command “show ip cache flow”

This will give you the basic traffic breakdown going through you router. Look at Pkts column to see where the heavy hitters are. When you are down looking at it just leave it running on your interfaces, won’t affect performance and will be in place for when you have a netflow collector installed.

So if you want to limit one or more of your real servers in a virtual server farm to a certain amount of connections you can do it with the “maxconns” command.

Login to the CSM go into config mode, go into the serverfarm you want to restrict then go into the real server. Type in “maxconns #” replacing the # with the max connections you want to go to that real server. This way if you want to test something under real traffic but don’t want it to get slammed you can.

Also if you specify this command it will send out a syslog when the max has been reached.

%CSM_SLB-6-RSERVERSTATE: Module # server state changed: server X.X.X.X:0 in serverfarm ’serverfarm’ has reached configured max-conns

The CSM will then send the rest of the traffic to the other real servers in that serverfarm.

First you need to know what module your CSM is in, most of you know I am sure but otherwise use this at the enable prompt:

“show module”

Next you need to session into the CSM with the following command replacing the slot number with the module number you found using the command above:

“sessions slot 1 processor 0″

Finally you need to tftp the core dump file off of the CSM with the command:

“tftp core_dump tftp-ip-addr”

You need to replace the tftp-ip-addr with the IP of your TFTP server. Also if you have multiple core dump file you can put the name of the file you want to tftp after tftp-ip-addr.

So like most IT security minded people I want to use SSH on everything I can because with telnet your username and password are sent over the wire in clear text. Now I know most of you say well if you are internal what matters it your password is sent in clear text who would be listening? Well a lot of people could be, your boss, your fellow employee in IT, a rouge server, etc…

One thing that you can do to mitigate the threat to to make sure you are switching all your data since a switch doesn’t broadcast most data like hubs do. That still leaves it open to people who have access to the network switches and can sniff your port or the port you are going to. So you can use SSH since it is encrypted and that will protect you. Now not everything supports SSH, both on the software side and on the hardware side. I can’t help with the hardware, if your switch or router doesn’t support SSH either you have to buy a new IOS for it or stick to telnet at your own risk.

As for the software side if you have a program that needs to connect to your network devices over telnet and it can’t be switched to SSH and you really need it listen up.

You can use the access-class command under line vty 0 4 to lockdown what IPs have access to SSH or Telnet.

Example Commands:

ip access-list extended vty
permit tcp host 10.10.0.5 any eq telnet log
permit tcp any any eq 22 log
deny tcp any any log

line vty 0 4

access-class vty in

transport input telnet ssh

So that ACL would allow 10.10.0.5 to telnet to the network device and anyone to SSH. FYI that older versions of the IOS don’t allow you to use extended ACLs so you would only be able to determine IPs not ports/services.

There are two major Denial-of-Service (DoS) advisories out today.

Cisco IOS SSL Vulnerability

Affects:

Cisco Crypto Library Vulnerability

Affects:

The U.S. Computer Emergency Response Team (US-CERT) has reported a network evasion technique using full-width and half-width unicode characters that affects several Cisco products. The US-CERT advisory is available at the following link:

http://www.kb.cert.org/vuls/id/739224

By encoding attacks using a full-width or half-width unicode character set, an attacker can exploit this vulnerability to evade detection by an Intrusion Prevention System (IPS) or firewall. This may allow the attacker to covertly scan and attack systems normally protected by an IPS or firewall.

This response is posted at the following link:

http://www.cisco.com/warp/public/707/cisco-sr-20070514-unicode.shtml

The Cisco IOS FTP Server feature contains multiple vulnerabilities that can result in a denial of service (DoS) condition, improper verification of user credentials, and the ability to retrieve or write any file from the device filesystem, including the device’s saved configuration. This configuration file may include passwords or other sensitive information.

The IOS FTP Server is an optional service that is disabled by default. Devices that are not specifically configured to enable the IOS FTP Server service are unaffected by these vulnerabilities.

This vulnerability does not apply to the IOS FTP Client feature.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070509-iosftp.shtml.

Cisco confirms the memory exhaustion vulnerability as per the advisory published by CERT/CC and confirms this vulnerability impacts the PIX and ASA appliance for system software 7.2 only. Exploitation of the vulnerability may lead to a Denial of Service condition against the appliance.

The Firewall Services Module (FWSM) is not affected by this vulnerability.

PSIRT would like to thank Grant Deffenbaugh and Lisa Sittler from the CERT/CC for reporting this vulnerability to Cisco.

We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in security vulnerability reports against Cisco products.

Full Article

I have been seeing some “Critical Syslog Events” coming through lately from my Cisco FWSM (Firewall Switch Module). The event number is FWSM-2-106017 or if you have a PIX it would be PIX-2-106017.

When you go to Cisco’s site for the explanation this is what they give you:

Error Message    %FWSM-2-106017: Deny IP due to Land Attack from IP_addr to IP_addr

Explanation    This message indicates that the module received a packet with the IP source address equal to the IP destination and the destination port equal to the source port. This indicates a spoofed packet that is designed to attack systems. This attack is referred to as a land attack. If this message persists, an attack may be in progress. The packet does not provide enough information to determine where the attack originates.

Recommended Action    None.

This is fine and dandy but doesn’t help me track down what the problem is. I don’t believe this is truly a lan attack since it only seems to happen when the Sysadmins are working on this box. The IP it is coming from is a web server and this web server has an internal IP and a natted external IP. When changes are made you want to test the website. So you go the website on the server it resolves to the natted IP which goes out through the firewall hits the router then is converted back to the internal IP and sent back through the firewall. This is where the Land attack comes in because the traffic is coming from  the same IP it is going to and on different interfaces on the firewall.

I haven’t seen a fix for this, you could probably disable this rule in the firewall or just make sure you got to the internal IP instead of the natted IP when testing from the web server itself.