Cisco | IPNET - Part 11

How to protect your network and users with not additional costs

One of the biggest problems in today’s network security is users surfing on the Internet. I’m not against offering Internet access at work place or schools, for example, but I believe that some measures should be taken by the network administrators to limit the users from being able to access (intentionally or not) the webpages with threatening content (hijack, malware, spyware and so on…).

If big corporation have the money to invest in security development and devices, than the SOHO business would rather invest those money in something else. Sometime ago, I was having in my home a small network meaning on one PC and a notebook in my apartment and some few devices in other friend flat from the same building. Since the other partners that I was sharing the network with, where not so familiar with the bad things on the Internet, I had to come with a solution to limit the monthly problems with strange software being installed on their PCs after a night of web surfing. You know what I talking about, right? Nice banner pop-up, user click on it then something like spyware getting installed on his/her device.

Instead of investing in some firewalls, or configuring a Linux machine to filter traffic, I let some smart machines to filter my traffic: Domain Name Servers. So, I arrived at opendns.com. Free service that let you use their NS services, provide you with stats and filtering. Exactly what I needed. From that point everything was easy. I announced their NS IP addresses in my home network from our Cisco router through DHCP as default DNS servers, and I was protected. I assume that you also have a Cisco device, but if not, please have a look here where you might find your device and how to configure it.

One note has to be mentioned, before I invite you to see the tutorial below. OpenDns.com stated clear in their Terms of Use, that their services are for home users. So, if you have so kind of small or medium business, please send ask them before you use their service as explained below.

Please click on the image below to see the presentation:

Cisco: TCP and UDP small servers

Do you like Linux with all this services that you can enable on the fly when you want to test something? I know that I really like Linux boxes. But what about Cisco? Well Cisco supports also some services to be enabled for testing purposes. This are called “TCP and UDP small servers”.

Maybe I should start by telling you that there are never ending discussions about this servers, whenever they should be enabled and how to protect the access to them, since this is still an open security issue which can attract and attacker. In my opinion you cannot keep them close and also running some tests (that require certain ports to be open) in the same time, but let open access to them is not a solution either. So, what can you do, is to enable TCP and UDP small servers only when you need them for testing and then disable these services. Another solution that I see, is to let this services all the time enabled, but to use some security tools (e.g. access-lists on external ports) to reduce the amount of hosts that can access them. In this way you let them accessible only for the hosts from where you want to be. And the third solution is not to enabled them at all, but then you cannot test anything. It’s like the story when a computer is safe? When you destroy the hard-drive and look the device into a safe. Good, the computer is secure, but you cannot use it anymore, so what’s the point of doing this?

But back to our discussion, TCP and UDP small servers are servers (strange phrase, I know) that run in the router which are useful for diagnostics.

TCP small servers:
Echo: Echoes back whatever you type through the telnet x.x.x.x echo command.
Chargen: Generates a stream of ASCII data. Use the telnet x.x.x.x chargen command.
Discard: Throws away whatever you type. Use the telnet x.x.x.x discard command.
Daytime: Returns system date and time, if it is correct. It is correct if you run Network Time Protocol (NTP), or have set the date and time manually from the exec level. Use the telnet x.x.x.x daytime command.

UDP small servers:
Echo: Echoes the payload of the datagram you send.
Discard: Silently pitches the datagram you send.
Chargen: Pitches the datagram you send, and responds with a 72-character string of ASCII characters terminated with a CR+LF.

In addition to the one above, the Cisco devices also offers finger service and async line bootp service, which you can independently turn on / off.

For this presentation I will use 2 point-to-point connected routers named RT-TEST-CLIENT (10.0.0.2 /30) and RT-SERVERS-ENABLE (10.0.0.1 /30). I will enable TCP and UDP small servers on one of them and test from the other one. Please click the image below to see the video presentation:

If you cannot see the Flash movie above please consult this text document which explain how to enable TCP / UDP small server and how to test them.

Cisco: How to configure Frame-Relay Hub and Spoke in simple steps

Some days ago, during my preparation for CCIE RS I had to configure Frame-Relay Hub and Spoke environment. Since I already did it, I said that is good to have it here also, maybe somebody will find it useful. Even if it sounds quite complicate as title, FR hub and spoke. This post assume that you are somehow familiar with Frame-Relay concept and you know basic stuff. If you need to refresh your knowledge there is good topic about Frame-Relay on Ciscopress page.

So, what is this FR hub and spoke anyway? A basic example is with 3 device (can be more) in which on of them connect the other ones in a central point. This is the opposite to (full or circular) mesh in which every router is connected with at least another 2 devices. For things to be more clear please have a look to this topology file.

As you can see in the topology provided, R1 is connecting the other 2 routers in a central point. R1 device is the Hub and R2, R3 are the Spokes. Like explained in the topology, the green lines represent PVC circuit and red ones the physical connection. The communication between R2 and R3 will be done only through R1 since there is no PVC that connect this 2 devices. You can be tempted to say that the communication is direct, because red lines have a common point in the FR switch, but the things are not like this. This is not Ethernet, so for L3 to work you need a map from L2 to L3. Since there is no PVC define in FR switch for R2 to R3 communication, everything is passing through R1.

To configure Frame-Relay Hub and Spoke is not very difficult. The most hard part is regarding FR switch, but luckily you don’t have to deal with it, as this is usually a provider equipment, and they will do the L2 to L3 frame-relay routing, providing you with the need DLCI information. From this point you only have to be careful to details (IP, DLCI, interface) when configuring frame-relay map on your devices.

In a future post I will extend this topic and show how you can configure OSPF in a Frame-Relay Hub and Spoke environment. For now please check this topic presented in the tutorial below:

If Flash movie is not available for you, then please check this text file which contains the configuration.

Cisco: How-to get notifications for IP SLA monitor using EEM

In some previous post, I explained how to configure a basic IP SLA monitor for checking the round-trip time between two Cisco routers. Because in the comments of that post I have been asked how you can get e-mail notification for IP SLA monitor, I have decided to write another post to extend a little bit this topic.

To accomplish e-mail notification for IP SLA monitors we will use Embedded Event Manager (EEM) and some SNMP knowledge.Cisco IOS EEM is a powerful device and system management technology integrated into specific Cisco switches and routers. EEM gives us the ability to customize Cisco IOS behavior based on network events as they happen.

EEM will use a SNMP event to report anomalies in regarding the RTT threshold value. For SNMP to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name: rttMonCtrlOperOverThresholdOccurred (OID: 1.3.6.1.4.1.9.9.42.1.2.9.1.7). On Cisco website you can find more about this SNMP Object and I advice you to read it before going on with this tutorial.

Below you have a basic example about how to get e-mail notification when the threshold of the RTT IP SLA monitor is reached. More examples you can find on Ivan Pepelnjak’s blog: blog.ioshints.info . It’s a good idea to check them also.

The topology remains the same like in the previous post about IP SLA. You can check it here. Please click below to check the tutorial:

If you cannot check the tutorial above, please read this text file, as it contains all the information from the video presentation.

Cisco: 6 best practice security tips for BGP

As we all know, in today’s digital communication world, there is a very big possibility that your network is or was target for a malicious activity. BGP is one of the most targeted routing protocols when we are talking about network attacks.Why? This is quite simple. BGP is your connection to the exterior world (peer networks, Internet and everything which is outside your LAN/MAN), so it is somehow normal to be the main target of the conducted attacks. If in case of the WWW, DNS, E-mail services we can say that maybe an attack was not intentionally made (e.g. a user got infected with some trojan/malware/botnet tool that is attacking random destinations), in the case of BGP, you can be 90% sure that this is an intentionally conducted attack. The main scope of a BGP attack is to flood the network with false information (e.g. false network prefixes) in this way trying to direct interesting traffic to special destinations where this can be sniffed and decoded.

I will present here 6 tips that I’m using the most to protect BGP against malicious information. This is really easy to implement, if you have any basic idea about how to configure BGP protocol, but it can save you from hours of troubleshooting and investigation.

1. Limit the maximum number of prefixes that you learn from BGP peer, to avoid overload of your machine.
2. Deny updates that include a private AS number in the AS Path (64512 – 65535).
3. Use ACLs on your external interface to permit input/output BGP packets only from your defined source and destination
4. Limit TTL in BGP packets to limit the communication only with next-hop peers.
5. Use a password to authenticate peer neighbors.
6. Limit the maximum length of the AS path

Also here I would like to mention, not necessary as a security tip, but more like a best practice, enable when it is possible logging. This can help you to observe some strange behavior that occur on your machines where you are not arround them.

There is no topology present for this tutorial, but we will assume that we have a point-to-point serial connection between 2 routers, R2 (10.0.23.2) and R3 (10.0.23.3). Please click the image below to view the tutorial:

If for some reasons the tutorial above is not available for you, please check this text file which present in text mode everything needed to implement BGP security tips presented above.