In our basic topology scenario, due to small budget our company still uses the old Cisco equipment for routing and filtering, but this time the second branch closed and added instead a visitor network (may be used by people that come at interview). After seeing some attacks done in our internal network like DoS, we decided to test different approaches: started with TCP intercept, continuing with CBAC and in the end implemented successfully the better security solution - zone based firewall (ZBF).

The new end-point machine called kali is a Kali Linux version 2019.3 and represents the possible attacker. The old network from branch 2 is reused (3.3.3.0/24) for visitors - with the first IP from subnet assigned to router and the second one for end-device. Note that we may refer to the router as firewall during the course of the lab.

Again, the router model is 7200 (version: c7200-adventerprisek9-mz.124-9.T4 - link here).

You have to do the following:

- add IPs for network between the server and the network equipment (use range 1.1.1.0/24)

- add IPs for network between the client and kali and the network equipment (use ranges 2.2.2.0/24 and 3.3.3.0/24) First IP is allocated for router and the second one for client1/kali machine

- add routes to make sure the endpoints can ping each other

Topology:

This first scenario is just for getting used to DoS attacks in our topology and hping3 command. Suppose that an attacker (called Trudy) wants to make a server unavailable using a SYN flood attack (which is fairly easy to create). This is done by sending TCP segments with SYN flag and no intention to complete the handshake. The server hangs by waiting for these connections to be finished until the timeout expires, but creates problems with legitimate TCP connections which can be denied.

TCP intercept is a features found in IOS that is used for SYN flood protection. There are 2 modes of protection:

- intercept: the router does mitm by intercepting the user's connection request and pretends to be the server, by completing the connection. Only if the 3-way handshake is completed successfully, the second TCP connection is set with the server.

Note: This process is transparent to both server and client

Suppose a SYN flood attack happens. The router has a buffer for all opened connections on behalf of client, that will timeout after a period of time (it sends to client a RST) due to no completed 3-way handshake and removed from the connection table. By using this approach, the server remains unaffected by the attack and valid requests are answered.

- watch: the disadvantage of intercept is that most of the times the router does this mitm for fair clients and adds overhead. A solution can be watch mode, which is a reactive approach that is monitoring connections, keeping track of half-open ones. Again, after a timeout (default 30 seconds) if a connection is not completed, the router sends a RST to server to remove it. This will remove all unwanted incompleted connections and allows legitimate ones to complete.

In this lab, we will use hping3 to simulate the attack. On server machine we have SimpleHTTPServer up and running on port 8080.

For TCP intercepting, we need firstly to add on router an ACL to permit tcp for any ip:

cisco_7200(config)#ip access-list extended TCP_INTERCEPT
cisco_7200(config-ext-nacl)#permit tcp any host 1.1.1.2 eq 8080

Enable TCP intercept in global config mode and specify the traffic to be analyzed (using ACL from above):

cisco_7200(config)#ip tcp intercept list TCP_INTERCEPT

The default mode is intercept, which is the one we are goind to use here. To change it to watch:

cisco_7200(config)#ip tcp intercept mode watch

Note that a mix of them is not possible.

There are also 3 timeouts that can be also configured: watch (default 30 secs - waiting time for 3-way handshake to complete), finrst (default 5 secs - waiting time for a connection to finish) and connection (default 24 hours - the maximum time of connection management. This is for sure one with handshake completed, but it can be in idle mode).

A high and low threshold values can be configured to deal with a big number of requests. After the high value is reached, it begins to drop connections until the low one. Default for high is 1100 and for low 900. To set them in production, you need careful baseline analysis to avoid dropping legitimate connections. These can be changed using:

cisco_7200(config)#ip tcp intercept max-incomplete high 100
cisco_7200(config)#ip tcp intercept max-incomplete low 10

The default method in aggressive mode is to drop oldest connections first until the connections number is below the minimum value. This can be also changed to random:

cisco_7200(config)#ip tcp intercept drop-mode random 

Let's stress the webserver using hping3 command:

root@kali:# hping3 -n -c 1000 -d 120 -S -w 64 -p 8080 --flood 1.1.1.2 

Explanations for the flags used:

1. -n = numeric output only (no lookup is done for host names)
2. -c 1000 = number of packets to send
3. -d 120 = size of each packet to target machine
4. -S = send SYN only (SYN attack)
5. -w 64 = TCP window size
6. -p 80 = port 80 (http)
7. –flood = send packets as fast as possible without taking care about the replies

Monitor the connections on router device (see that all are marked as incomplete):

cisco_7200#sh tcp intercept connections 
Incomplete:
Client                Server                State    Create   Timeout  Mode
3.3.3.2:47922         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47923         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47920         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47921         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47926         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47927         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47924         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47925         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47930         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47931         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
3.3.3.2:47928         1.1.1.2:8080          SYNRCVD  00:00:00 00:00:00 I
[...]

*Oct 29 02:29:33.847: %TCP-6-INTERCEPT: getting aggressive, count (1100/1100) 1 min 0

See that each conn has SYNRCVD state, because a SYN-ACK was sent by the router and the mode is I (intercept).

Note that this will drop any other connection request sent to server (in our case, there were generated ~500k in few secs, but only 1100 left for analysis). This can be seen here:

cisco_7200#sh tcp intercept statistics 
Intercepting new connections using access-list TCP_INTERCEPT
1100 incomplete, 0 established connections (total 1100)

After 1 minute, the connections will drop until low value and the rest are retransmitted to client with SYN+ACK until timeout (due to aggresive mode, the value is reduced by half):

cisco_7200#
*Oct 29 02:30:54.195: %TCP-6-INTERCEPT: calming down, count (0/900) 1 min 0

cisco_7200(config)#no ip tcp intercept list
cisco_7200(config)#no ip tcp intercept max-incomplete  high
cisco_7200(config)#no ip tcp intercept max-incomplete  low 

CBAC stands for Context-Based Access Control and represents a feature of Cisco products that is used for verifying protocol of application layer and dynamic modification of firewall rules that are based on it.

Using this feature, the number of connections opened by outside machines can be limited (to stop a DoS attack). This task proposes to create a CBAC rule that is used for monitoring TCP connections and added on outbound interface to UbuntuVM (traffic to that machine).

It provides 4 main functions:

- filtering traffic: TCP, UDP, ICMP connections. As seen on lab 1, ACLs can filter only at layers 3 and 4 and reflexive ones (RACL) at layer 5. CBAC can also inspect at application level.

- inspecting traffic: CBAC maintains its stateful firewall by looking at layer 7. It can also prevent SYN flood attacks by shutting connections down after a specific threshold is reached.

- detecting intrusions: DoS protection, limit phishing attacks.

- generate alerts and audits: it can generate real-time alerts and detect attacks. Logs can later be inspected

CBAC configuration steps:

Part 1: find which interface is external for router. In our case this is e1/0.

Part 2 [optional for us]: Before the traffic gets inspected by CBAC, the traffic must be permitted by ACLs. In our case, there are no ACLs added to simplify the usage.

Try now to access the webserver from client1 and kali. It should work.

Part 3: global timeout values for tcp, udp, icmp can also be changed (like synwait-time, finwait-time, idle-time etc.). Another value that can be changed is the maximum number of incomplete connections:

cisco_7200(config)#ip inspect tcp max-incomplete host 4 block-time 1

There is a bug on this IOS version - for a host VAL < 4, the blocked packets is curl 1.1.1.2:8080 <!DOCTYPE html PUBLIC ”-W3CDTD HTML 3.2 FinalEN”><html> <title>Directory listing for /</title> <body> <h2>Directory listing for /</h2> […] </code> === 5. [2p] Extra ZBF === Do task 4 from Extra ZBF.