Posted: February 14th, 2010 | Author: charlie | Filed under: Networking, Security | Tags: ccna, cisco, networks, Security | No Comments »
Another new feature available in IOS (12.3) is Cisco’s Intrusion Prevention System. An IDS has been part of IOS for a long time, but they recently took it a step further. As part of its Self-Defending Network campaign, Cisco realized that an IPS should be integrated into the network fabric. We’ll explain what this means, and show you how to implement it.
Actively preventing the attack makes it an IPS. The standard old IDS solution means that it can detect and alert, but blocking attacks is not normally part of an IDS’s feature set. Thus, if you want to prevent attacks rather than just receive alerts, you need an IPS. Cisco’s IPS works like any other: you get a signature file, called the Signature Definition File (SDF) by Cisco, and if the IPS finds that a packet matches a signature, it’s blocked.
There are appliances, Catalyst switch modules, and router modules, but IPS is also built-in to certain IOS images now. Since Cisco claims IPS features won’t impact router performance (since the latest release), it may be possible to skip the purchase of a dedicated module for IPS.
The catch, of course, is that an IPS is not robust without constant signature updates. Attacks are constantly evolving, and without an update you aren’t protected against the latest and greatest attacks. Something completely new could sneak in, but the idea is that after the first few attacks Cisco will update the SDF and you’ll be notified that it’s time to download a new version. That’s right, you have to manually download and install a new signature file. This requires a subscription service above and beyond what you pay for SMARTnet. Services for IPS, as it’s called, provides SDF updates and the other features (support, warranty) that SMARTnet does as well. Accordingly, your SMARTnet contract is discounted when you purchase a Cisco Services for IPS contract, according to Cisco’s Q&A documentation.
Configuring IPS for Sensor Modules
There are many different cases for configuring IPS depending on your device. First, we’ll show you how to enable it on any IPS sensor module that uses the IPS 5.1 or later, then we’ll show you how to take advantage of the IOS built-in default IPS features.
The IDS Device Manager (IDM) is a graphical interface for configuring all IDS (and IPS) functionality. If you prefer that, then refer to the Cisco documentation after reading about how it’s done via the CLI here.
The general idea we’re working with here is called the VLAN pair method. This means that we’ll configure two VLANs in a pair group, and all traffic received by a sensor will be inspected and either forwarded on to the other VLAN, or dropped. Up to 255 VLAN pairs can be configured on most sensors.
First we enter configuration mode, then the service interface, and finally select the physical interface that we wish to configure:
sensor#configure terminal
sensor(config)#service interface
sensor(config-int)#physical-interfaces GigabitEthernet0/1
Next, we must configure the VLAN pair (and give it a meaningful description):
sensor(config-int-phy)#subinterface-type inline-vlan-pair
sensor(config-int-phy-inl)#subinterface 1
sensor(config-int-phy-inl-sub)#vlan1 10
sensor(config-int-phy-inl-sub)#vlan2 11
sensor(config-int-phy-inl-sub)#description vlans 10 and 11
Conceptually, the interface will now be added to a virtual sensor, and once it’s enabled it will monitor traffic. We now need to enable a virtual sensor:
sensor(config)#service analysis-engine
sensor(config-ana)#virtual-sensor vs0
Once that’s completed, we simply add the previously-defined subinterface to the sensor, and we’re done:
sensor(config-ana-vir)#physical-interface GigabitEthernet0/2 subinterface-number 1
Configuring IPS for IOS
You can enable IPS features in IOS using the default SDF. Signatures may be added manually to the SDF, or you can pay Cisco for the latest signatures.
First we need to enable what’s called Security Device Event Exchange notifications:
router(config)#ip ips notify sdee
Then we must configure an IPS rule name that will be used for associating with interfaces.
router(config)# ip ips name MYIPSRULES
The next step is to specify where the SDF file will come from. The following command specifies that the file 256MB.sdf can be found in flash memory. You can also specify tftp or any other protocol your Cisco knows how to handle, but it’s best to use flash memory to ensure no dependencies on other servers.
router(config)# ip ips sdf location flash:256MB.sdf
Finally, we simply enable IPS on the interface (in both directions). It is also a good idea to enable IP reassembly on the interface, so that the IPS rule can evaluate entire IP packets at once.
router(config)#interface fastEthernet 0
router(config-if)#ip ips MYIPSRULES in
router(config-if)#ip ips MYIPSRULES out
router(config-if)#ip virtual-reassembly
Now you have a working IPS, based on the file in your flash called 256MB.sdf. That file must be downloaded from Cisco using your CCO login linked to a valid support contract.
The Power of Community
If you don’t feel like paying Cisco for signature updates, you can update the SDF yourself. When a new attack surfaces, you’ll often find Cisco IPS XML signatures posted to various online forums. You can and should use them.
To view your current SDF version, you can run: sh ip ips signatures
To merge the IPS SDF configuration with new information, you can copy in an XML file. Just like copying in any configuration snippet, the updates will be merged, not replaced. Say we got sigs.xml from a helpful network operator. To enable these signatures, we simply run:
router#copy tftp://serer.fqdn/sigs.xml ips-sdf
That’s it! You’ll see that 256MB.sdf on the flash memory is now a bit larger. It’s a good idea (and is recommended by Cisco) to rename 256MB.sdf to avoid confusion, now that you are no longer running a Cisco-sanctioned version.
Enabling IPS on supported routers is quite easy, but can lead to some interesting troubleshooting sessions. Be sure you have a syslog server that your routers all log to: it will save hours of work. Also, search around; you may find a source for XML updates that you wish to trust, and then it’s pretty easy to automate daily merges into your local SDF.
No Comments yet... be the first » Related posts:
- Manage Devices and Configurations with Cisco SDM
- Are Cisco Flex Links the End of STP?
- Cisco AutoQoS: VoIP QoS for Mere Mortals
- Multi-user Security in Linux
- What the Heck is a TCAM?
Posted: February 14th, 2010 | Author: charlie | Filed under: IT Management, Linux / Unix, Networking | Tags: linux, monitoring, networks, NMS | 16 Comments »
Another perfect example of open source software gone commercial is Zenoss. As a full-featured network and service monitoring solution, Zenoss is one of the best monitoring tools available.
Most importantly, Zenoss combines two functionalities. First and foremost an enterprise environment requires host and service monitoring, with notifications. Network monitoring really means checking services, checking that hosts are up (they ping), and possibly writing your own plugins to check various other aspects of a server or network device. Until now, Nagios has filled that role.
Second, once a decent monitoring solution is in place, getting time-based information becomes desirable. Memory and CPU usage is the most prevalent example: if you’re checking available swap space every so often with Nagios, you may know when you start running low. But it may be just as important to see a graph of the last week’s usage. Tools like Cacti or Munin, which collect data frequently and use RRD graphs to display it, are very useful.
Zenoss fills both roles, without the annoying shortcomings prevalent in the alternative solutions. Zenoss uses the terms Availability Monitoring and Performance Monitoring to describe these two fundamental roles.
Performance of monitoring tools is important, and often times overlooked until it becomes a debilitating problem. For example, if you want to chart pretty RRD graphs of systems statistics like available RAM or disk space, Munin is an option. Unfortunately it’s all Perl, and designed in such a way that prevents it from scaling to even moderate amounts of hosts. Cacti is a bit better, but monitoring close to 100 hosts is painful with either option. Along comes Zenoss.
Zenoss is written in Python, and uses a MySQL backend for storage, and by all accounts it appears to perform very well. The really great thing about corporate-backed open source is quality control. The community simply isn’t responsible enough to say, “No, this won’t work, re-implement it.” A company with QA is.
Speaking of features, Zenoss isn’t missing many. Flexibility seems to be top priority–it can monitor hosts with SNMP, Nagios agents, SSH, Windows WMI, and various other mechanisms. Many features they claim are a bit over-inflated, such as ZenPing (marketed as Network Topology Monitoring) but the feature set is rich nonetheless.
Zenoss’s primary functions involve four features:
- Inventory Tracking
- Availability Monitoring
- Performance Monitoring
- Event Monitoring and Management
Inventory tracking claims some sort of “configuration” reporting as well, but it seems very limited. Zenoss will discover your inventory and auto-populate a database. This is great for knowing which IP addresses are in use, for example, but means that “configuration” reporting is limited to an outside observer’s perspective. It can tell you which servers have a Web server running, but it certainly doesn’t deal with the configuration of the Web server. Of course, inventory tracking isn’t limited to automatically discovered information; there are manual input capabilities too.
Availability monitoring is basically Nagios, plus. It can ping, it can monitor Windows machines, and it can pretty much do whatever you need. Even your old Nagios plugins will work with Zenoss. It does generate reports, but much better ones than Nagios is capable of.
Host monitoring, performance monitoring, or whatever you’d like to call it, is quite robust in Zenoss. Some would think it’s light on features, but there’s a good reason that Zenoss requires you use SNMP: it’s much more scalable than SSH’ing to each server every minute. A bit of up-front configuration is required, in that all your hosts will need SNMP configured and working, but it’s completely worth it. Zenoss too uses RRD graphs, and it can generate events and alerts based on pre-defined thresholds.
Finally we come to event monitoring. Zenoss is also encroaching on Splunk‘s territory a bit. It can combine syslog, availability monitoring alerts, SNMP traps, and even Windows event log data. Much like Splunk, Zenoss correlates similar events for easier viewing and troubleshooting. This is the portion that processes all events and generates alerts to pagers or e-mail, taking into account the escalation procedure you’ve defined.
To top it all off, the Zenoss Web interface is top-notch. It includes a customizable “dashboard” for monitoring, and everything is AJAX-enabled. AJAX provides the user experience similar to Splunk and Google’s Gmail.
Marketing fluff aside, Zenoss really does provide a wonderful product. It is, of course, open source and available for free.
At last year’s LISA conference, Zenoss gave a demonstration that sadly coincided with free beer time. Stumbling in toward the end, I demanded one of their free baseball caps, and sat to listen to the last few audience questions. One thing was very obvious: everyone in the room was excited about this product. If hardcore sysadmins are excited, you know this is something worthwhile.
Zenosss is very functional and full of features. It may even be possible to replace three separate pieces of software with this one product: host inventory database, Nagios, and your performance monitoring tool of choice. Maybe even Splunk some day. We can’t wait to see what features they will be adding next.
16 Comments » Related posts:
- Squeeze Your Gigabit NIC for Top Performance
- Managing Virtual Machine and Cloud Sprawl
- Built-in Security with Cisco IPS
- Back to Basics: Unix System Stats Utilities
- Manage Devices and Configurations with Cisco SDM
Posted: February 13th, 2010 | Author: charlie | Filed under: Networking | Tags: linux, networks, NIC, tuning, windows | 1 Comment »
Many new workstations and servers are coming with integrated gigabit network cards nowadays, but quite a few people soon discover that they can’t transfer data much faster than they did with 100 Mb/s network cards. Multiple factors can affect your ability to transfer at higher speeds, and most of them revolve around operating system settings. In this article we will discuss the necessary steps to make your new gigabit enabled server obtain close to gigabit speeds in Linux, FreeBSD, and Windows.
Hardware considerations
First and foremost we must realize that there are hardware limitations to consider. Just because someone throws a gigabit network card in a server doesn’t mean the hardware can keep up. Network cards are normally connected to the PCI bus via a free PCI slot. In older workstation and non server-class motherboards the PCI slots are normally 32 bit, 33MHz. This means they can transfer at speeds of 133MB/s, but since it is a shared bus between many parts of the computer, realistically it’s limited to around 80MB/s in the best case. Gigabit network cards are 1000Mb/s, or 125MB/s. If the PCI bus is only capable of 80MB/s this is a major limiting factor for gigabit network cards. The math works out to 640Mb/s, which is really quite a bit faster than most gigabit network card installations, but remember this is probably the best-case scenario. If there are other hungry data loving PCI cards in the server, you’ll likely see much less throughput. The only solution for overcoming this bottleneck is to purchase a motherboard with a 66MHz PCI slot, which can do 266MB/s. Also, the new 64 bit PCI slots are capable of 532MB/s on a 66MHz bus. These are beginning to come standard on all server-class motherboards.
Assuming we’re using decent hardware that can keep up with the data rates necessary for gigabit, there is now another obstacle – the operating system. For testing, we used two identical servers: Intel Server motherboards, Pentium 4 3.0 GHz, 1GB RAM, integrated 10/100/1000 Intel network card. One was running Gentoo Linux with a 2.6 SMP kernel, and the other is FreeBSD 5.3 with an SMP kernel to take advantage of the Pentium 4’s HyperThreading capabilities. We were lucky to have a gigabit capable switch, but the same results could be accomplished by connecting both servers directly to each other.
Software considerations
For testing speeds between two servers, we don’t want to use FTP or anything that will require data be fetched from disk. Memory to memory transfers are a much better test, and many tools exist to do this. For our tests, we used ttcp (http://www.pcausa.com/Utilities/pcattcp.htm).
The first test between these two servers was not pretty. The maximum rate was around 230 Mb/s, about two times as fast as a 100Mb/s network card. This is an improvement, but far from optimal. In actuality, most people will see even worse performance out of the box. However, with a few minor setting changes, we quickly realized major speed improvements – more than a threefold improvement over the initial test.
Many people recommend setting the MTU of your network interface larger. This basically means telling the network card to send a larger sized Ethernet frame. While this may be useful when connecting two hosts directly together, it becomes less useful when connecting through a switch that doesn’t support larger MTUs. At any rate, this isn’t necessary. 900Mb/s can be attained at the normal 1500 byte MTU setting.
For attaining maximum throughput, the most important options involve TCP window sizes. The TCP window controls the flow of data, and is negotiated during the start of a TCP connection. Using too small of a size will result in slowness, since TCP can only use the smaller of the two end system’s capabilities. It is quite a bit more complex than this, but here’s the information you really need to know:
For both Linux and FreeBSD we’re using the sysctl utility. For all of the following options, entering the command ‘sysctl variable=number’ should do the trick. To view the current settings use: ‘sysctl ’
Maximum window size:
FreeBSD:
kern.ipc.maxsockbuf=262144
Linux:
net.core.wmem_max=8388608
Default window size:
FreeBSD, sending and receiving:
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=65536
Linux, sending and receiving:
net.core.wmem_default = 65536
net.core.rmem_default = 65536
RFC 1323:
This enables the useful window scaling options defined in rfc1323, which allows the windows to dynamically get larger than we specified above.
FreeBSD:
net.inet.tcp.rfc1323=1
Linux:
net.ipv4.tcp_window_scaling=1
Buffers:
When sending large amounts of data, we can run the operating system out of buffers. This option should be enabled before attempting to use the above settings. To increase the amount of “mbufs” available:
FreeBSD:
kern.ipc.nmbclusters=32768
Linux:
net.ipv4.tcp_mem= 98304 131072 196608
These quick changes will skyrocket TCP performance. Afterwards we were able to run ttcp and attain around 895 Mb/s every time – quite an impressive data rate. There are other options available for adjusting the UDP datagram sizes as well, but we’re mainly focusing on TCP here.
Windows XP / 2000 Server / Server 2003
The magical location for TCP settings in the registry editor is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
We need to add a registry DWORD named TcpWindowSize, and enter a sufficiently large size. 131400 (make sure you click on decimal) should be enough.
Tcp1323Opts should be set to 3. This enables both rfc1323 scaling and timestamps.
And similarly to Unix, we also want to increase the TCP buffer sizes:
ForwardBufferMemory 80000
NumForwardPackets 60000
One last important note for Windows XP users needs to be made. If you’re installed service pack 2, then there is another likely culprit of poor network performance. Explained in knowledge base article 842264, Microsoft says that disabling Internet Connection Sharing after an SP2 install should fix performance issues.
The above tweaks should enable your sufficiently fast server to attain much faster data rates over TCP. If your specific application makes significant use of UDP, then it will be worth looking into similar options relating to UDP datagram sizes. Remember, we obtained close to 900Mb/s with a very fast Pentium 4 machine, server-class motherboard, and quality Intel network card. Results may vary wildly, but adjusting the above settings are a necessary step toward realizing your server’s capabilities.
1 Comment » Related posts:
- How Much Server do you Need?
- Zenoss: We Can Ditch Nagios Now
- What the Heck is a TCAM?
- Understanding Linux Virtual Memory
- Back To Basics: Unix Differences in Performing Tasks
