Nov 6

URL Filtering using IOS

Posted by Radu

Today, while I was trying to keep my students awake during a CCNA1 presentation I noticed that two of them were looking at 9Gag and they ignored me. Not that I was saying something so deep and meaningful but it was a little bit frustrating for me. So, as soon I finished my presentation, I opened a console to the local router (a Cisco 2821 ) and began to filter 9gag.

Obviously you cannot do that with ACLs when you want to filter a website running on multiple addresses like 9gag. Even if you use hostname instead of an IP address, that hostname is resolved once using dns servers defined in your configuration and that’s it.

So I used a policy and five minutes later those two were the frustrated ones. This is how I did it :

!
class-map match-any URLFILTER
    match protocol http host *9gag.com
!
policy-map DROPURL
    class URLFILTER
      drop
!
!
interface FastEthernet 0/1
    desc Internal
    service-policy input DROPURL
!

And that was it. Next time, facebook, prepare your url, I wanna filter you.

Or, using CBAC (Context-Based Access Control) :

!
ip inspect name WEBFILTER http urlfilter
ip urlfilter allow-mode on
ip urlfilter exclusive-domain deny .9gag.com
!
!
interface FastEthernet 0/1
   desc Internal
   ip inspect WEBFILTER in
!

Oh, and if you’re wondering how to do url filtering with linux the answer is “it’s complicated”. You need either a proxy (squid, privoxy) or, if you are shameless, you can do it using DNS hijacking.

Mar 30

Securing a router or a switch involves not only filtering traffic with ACLs, but also means securing the device itself. Creating users with certain privilege levels is an important first step.  This can be done on a device by device basis or using a centralized authentication server. In any case, it involves using AAA (Authentication, Authorization and Accounting).

If using a centralized system for user authentication, the router or switch would be an authentication client. It will need to communicate with a server using a specialized protocol. Two such protocols are wide known: TACACS, a Cisco proprietary protocol and RADIUS, an open standard protocol. In a Cisco-centered  network, IOS authentication would work with Cisco’s ACS (Access Control Server), but in some cases , specially for lab purposes, ACS could be harder to get an setup.

A very quick way to setup an authentication server is to use FreeRADIUS, an open source server that uses the RADIUS protocol. It can be easily installed on a Linux box and used with minimum configurations. Here are the steps to setup:

Install the packet:

root@radiusserver# apt-get install freeradius

Add each client (router or switch) in the /etc/freeradius/clients.conf file. Each client is identified by its hostname and requires a password (secret).

root@radiusserver# vim /etc/freeradius/clients.conf

Client 192.168.0.2
{
secret = authentications3cr3t
shortname = ClientRouter

}

Add each user that is allowed on the device.

root@radiusserver# vim /etc/freeradius/users.conf

iosuser Cleartext-Password := “icanhazroot”
DEFAULT Auth-Type := Reject

Start or restart the FreeRADIUS server:

root@radiusserver# /etc/init.d/freeradius restart

On the client side (the network device), AAA needs to be enabled, the RADIUS server configured and then the authentication need to be set to use an external server.

ClientRouter(config)# aaa new-model
ClientRouter(config)# radius-server host $RADIUS_SERVER_IP auth 1812 acct 1813 key authentications3cr3t
ClientRouter(config)# aaa authentication login default group radius

This is a basic configuration of a FreeRADIUS server, but it can also provide features like LDAP intergration.

Jul 18

Frame Relay Switching

Posted by Alex Juncu

Frame Relay is still very much a popular subject in exams, labs and in the real networks.

Any lab with topologies that run different protocols over FR must start with the layer 2 configuration of the Frame Relay switched network. FR Topologies like full mesh or hub and spoke require a Frame Relay Switch. A FR Switch is a normal router but specifically configured to do Frame Relay switching.

First of all, we need to tell the router to start switching Frame Relay traffic. From global configuration mode we need to issue the frame-relay switching command.

Then, on the interfaces to Frame Relay clients, we need to start sending keepalives (LMIs) by configuring the interface as DCE with the frame-relay intf-type dce command.

The last thing that the FR Switch needs to do is to route DLCI on the virtual cicuits. This is done to tell an interface where to put a received frame with a DLCI. The frame will be put on another interface with another DLCI.  The configuration is done per interface with the frame-relay route command. The command requires that you specify the incoming  DLCI, on which the switching decision will be maide, the outgoing interface, and the DLCI with which the frame will be sent (”freame-relay route IN_DLCI OUT_INT OUT_DLCI”).

If Inverse ARP is not disabled on the FR Switch, no DLCI-IP mappings will be required.

Topology:

fr_sw

Configuration:

R1(config)#int s0/0
R1(config-if)#no shut
R1(config-if)#encapsulation frame-relay
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0

R2(config)#int s0/0
R2(config-if)#no shut
R2(config-if)#encapsulation frame-relay
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0

FR-Sw(config)#frame-relay switching
FR-Sw(config)#int s0/1
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 102 interface s0/0 201
FR-Sw(config-if)#int s0/0
FR-Sw(config-if)#no shut
FR-Sw(config-if)#clock rate 128000
FR-Sw(config-if)#encapsulation frame-relay
FR-Sw(config-if)#frame-relay intf-type dce
FR-Sw(config-if)#frame-relay route 201 interface s0/1 102


Running Configurations:

R1:

interface Serial0/0
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

R2:

interface Serial0/0
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
clockrate 128000
no fair-queue
end

FR-Sw:

interface Serial0/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay intf-type dce
frame-relay route 201 interface Serial0/1 102
end

interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 102 interface Serial0/0 201
end

Jul 18

Back-to-back Frame Relay

Posted by Alex Juncu

This is the simplest use of a Frame Relay encapsulation and it’s between two routers, without a Frame Relay Switch. PPP or HDLC would make more sense to use in these types of links, but it is useful in labs.

In a back-to-back scenario is important to remember what the FR Switch should be doing: being the DCE and sending the keepalives to maintain the layer 2 link to the client router. Because of the fact that no FR Switch is present, the lack of keepalives being sent must be ignored using the “no keepalive” command. Also, Inverse ARP won’t work, so manual IP-DLCI mapping will be needed.

The FR Switch should be the one doing swapping of DLCIs on the network so the frames arrive at their destination with the correctly mapped DLCIs. In this case, we will need to have the same DLCI set in the manual mapping so the routers match entries in the mappings.

The topology:

fr_b2b

Configuration:

R1(config)#int s0/1
R1(config-if)#no shut
R1(config-if)#clock rate 128000
R1(config-if)#ip address 10.1.2.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay map ip 10.1.2.2 42
R1(config-if)#no keepalive

R2(config)#int s0/1
R2(config-if)#no shut
R2(config-if)#clock rate 128000
R2(config-if)#ip address 10.1.2.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay map ip 10.1.2.1 42
R2(config-if)#no keepalive

Running configurations:

R1:

interface Serial0/1
ip address 10.1.2.1 255.255.255.0
encapsulation frame-relay
no keepalive
clockrate 128000
frame-relay map ip 10.1.2.2 42
end

R2:

interface Serial0/1
ip address 10.1.2.2 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 10.1.2.1 42
end

Jun 11

Basic packet crafting

Posted by Dragos Draghicescu

Ok, this will be a short one :) . I just want to raise attention on how can one bypass an extended (or standard) ACL (or access-list).

So, for this example, i have one router with an IP address of 10.10.10.2, which can be accessed only by the admin, only from 20.20.20.20. That is done with an inbound ACL, put on the egress interface of the router. Looks like this:

Extended IP access list 111
20 permit ip host 20.20.20.20 host 10.10.10.2 log

There is a little problem with spoofing: the return traffic has to be routed back to the attacker. But everything will work just fine if you happen to be in the same network with the admin (you can achieve bidirectional communication). In case the attack is done over the Internet, there is still the possibility of a DOS (Denial Of Service), by sending tons of packets that will be accepted. I assumed another thing: your ISP does not check for the source of the packets (DOS attacks are less frequent if that simple measure is taken).

For the demonstration, i chose a well-known packet crafter named HPING3. It allows one to customize a packet at different layers and it`s well documented, but for now we will only use a fraction of it`s power:

$ sudo hping3 -S 10.10.10.2 -a 20.20.20.20

The result could be:

*Mar 1 05:52:01.702: %SEC-6-IPACCESSLOGP:
list 111 permitted tcp 20.20.20.20(0) -> 10.10.10.2(0), 360 packets

To check the amount of pings, you can issue the command “show ip traffic | section ICMP“. You can “clear ip traffic” before that.

Despite this, ACLs are still adding a serious amount of security to your network. But in front of a determined attacker, one should do more than that in order to have a healthy network.

Nov 4

In labs we use reverse telnet to access our equipment (as in “routers and switches”) directly into console. To make things a little bit easier for our students we created a web page with “telnet://” links pointing directly to each router/switch.
That should be enough to solve all those pesky little questions like “what was that address again ?”. And it is. At least when the computer used by our students is running Windows. But we do have a little problem because all our computers in the lab are running Ubuntu. And Firefox. And it appears that Firefox in Ubuntu doesn’t know how to handle “telnet://” links.

I solved the problem by installing Opera browser and add the telnet handler in Opera. Or even better, install Opera and Putty and use Putty to handle “telnet://”. But the problem with Firefox kept bugging me and even if I’m lazy i knew that it became personal.
So I started to search the allmighty internet. I found out that I can add telnet protocol in user prefs in Firefox. But it didn’t work. So I kept searching and finally I’ved put the bits and pieces together and solved the problem. Here it goes.

First thing to do is to tell Firefox that we WANT to use telnet:// links. To do that we must open Firefox and type “about:config” in address bar. And we create a new boolean preference (right click on an empty space), name it “network.protocol-handler.expose.telnet” and set the value “false” and restart the browser. That should be enough for Firefox to let us select an external application to open “telnet://” links.
From this point forward we can choose the easy way and choose putty or the hard way and use gnome-terminal/xterm/konsole. The “hard way” because telnet in terminal doesn’t know how to handle “address:port” format. So how should we do that ? Simple, we create a shell script and we use that script as the default application to open “telnet://” links in Firefox.

The script is pretty easy :


#!/bin/sh

address=`echo ${*##telnet://} | sed 's/:/ /g'`

#For xterm junkies :
xterm -e "telnet $address"

#For gnome-terminal users :
#uncomment the next line but comment
#all other terminal launchers (xterm, konsole)
#gnome-terminal -e "telnet $address"

#For konsole hipsters :
#konsole sends args separately to command so we use "" only for telnet
#uncomment the next line but comment
#all other terminal launchers (gnome-terminal, xterm)
#konsole -e "telnet" $address

And voila, sit back, relax and enjoy a cold beer…

Nov 3

Run remote procedures & GNS3

Posted by Dragos Draghicescu

An interesting and pretty new capability of Cisco IOS is scripting through TCL language. What is not that well documented is that you can configure a router in some situations and the interesting thing is that you can store the configuration procedure remotely, like on a tftp server for example. What I will present may be useful in lab environments, for simulation purposes. I used it to prepare a huge exercise for the CCNA 2 class.

First of all, I will suppose that you have configured a tftp server somewhere in your LAN. Second thing is you can configure a bridge between your Ethernet interface and a tap interface (a virtual interface, for use with the emulated router). In Linux, you can use the Bridge-utils and uml-utilities to do that. You can find a tutorial on how to do a bridge <here>.

Now lets get to work! :)

In GNS3 (ran as root) you have to link the router with a clouds tap interface. In the cloud configuration panel, add a tap interface into the NIO tap tab (lets say tap0). Next, configure the router interface IP address like its part of your LAN. You can ping your gateway to verify that.

It’s all said and done. The script I wrote reads a number of Loopback interfaces to be configured from the user input. The output looks like this:

IOS output

IOS output

The output is incomplete, but the script configured Loopback 0 to 4 with ip addresses.

I hope some will find what can be done with IOS TCL pretty interesting.

Good luck!

DD

Aug 19

Like most CCIE Lab stories, this one starts with a way to access the consoles remotely – a terminal server. In my case, a Cisco 2811 with a NM-16A module (and a CAB-OCTAL-ASYNC breakout cable for connecting 8 routers).

I have had the opportunity to work with terminal servers many times before (including the actual CCIE lab) – but they were always configured by other people. This time, I had to configure the TS myself. No problem, I say…

TS(config)#int lo0
TS(config-if)#ip add 192.168.1.1 255.255.255.255

!--- line numbers may vary depending on module
!--- use "show line" to determine the numbers in use
TS(config-if)#line 66 81
TS(config-line)#transport input all

!--- Optional
TS(config-line)#flowcontrol hardware

!--- Optional, but it makes accessing the devices easier
TS(config)#ip host r1 2066 192.168.1.1
TS(config)#ip host r2 2067 192.168.1.1
TS(config)#ip host r3 2068 192.168.1.1
TS(config)#ip host r4 2069 192.168.1.1
TS(config)#ip host r5 2070 192.168.1.1
TS(config)#ip host r6 2071 192.168.1.1
TS(config)#ip host r7 2072 192.168.1.1
TS(config)#ip host r8 2073 192.168.1.1

Looks good, and I can now access the devices by telnetting to the various ports on 192.168.1.1. Yet something is wrong… The lines become busy at random intervals, which makes the terminal server refuse connections. A “clear line” solves the problem, but only for a very short time – just seconds later, the line becomes active again.

TS#sh line
   Tty Line Typ     Tx/Rx    A Modem  Roty AccO AccI  Uses  Noise Overruns  Int

*   1/6   72 TTY   9600/9600  -    -      -    -    -     3   1448  447/1343   -
*   1/7   73 TTY   9600/9600  -    -      -    -    -     5    129   62/188    -

TS#r1
Translating "r7"
Trying r7 (192.168.1.1, 2072)...
% Connection refused by remote host

After several hours of frustration (clearing lines just to have them become busy again almost immediately), I realize what I forgot:

TS(config-if)#line 66 81
TS(config-line)#no exec

The explanation? Any kind of noise on the wire was interpreted by the TS as an incoming character. As a result, the TS would activate the line, opening an exec session. A “clear line” would close the session, only to have it opened again by the noise.

As somebody else put it – “‘No exec’ isn’t mandatory, but it will help you keep your sanity!”