Blackhole Traffic in Linux

Previous | Linux | Next

---

A few times, I had this issue with some client connected to one our servers that was filling up the disk space with some garbage.

At that point (customer or not), I needed to block their IP from connecting. There are many ways of doing that (IPTABLES, SELinux, etc.) There is also a way of  doing that by rejecting their IP using routing table in Linux.

In this example I will use my two Raspberry PI computers. The first one, 192.168.0.253 (clu) will block the second one 192.168.0.254 (tron).

Method 1

pi@clu $ sudo route add 192.168.0.254 gw 127.0.0.1
pi@clu $

 The efect of this command will produce the following output:

pi@clu $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.254   127.0.0.1       255.255.255.255 UGH       0 0          0 lo
pi@clu $

Removal is the same command with 'del' instead of 'add'.

pi@clu $ sudo route del 192.168.0.254 gw 127.0.0.1
pi@clu $

Method 2
Another way of accomplishing the same task is the following route table change

pi@clu $ sudo route add -host 192.168.0.254 reject
pi@clu $ 

It creates the following route table entry:

pi@clu $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.254   -               255.255.255.255 !H        - -          - -
pi@clu $

In a similar way, we can use use keyword '-net 192.168.0.0 netmask 255.255.255.0 reject'. This will stop the whole network from entering our server.

Again, in order to remove it, the following needs to be configured:

pi@clu $ sudo route del -host 192.168.0.254 reject
pi@clu $ 

Finally, also a quick method is to use the keyword 'blackhole'.

Method 3

pi@clu $ sudo ip route add blackhole 192.168.0.254/32
pi@clu $

This will create the following entry in the routing table:

pi@clu $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.254   0.0.0.0         255.255.255.255 UH        0 0          0 *
pi@clu $

In order to remove this entry type in:

pi@clu $ sudo ip route del blackhole 192.168.0.254/32
pi@clu $

Linux Simple Firewall Using IPTABLES

Previous | Linux | Next

---

The basic computer protection is to only allow connections necessary. Anything else should be disconnected.

I want to check what ports my Kali Linux has currently open. The best tool to quickly do that is NMAP scanner (written by Gordon Lyon).

Here goes (my Kali Linux):

jr@rat $ nmap 192.168.0.251

Starting Nmap 7.01 ( https://nmap.org ) at 2020-07-25 09:07 IST
Nmap scan report for hack (192.168.0.251)
Host is up (0.0038s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 0.17 seconds
jr@rat $ 

That's good. Only SSH server is running on the box.

What is the current state of IPTABLES configuration?

pi@hack: $ sudo iptables -L
[sudo] password for pi: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
pi@hack: $ 

Here's a simple protection allowing only SSH traffic to my Linux box.

INPUT policy is set to 'ACCEPT'. I want to change it.

I would like to give it a simple, extra protection. In case I will open other ports in the future, they won't be accessible to the rest of my network. Not until I permit this in IPTABLES.

So here is my simple configuration allowing SSH only.

pi@hack: $ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
pi@hack: $ sudo iptables -A INPUT -i lo -j ACCEPT
pi@hack: $ sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
pi@hack: $ sudo iptables -P INPUT DROP
pi@hack: $ 

 What is it doing?

iptables -A INPUT 
It will add (-A) entry to the INPUT chain (the one that deals with the packets trying to enter the box).

-m conntrack
This refers to the stateful firewall module that allows the system to track the existing connection (initiated by this very computer) and allow the returning traffic to be accepted rather than dropped.

ESTABLISHED,RELATED
The state of the connections might be of different sorts. Here ESTABLISHED means that my system has already received reply from the host it sent packet to. RELATED, will are packets that relate to already ESTABLISHED session (like ftp data session relies on already established control session).

--ctstate
This sets the state such as (ESTABLISHED, RELATED, INVALID, etc.).

Next line, 

iptables -A INPUT -i lo -j ACCEPT

allows daemons talk to Loopback interface. Without this line, local software can't talk to other hosts.

The line that allows ssh traffic coming in (self explanatory)

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

And finally, the INPUT policy (-P) will drop everything that is not otherwise allowed.

The last problem to solve is that this configuration is not persistent. It will not survive the reboot.

In order to make it work like this after the computer is rebooted, I need to install extra package.

pi@hack: $ sudo apt-get install iptables-persistent
pi@hack: $

During the installation, a windows pops up asking if I want to save current configuration. I am going to oblige.

Verification of this 'save' is below:

pi@hack: $ cat /etc/iptables/rules.v4
# Generated by xtables-save v1.8.2 on Sat Jul 25 09:41:15 2020
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT
# Completed on Sat Jul 25 09:41:15 2020
pi@hack: $

After adding extra lines, saving new configuration can be done with the following command:

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Similarly, the restoration of the configuration from the file, would look as follows:

sudo sh -c "iptables-restore < /etc/iptables/rules.v4

One last observation about Kali Linux is that the iptables service is not turned on by default.

pi@hack: $ systemctl status iptables
● iptables.service - netfilter persistent configuration
     Loaded: loaded (/etc/alternatives/iptables.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
       Docs: man:netfilter-persistent(8)
pi@hack: $

Quick enable mode (start for starting it now) should do the trick. After next reboot, iptables will be turned on doing what I have asked it to do.

pi@hack: $ sudo systemctl enable iptables
Created symlink /etc/systemd/system/multi-user.target.wants/netfilter-persistent.service → /lib/systemd/system/netfilter-persistent.service.
pi@hack: $

On to the next system discovery...

Connecting Kali Linux to WiFi Network

Previous | Linux | Next

---

My old and battered Dell Optiplex 745 desktop has seen better days. But I just can't part with it. Not when it is still alive.

I have installed Kali Linux on the Optiplex. It is nice to see it breathe again. I have decided to learn this Linux distribution a bit. Who knows, it may come in handy some day. 

Since this machine has no wireless adapter, I am going to plug in a USB one. Let's see what /var/log/messages says about it.

usb 1-3: new high-speed USB device number 2 using ehci-pci
usb 1-3: New USB device found, idVendor=0bda, idProduct=8176, bcdDevice= 2.00
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-3: Manufacturer: Realtek
usb 1-3: SerialNumber: 00e04c000001
mtp-probe: bus: 1, device: 2 was not an MTP device
mtp-probe: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3"
kernel: [  861.048033] rtl8192cu: Chip version 0x10
kernel: [  861.124660] rtl8192cu: Board Type 0
kernel: [  861.124892] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
kernel: [  861.124964] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
kernel: [  861.180081] usbcore: registered new interface driver rtl8192cu
kernel: [  861.190722] usb 1-3: firmware: direct-loading firmware rtlwifi/rtl8192cufw_TMSC.bin
mtp-probe: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3"
mtp-probe: bus: 1, device: 2 was not an MTP device
kernel: [  861.253312] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [  861.255516] rtl8192cu: MAC auto ON okay!
kernel: [  861.298164] rtl8192cu: Tx queue select: 0x05
kernel: [  861.815663] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [  861.840767] rtl8192cu: MAC auto ON okay!
kernel: [  861.873790] rtl8192cu: Tx queue select: 0x05
kernel: [  862.397726] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [  862.685255] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

The system recognizes Realtek USB WiFi adapter. 

Now would be the time to try to make it work. Let's start with looking at what network adapters Kali can see:

The WiFi adapter shows as 'wlan0' and is currently disconnected. 

Now onto the WiFi Access Points discovery (I know my AP name but I want to have some fun on this Sunday morning). The following command will discover all APs in the neighborhood.

pi@hack: $ iwlist wlan0 scan

A nice and short output to display all APs in the neighborhood is produced by 'nmcli dev wifi list'.

SSIDs have been hidden here. I don't want to disclose my and my neighbor's APs.

Now, let's hook up the wlan0 interface to my home network. As of now, the interface looks like this in ifconfig output:

pi@hack: $ /sbin/ifconfig wlan0
wlan0: flags=4099  mtu 1500
        ether d6:a5:6b:d9:b6:15  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The command that is going to connect to my WiFi access point goes like this:

pi@hack: $ sudo nmcli device wifi connect SSID-Of-My-AP password My-Password

Now, I can see that the adapter is working:

pi@hack: $ sudo ifconfig wlan0
wlan0: flags=4163  mtu 1500
        inet 192.168.0.28  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fd34:b1bb:c269:0:31b2:adf2:7740:ea48  prefixlen 64  scopeid 0x0
        inet6 fe80::7c9e:84a4:2c7b:4104  prefixlen 64  scopeid 0x20
        ether e8:4e:06:0d:d6:98  txqueuelen 1000  (Ethernet)
        RX packets 36  bytes 8072 (7.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 3110 (3.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@hack: $

I am off to a good start to explore how WiFi can be hacked.

TCPDUMP Basics

CCNA Basics | Cisco Next Step | Linux 

TCPDUMP Basics | TCPDUMP IP Header

TCPDUMP is a very powerful packet capturing tool. "Must love tcpdump and wireshark" the job ads often say, so working with networks requires mastering the fundamentals of this tool.

I have two Raspberry PI computers in my lab. They are perfect learning tools (hats off to the creators).

TYPICAL SYNTAX

A typical packet capture might look like this:

pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv src host 192.168.0.254 and dst port 22
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1600 bytes

What on earth do those flag stand for?
-i eth0      capture packets on eth0 interface
-s 1600    capture only 1600 bytes rather than max. allowed (varies by version)
-nn           don't resolve ip address or port numbers to names
-v             slightly more verbose output
-vv           even more verbose output
-vvv         even more verbose output (useful with -x or -X option)
src host   coming from IP address
and          logical and (both statement must be true to capture packets)
dst port    dst port 22 (ssh)

NETWORK FILTERING
tcpdump net 192.168.0
tcpdump src net  192.168.0
tcpdump dst net 192.168.0
etc.

PROTOCOL FILTERING
tcpdump ip
tcpdump tcp
tcpdump icmp
etc. 

Combining expressions may may involve keywords such as:

!        negation
not    negation

&       concatenation
and    concatenation

||        alternative (or)
or       alternative

Example:
pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv -c3 'tcp and src host 192.168.0.254'

I've thrown in -c3 (for capturing only 3 packets) and the combined expression in quotes (' ').

Another example:
pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv -c3 'not tcp and src host 192.168.0.254'