Killing connections with Ettercap filters

Now, let's try to construct a filter to kill SSH and SMTP connections while allowing all other traffic. This will give us hands-on experience with setting up a basic service filtering mechanism on our Kali box. Pay attention: my first shot at this short filter will have a troublemaking function in it. We'll review the results and see if we can't fix the problem.

First, I fire up nano and create a file with this filter:

if (ip.proto == TCP) {
  if (tcp.src == 22 || tcp.dst == 22 || tcp.src == 25 || tcp.dst == 25) {
    msg("SSH or SMTP communication detected. Killing connection.\n");
    drop();
    kill();
  }
}

Let's review this line by line:

• if (ip.proto == TCP) { is our parent if statement, checking if the packet in question is a TCP packet. If so, the script proceeds.
• if (tcp.src == 22 || tcp.dst == 22 || tcp.src == 25 || tcp.dst == 25) { is the nested if statement that checks if the TCP packet that passed our first check is coming from or destined to ports 22 or 25. The double pipe means or, so any of these four checks will pass the if, taking us to the functions:
  • msg() displays a message in our Ettercap window. I would always recommend using this so we know that the filter was triggered.
  • drop() simply drops the packet; since we're in the middle, it means we received it but we won't be passing it on. The sender doesn't get any confirmation of receipt, and the recipient never gets it.
  • kill() gets aggressive and sends a RST packet to both ends of the communication.  
• The two closing graph parentheses correspond to each if statement.

I save this text file with nano, and I prepare to compile it.

Why are we compiling the filter? Because interpreting code is slow, and we're dealing with analysis and manipulation in the middle of the packet's flight. The compiler is very simple to use and is included, so we simply issue the command with the name of the file we just created.

# etterfilter [filter text file]

The default output is filter.ef, but you can name it whatever you want.

Now, we simply fire up Ettercap like before, but this time we're loading our filter with -F.  Ettercap does everything else automatically:

# ettercap -T -q -F filter.ef -B eth0 -B wlan0 -w SSH_SMTP_Filter_Testcapture

I connect to our naughty network, and I try to connect to my SSH server at home. The connection fails, just as we had planned – but the console starts lighting up with my filter message. Let's look in Wireshark and filter by port 22 traffic to see what's going on:

What in tarnation? 26,792 RST packets in a matter of a couple minutes! We just flooded ourselves with RST packets. How did we manage this with such a dinky script? 

I know what the hacker in you is thinking: we included a kill function in bridged sniffing, so the filter is running on two interfaces and designed to match any packet going to and from SSH which would, by definition, include our RST packets. Nicely done, I'm impressed. Let's recompile our script and take out kill().  

That's better:

The network quietens down and our bridge merely drops the packets without sending any RST packets. My SSH client running on our victim Windows box never gets the SYN-ACK it was hoping for.