What Ports Are Open On My Router

What Ports Are Open On My Router?

Erick N. Borgard CCNP

Here is a little trick you can use to find out what ports are open on your Cisco router.  You can use the command show control-plane host open-ports command to see what ports your Cisco router is listening on for connections.  This command will also show if there are any connections presently established.

Internet_RTR#show control-plane host open-ports 

Active internet connections (servers and established)

Prot        Local Address      Foreign Address                  Service    State

 tcp                 *:23                  *:0                   Telnet   LISTEN

 tcp                 *:23    10.10.10.31:49664                   Telnet ESTABLIS

 udp                 *:67                  *:0            DHCPD Receive   LISTEN

 udp                 *:68                  *:0             BootP client   LISTEN

 udp                *:123                  *:0                      NTP   LISTEN

The above output shows the router is listening for connections for telnet, DHCP, BootP and NTP.  We can also see that the router has an established telnet connection from a device that sourced a connection from IP address 10.10.10.31 and a source port of 49664.  The connection was established to the router on the standard telnet port 23.  Using this command could help  to harden the router to prevent attacks.

OSPF Graceful Shutdown

OSPF Graceful Shutdown

Erick N. Borgard CCNP

In this blog post, we are going to look at an OSPF feature called graceful shutdown.  Please consider the following diagram.

Presently, R1 is forwarding packets destined for the loopback of R4 towards R5.  All interfaces on all routers are running in OSPF area 0.  Because OSPF uses the formula Reference BW/Interface Bandwidth to calculate the cost of the link, it seem logical that R1 will, in fact, forward packets to R5 to reach the loopback of R4.  We can confirm this by examining the routing table of R1 for prefix 4.4.4.4.

R1#sh ip route 4.4.4.4

Routing entry for 4.4.4.4/32

  Known via "ospf 100", distance 110, metric 21, type intra area

  Last update from 10.0.15.5 on FastEthernet0/0, 00:05:15 ago

  Routing Descriptor Blocks:

  * 10.0.15.5, from 10.0.45.4, 00:05:15 ago, via FastEthernet0/0

      Route metric is 21, traffic share count is 1

The output above confirms that R1 is using R5 as the next hop to reach R4's loopback and is using route recursion to identify the interface to use when forwarding packets to 4.4.4.4.  That's R1's Fa0/0 interface in this case.

Now let's suppose this is the core of the production network and there is an issue with R5. R5 needs to be power cycled or possibly an IOS upgrade needs to be performed for new features or to bring it up to the same IOS level with the other routers in the OSPF routing domain.  If we just simply powered down R5, that would force the adjacent neighbors to wait for the OSPF dead timer to expire.  Furthermore, the OSPF SPF algorithm would need to be run on R1 to recalculate the SPF tree to reach R4s loopback and all of the other networks in the topology to which R5 is connected. What does that mean to us?  It means that there is a strong possibility that there will be dropped packets in the data plane while OSPF is re-converging.  That's not good.  A better option would be to use the OSPF graceful shutdown feature.  We can force R5 to advertise it's router LSAs with an infinite metric of 0xFFFF to it's neighbors.  This will force it's neighbors to use other LSAs in the database to reach networks that R5 is not directly connected to.

Here is the output of the show ip ospf command on R5 before any changes are made.  Some output will be removed for brevity.

R5#sh ip ospf 

 Routing Process "ospf 100" with ID 10.0.45.5

 Start time: 00:14:11.648, Time elapsed: 00:15:00.240

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Supports Link-local Signaling (LLS)

 Supports area transit capability

 Router is not originating router-LSAs with maximum metric

    Unset reason: unconfigured

    Unset time: 00:23:00.044, Time elapsed: 00:06:11.844

 Initial SPF schedule delay 5000 msecs

Now we can use the command max-metric router-lsa on R5.  We should see that R1 will load balance the traffic over both of the serial links towards 4.4.4.4 instead of using the fast ethernet link connected to R5.  

R5(config)#router ospf 100

R5(config-router)#max-metric router-lsa

Here is the output of R1s routing table for the 4.0.0.0 prefix.

R1#sh ip route 4.0.0.0

Routing entry for 4.0.0.0/8

  Known via "ospf 100", distance 110, metric 129, type intra area

  Last update from 10.0.12.2 on Serial0/0, 00:02:33 ago

  Routing Descriptor Blocks:

  * 10.0.13.3, from 10.0.45.4, 00:02:33 ago, via Serial0/1

      Route metric is 129, traffic share count is 1

    10.0.12.2, from 10.0.45.4, 00:02:33 ago, via Serial0/0

      Route metric is 129, traffic share count is 1

Our configuration can be further clarified by examining the router LSA for the network 10.0.45.5.  This is the network between R4 & R5. 

R5#sh ip ospf database router 10.0.45.5

            OSPF Router with ID (10.0.45.5) (Process ID 100)

                Router Link States (Area 0)

  Exception Flag: Announcing maximum link costs

  LS age: 404

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 10.0.45.5

  Advertising Router: 10.0.45.5

  LS Seq Number: 80000008

  Checksum: 0xD0FA

  Length: 60

  Number of Links: 3

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.0.45.5

     (Link Data) Router Interface address: 10.0.45.5

      Number of TOS metrics: 0

       TOS 0 Metrics: 65535

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 10.0.15.5

     (Link Data) Router Interface address: 10.0.15.5

      Number of TOS metrics: 0

       TOS 0 Metrics: 65535

The output above does show that R5 is advertising a metric of 65535 to reach it's connected link.  We can examine the output of the show ip ospf command on R5 again to further verify the configuration.

R5#sh ip ospf

 Routing Process "ospf 100" with ID 10.0.45.5

 Start time: 00:14:11.648, Time elapsed: 00:34:40.828

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Supports Link-local Signaling (LLS)

 Supports area transit capability

 Originating router-LSAs with maximum metric

    Condition: always, State: active

 Initial SPF schedule delay 5000 msecs

There are a few other options available to the engineer concerning OSPF graceful shutdown.

1. Override the summary LSA metric
2. Override the external LSA metric
3. Set the infinite metric for stub area link
4. Set the infinite metric after a reboot for a specific amount of time.

Multicast Helper Maps

IP Multicast Helper Maps

Erick N Borgard CCNP

Can you remember back when you were studying for your CCNA? One of the concepts you read or heard from an instructor was that routers do not forward broadcast messages.  While that is true, what you  probably didn't read was engineers can use multicast helper maps to translate that broadcast traffic to a multicast address and route those packets via multicast to another broadcast only network.  This lab will demonstrate the use of ip multicast helper maps to carry RIP broadcast routing information over and ip multicast-enabled IP network.  Please see the diagram for more details.

Setup:

Multicast routing is enabled on R2 & R3

OSPF is enabled between R2 & R3

RIPv2 is enabled on R1 & R4 with the loopback and fa0/0 interfaces participating in the protocol

RIPv2 is configured to send version 2 updates as broadcasts on R1 & R4

Note: It should not be implied that RIP is or needs to operate and provide connectivity.  This lab is only to show how broadcast packets destined for UDP port 520 can be translated, routed via multicast, and translated again on another broadcast only network.  RIP is the tool being used in this example because it's easy to see it work with RIP, but the engineer can use whatever port he/she wants to use or use the one outlined in your task and use the response time reporter to test.

Steps to configure multicast helper maps are:

• Configure an ACL to identify the traffic the multicast helper map will use on first and last hop routers
• Configure the routers to forward broadcast traffic destined for specified port number
• Configure the first-hop router to translate broadcast packets to a multicast address
• Configure the last hop router to translate received multicast traffic to the IP directed broadcast address of the link on which traffic needs to be forwarded
• Configure the router to forward directed broadcast on the interface on which the broadcast needs to be forwarded

One thing that tends to confuse people is on which interface the ip multicast helper-map command should be applied.  The ip multicast helper-map command should be applied to upstream facing interfaces. Or more specific, the commandis applied to interfaces facing towards the source of the broadcast traffic that needs to be translated.  In this example, R1 is sending the traffic to be translated to multicast.  So on the first hop router (R2), the command is applied to the LAN interface(fa0/0).  On the last hop router, the command is applied to the S0/0 interface. The best way to remember this is to think about it from the perspective of the router and the direction in which traffic is flowing.  Just keep in mind while looking at this lab that the commands are applied to interfaces pointing towards R1.

In this example, R1 is sending updates as broadcast.  R2 will rewrite the destination address of the packet to the configured multicastaddress 229.0.0.1.  R2 will route that traffic via PIM to R3.  When R3 receives that packet, it will rewrite the destination address ofthe IP packet to the directed broadcast address configured in the multicast helper-map command.  It will then use the ip directed-broadcast command to forward that traffic onto the destination link.

Here are the relevant configurations.

R1

router rip

 version 2

 network 1.0.0.0

 network 10.0.0.0

 no auto-summary

interface FastEthernet0/0

 ip address 10.1.12.1 255.255.255.0

 ip rip v2-broadcast

R2

ip forward-protocol udp rip

access-list 101 permit udp any any eq rip

interface FastEthernet0/0

 ip address 10.1.12.2 255.255.255.0

 ip pim dense-mode

 ip multicast helper-map broadcast 229.0.0.1 101 ttl 5

R3

                                                                                                                                                   

ip forward-protocol udp rip

access-list 101 permit udp any any eq rip

interface Serial0/0

 ip address 10.1.23.2 255.255.255.252

 ip pim dense-mode

 ip multicast helper-map 229.0.0.1 10.1.34.255 101

 ip igmp join-group 229.0.0.1

interface FastEthernet0/0

 ip address 10.1.34.3 255.255.255.0

 ip directed-broadcast

R4

router rip

 version 2

 no validate-update-source

 network 4.0.0.0

 network 10.0.0.0

 no auto-summary

There is one other thing that needs to be addressed.  By default, RIP will perform a sanity check on the source address of the RIP update to ensure that it is part of it's directly connected interfaces.   The packet originated on the 10.1.12.x subnet.  When R4 performs the sanity check, it will not accept/install the route into the routing table.  Note that the above configuration disables these sanity checks with the no validate-update-source command under the RIP routing process.  Once this command is entered, R4 will accept and install the route learned from R1 into the IP routing table.

R4#sh ip route | beg Gate

Gatewayof last resort is not set

     1.0.0.0/32is subnetted, 1 subnets

R       1.1.1.1 [120/1]via 10.1.12.1, 00:00:15

     4.0.0.0/32is subnetted, 1 subnets

C      4.4.4.4 is directly connected, Loopback4

     10.0.0.0/24is subnetted, 1 subnets

C      10.1.34.0 is directly connected, FastEthernet0/0

Here we see that R4 did receive the RIP route from R1 as expected. Obviously we will not have IP connectivity because the nexthop(10.1.12.1) is not reachable from R4.  RIP was only used to show how broadcast traffic is handled with the ip multicasthelper-map command.

TCP Intercept

TCP Intercept

Erick N. Borgard CCNP

In this blog entry, we are going to talk about a feature on the Cisco router called TCP intercept. TCP intercept was designed to help in the prevention of denial of service attacks. Before we get into the example, I think it's very important that some fundamental TCP knowledge be reviewed and some terminology covered.  

First let's talk about how two network devices establish a TCP connection.  Remember that TCP is a reliable protocol so a connection has to be made between two devices in order for them to transmit data.  In order for them to be able to form this connection, a TCP 3way handshake must take place.  The TCP 3 way handshake starts with a client sending a SYN(Synchronize) packet with it's own IP address in the source IP address field.  The server will then return a SYN/ACK packet back to the client acknowledging the SYN packet.  Finally, the client will send the server a ACK packet to complete the 3way handshake process.  From there, the client and server can exchange information.  This is a bit over simplified, but for the purposes of this blog, that is fine.

Now a DoS attack is when an attacker sends a plethora of packets with bogus source IP addresses.  When this happens, the server will reply with a SYN/ACK, but the connection will never complete because the server will never receive the ACK packet back from the source.  This leaves a lot of 1/2 open connections effectively eating up a ton of the server's resources that it could otherwise be allocating to other things.  Ultimately, the server will run out of resources and will cease to be able to provide legitimate services to clients who need them.

Enter TCP intercept.  Cisco provides a feature that allows the engineer to configure a router to act as  a proxy for the server.  Cisco's TCP intercept can run in two different modes.

Intercept Mode - Intercepts all legitimate TCP connections as defined in the ACL.  In this mode, the router will establish a TCP with the client on behalf of the server.  In essence, this is what is I would call a TCP proxy.  The router will respond to TCP SYN packets and will patch the connection between the client and server.  

Watch Mode - In this mode the router will passively watch the TCP connections as they pass between the client and the server.  If the connection does not complete within the configured threshold, the router terminates the connection.

When under a DoS, the router will become more aggressive in it's behavior to protect the network.  By default, the router will allow 1100 connections or 1100 connections in a 1 minute period.  From there it will begin to close the oldest connection attempts received.  In addition, the retransmit interval is reduced by one half.  The router will, by default, drop the oldest connections, but this is easily changed to allow the router to drop random connections instead.  The command to allow the router to drop random connections is ip tcp intercept drop-mode random.  

The two things that the router will use in determining if there is an attack is happening are the following.

• Total incomplete connections
• The number of connection attempts in a one minute sampling period

These value are configurable which gives the engineer more granularity when implementing the security policy for the enterprise.  It is also worth mentioning that the the 2 factors above work together to determine when to become more aggressive and when to become less aggressive by the thresholds defined by the engineer.

Now that we have reviewed the basics of how a TCP 3way handshake functions and what a DoS attack is and how a SYN flood operates, we can look at an example.

In this example there will be a web server that will be simulated at R2.  It will be simulated with a loopback interface with IP address 155.2.2.2.  The requirements are as follows.

• Enable TCP intercept on R1 to protect the web server located behind R2.
• The mode should be intercept
• The drop mode should be set to random
• Set the timeout for connections to be 5 minutes

Configuration:

ip access-list extended TCP-Intercept

 permit tcp any host 155.2.2.2

!

!

ip tcp intercept list TCP-Intercept

ip tcp intercept connection-timeout 300

ip tcp intercept drop-mode random

!

!

end

In order to test this, a telnet connection to R2's loopback from R3 can be established.  Remember that TCP intercept is going to inspect data plane traffic, so the traffic needs to pass through the router.

With this feature, there are only two(2) show commands for verification.  They are:

1. show tcp intercept connections
2. show tcp intercept statistics

In this example I am going to enable debug ip tcp intercept on R1 and test with the telnet connection from R3 to R2.

INTERCEPT: new connection (10.0.13.3:21903 SYN -> 155.2.2.2:23)

INTERCEPT(*): (10.0.13.3:21903 <- ACK+SYN 155.2.2.2:23)

INTERCEPT: 1st half of connection is established (10.0.13.3:21903 ACK -> 155.2.2.2:23)

INTERCEPT(*): (10.0.13.3:21903 SYN -> 155.2.2.2:23)

INTERCEPT: 2nd half of connection established  (10.0.13.3:21903 <- ACK+SYN 155.2.2.2:23)

INTERCEPT(*): (10.0.13.3:21903 ACK -> 155.2.2.2:23)

INTERCEPT(*): (10.0.13.3:21903 <- WINDOW 155.2.2.2:23)

In the above debug output, we can see that a new connection attempt was established by R3.  R1 intercepted the packet and replied with a SYN/ACK to R3 to IP address 10.0.13.3.  It then says the 1st half of the connection is established.  Then the router establishes the TCP connection with R2.  After the 2nd half of the connection is established, the router will finally patches the two parts together and allows the TCP connection between R3 to R2.  Let's take a look at the show commands for verification.

R1#show tcp intercept statistics

Intercepting new connections using access-list TCP-Intercept

0 incomplete, 1 established connections (total 1)

1 connection requests per minute

R1#show tcp intercept connections 

Incomplete:

Client                Server                State    Create   Timeout  Mode

Established:

Client                Server                State    Create   Timeout  Mode

10.0.13.3:21903       155.2.2.2:23          ESTAB    00:02:54 00:02:06 I

The above output shows that a connection to server 155.2.2.2 is established.  It also shows that it is intercepting TCP connections using access list TCP-Intercept that we created.  There are no incomplete connections


In summary, this blog examined the basics of the TCP 3way handshake, the definition and examination of a DoS attack and how the Cisco router can be configured to intercept TCP connections and act as a proxy for the servers needing to be protected from potential DoS attacks.