Network Admin Stuff: July 2020

Monday, July 27, 2020

Linux-Next-Step

Linux is the best playground for curious minds.

IP Geolocation
Connecting Kali Linux to WiFi Network
Linux Simple Firewall Using IPTABLES
Blackhole Traffic in Linux

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 $

Building eBGP Peering

Previous | Cisco | Next

When two BGP routers that belong to different Autonomous System establish session, they effectively form an eBGP session. Here is an example of configuring eBGP session between R2 (AS 65100) and R8 (AS 65089).

R8 Configuration:

router bgp 65089
 bgp router-id 10.8.8.8
 bgp log-neighbor-changes
 neighbor 172.16.28.2 remote-as 65100

Now R2 Configuration:

router bgp 65100
 bgp router-id 10.2.2.2
 bgp log-neighbor-changes
 neighbor 172.16.28.8 remote-as 65089

Verification of the session.

R2#show ip bgp summary
BGP router identifier 10.2.2.2, local AS number 65100
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.28.8     4        65089       5       5        1    0    0 00:01:29        0
R2#

All is good here.

More elaborate output:

R2#show ip bgp neighbor 172.16.28.8
BGP neighbor is 172.16.28.8,  remote AS 65089, external link
  BGP version 4, remote router ID 10.8.8.8
  BGP state = Established, up for 00:05:02
  [snip]
  Local host: 172.16.28.2, Local port: 179
  Foreign host: 172.16.28.8, Foreign port: 12099

In preparation to next lab I want to advertise a few prefixes on R8, so that R2 can learn them.

First, I am going to create a few loopback interfaces with IP addresses.

interface Loopback0
 ip address 10.8.8.8 255.255.255.255
!
interface Loopback10
 ip address 10.8.0.1 255.255.255.240
!
interface Loopback11
 ip address 10.8.0.17 255.255.255.240
!
interface Loopback12
 ip address 10.8.0.33 255.255.255.240
!
interface Loopback13
 ip address 10.8.0.49 255.255.255.240
!
interface Loopback14
 ip address 10.8.80.1 255.255.255.0
!
interface Loopback15
 ip address 10.8.81.1 255.255.255.0
!
interface Loopback16
 ip address 10.8.82.1 255.255.255.0
!
interface Loopback17
 ip address 10.8.83.1 255.255.255.0
!

As for advertising networks in BGP, this protocol is unlike IGP protocols such as IS-IS, OSPF, EIGRP.

Those observations deserve a separate post.

Saturday, July 25, 2020

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...

iBGP Neighbor Address

Previous | Cisco | Next

When establishing BGP sessions between two nodes, there is one more thing worth noting.

Let's remove previous configuration and start from scratch.

R1:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#no router bgp 65104

R4:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#no router bgp 65104

Let's rebuild this iBGP peering between R1 and R4, but incorrectly this time.

First, on R1:

R1(config)#router bgp 65104
R1(config-router)#neighbor 172.16.14.4 remote-as 65104
R1(config-router)#end
R1#

So far, so good. But now, R4's configuration is going to teach us a lesson.

R4(config)#router bgp 65104
R4(config-router)#neighbor 172.16.104.1 remote-as 65104
R4(config-router)#end
R4#

This is not working. iBGP Session is not getting established. What is wrong here?

First debug shows this:

R4#debug ip tcp transactions 
TCP special event debugging is on
R4#u all                     
Reserved port 0 in Transport Port Agent for TCP IP type 0
TCP: connection attempt to port 179
TCP: sending RST, seq 0, ack 1549513988
TCP: sent RST to 172.16.14.1:47137 from 172.16.14.4:179
Released port 0 in Transport Port Agent for TCP IP type 0 delay 240000
TCP0: state was LISTEN -> CLOSED [0 -> UNKNOWN(0)]
TCB 0xF3E55AD0 destroyed
R4#u all
R4#

R4 is sending TCP RST. But why? It is configured to run BGP AS 65104 after all!

Let's tear R1's configuration apart.

The router process is configured to be AS 65401. So is the AS number on R4. All in order here.

R1 configuration contains the 'neighbor 172.16.14.4 remote-as 65401'. This means, that R1 is going to try to establish iBGP session with R4. Since R1 has two interfaces towards R4, it is going to use the one that routing table uses as best path towards 172.16.14.4. Here it is:

R1#show ip route 172.16.14.4   
Routing entry for 172.16.14.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0.14
      Route metric is 0, traffic share count is 1
R1#

In order to send TCP SYN R1 will use its Ethernet0/0.14 to reach 172.16.14.4. It is going to source this request with IP address found on this interface: 172.16.14.1.

A temporary ACL and debug ip packet detail (use in lab only), are going to help see what is going on.

R4(config)#access-list 101 permit ip host 172.16.14.1 any
R4(config)#access-list 101 permit ip host 172.16.14.4 any
R4(config)#

This ACL will be used in the debug.

R4#debug ip packet detail 101
IP packet debugging is on (detailed) for access list 101
R4#
IP: s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4, len 44, input feature
    TCP src=41155, dst=179, seq=702428119, ack=0, win=16384 SYN, MCI Check(88), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
FIBipv4-packet-proc: route packet from Ethernet0/0.14 src 172.16.14.1 dst 172.16.14.4
FIBfwd-proc: Default:172.16.14.4/32 receive entry
FIBipv4-packet-proc: packet routing failed
IP: tableid=0, s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4 (Ethernet0/0.14), routed via RIB
IP: s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4 (Ethernet0/0.14), len 44, rcvd 3
    TCP src=41155, dst=179, seq=702428119, ack=0, win=16384 SYN
IP: s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4
R4#, len 44, stop process pak for forus packet
    TCP src=41155, dst=179, seq=702428119, ack=0, win=16384 SYN
FIBipv4-packet-proc: route packet from (local) src 172.16.14.4 dst 172.16.14.1
FIBfwd-proc: packet routed by adj to Ethernet0/0.14 172.16.14.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 40, sending
    TCP src=179, dst=41155, seq=0, ack=702428120, win=0 ACK RST
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 40, sending full packet
    TCP src=179, dst=41155, seq=0, ack=702428120, win=0 ACK RST
R4#u all
All possible debugging has been turned off
R4#

Clearly R4 does not like the request sent by R1.

The reason is that R4 BGP configuration has the following line:

R4(config)#router bgp 65104
R4(config-router)#neighbor 172.16.104.1 remote-as 65104
R4(config-router)#end
R4#

R4 will try to establish the TCP (BGP) session with R1 using its outgoing interface Ethernet0/0.104.

It expects to receive TCP SYN from R1 with the source IP address 172.16.104.1, not currently seen 172.16.14.1. Establishing session fails on both routers due to the neighbor IP address misconfiguration.

Conclusion

BGP neighbor IP address configured must match IP address of the incoming TCP SYN (port 179) from the peer. If not here's what we see:

R1#show ip bgp summary
BGP router identifier 10.1.1.1, local AS number 65104
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.14.4     4        65104       0       0        1    0    0 never    Idle
R1#

R4#show ip bgp summary
BGP router identifier 10.4.4.4, local AS number 65104
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.104.1    4        65104       0       0        1    0    0 never    Idle
R4#

Remove the configuration from this (and previous lab). Up next, eBGP session.

Sunday, July 19, 2020

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.

Saturday, July 18, 2020

Building iBGP Peering

Previous | Cisco | Next

Key points

BGP Protocol does not discover the neighboring routers running BGP (Peers). Administrator statically defines neighbor IP addresses for the BGP protocol to establish connection.

It uses TCP for transportation with destination port 179 (performs 3-way handshake)

Since BGP protocol uses TCP for transportation, the routers rely on IGP (OSPF/EIGRP/ISIS) to reach each other.

In an unlikely case both BGP peers initiated TCP session at exact same time, only the session originated by the higher BGP Router-ID is maintained. The other TCP session will be dropped.

An iBGP Peering (Internal BGP Peering) is built when the routers share the same AS number (Autonomous System number) which has certain consequences in relation to BGP operation.

If the routers forming BGP session do not share the same AS, they establish eBGP (External BGP) peering). There are some important differences between iBGP and eBGP operation (more on that in future labs).

Router allows only one AS to be configured.

BGP Router ID is chosen in the following order (the same as OSPF selection process):

Prefer, manually assigned Router ID.
If there is no manually assigned Router ID, use the highest IP address of configured Loopback interface.
If there is no manually configured Router ID, and no Loopback with configured IP address, use the highest IP address found on the physical interface.

Lab Topology

Here’s the R1 BGP configuration:

R1#conf t
R1(config)#router bgp 65100
R1(config-router)#bgp router-id 10.1.1.1
R1(config-router)#neighbor 172.16.14.4 remote-as 65100
R1(config-router)#end
R1#

In English this would, more or less, mean this:

Enter the global confiugation mode (conf t).

Start BGP process with AS number 65100 (router bgp 65100).

Manually assign BGP router id to be 10.1.1.1 (bgp router-id 10.1.1.1).

Initiate iBGP session to the IP address 172.16.14.4 (neighbor 172.16.14.4 remote-as 65100)

Get back to privileged mode (end).

What happens now with ‘neighbor 172.16.14.4 remote-as 65100’ statement, is that R1 is going to perform a routing table lookup trying to determine if it knows how to reach the neighbor. It does know the path to the neighbor as shown below:

R1#show ip route 172.16.14.4
Routing entry for 172.16.14.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0.14
      Route metric is 0, traffic share count is 1
R1#

Since this is a lab not a production equipment I can use all sorts of methods to inspect what’s happening behind the curtain. Let’s take a sneak peek using ‘debug ip tcp transactions’ enabled on both R1 and R4.

R1 Debug Output:

  
R1#debug ip tcp transactions
TCP special event debugging is on
R1#
TCBF316C348 created
TCBF316C348 setting property TCP_VRFTABLEID (20) F3ED29DC
TCBF316C348 setting property TCP_MD5KEY (4) 0
TCBF316C348 setting property TCP_ACK_RATE (37) F31765E8
TCBF316C348 setting property TCP_TOS (11) F3176604
TCBF316C348 setting property TCP_PMTU (45) F3176590
TCBF316C348 setting property TCP_IN_TTL (34) F31765A4
TCBF316C348 setting property TCP_OUT_TTL (35) F31765A4
TCBF316C348 setting property TCP_OUT_TTL (35) F3ED2BF2
TCBF316C348 setting property TCP_RTRANSTMO (36) F31765E4
TCP: Random local port generated 44659, network 1
TCBF316C348 bound to 172.16.14.1.44659
Reserved port 44659 in Transport Port Agent for TCP IP type 1
R1#
TCP: sending SYN, seq 2088596354, ack 0
TCP0: Connection to 172.16.14.4:179, advertising MSS 1460
TCP0: state was CLOSED → SYNSENT [44659 → 172.16.14.4(179)]
Released port 44659 in Transport Port Agent for TCP IP type 1 delay 240000
TCP0: state was SYNSENT  CLOSED [44659  172.16.14.4(179)]
TCP0: bad seg from 172.16.14.4 -- closing connection: port 44659 seq 0 ack 2088596355 rcvnxt 0 rcvwnd 0 len 0
TCP0: connection closed - remote sent RST
TCB 0xF316C348 destroyed
R1#u all
All possible debugging has been turned off

TCP block is created and bound to local IP 172.16.14.1, TCP source port 44659 is randomly chosen.

The source IP 172.16.14.1 is going to be used to communicate with the neighbor (IP address of the outgoing interface towards 172.16.14.4 - Ethernet0/0.14).

R1 is using TCP trying to establish session src: 172.16.14.1:44659 dst: 172.16.14.4:179.

This attempt fails due to TCP RST sent by 172.16.14.4. The reason RST is sen is that R4 has the port 179 currently closed. R4 BGP configuration is missing. TCP Control Block is destroyed. And shortly R1 is going to repeat the same process in an endless loop.

Let’s configure R4 to complete iBGP session with R1.

R4 - BGP Configuration:

  
router bgp 65104
 bgp router-id 10.4.4.4
 neighbor 172.16.14.1 remote-as 65104

Now, with proper BGP configuration on both devices, R1 shows the following output in the debug:

  

R1#debug ip tcp transactions 
TCP special event debugging is on
R1#
TCBF316C998 created
TCBF316C998 setting property TCP_VRFTABLEID (20) F3ED29DC
TCBF316C998 setting property TCP_MD5KEY (4) 0
TCBF316C998 setting property TCP_ACK_RATE (37) F3F83DA0
TCBF316C998 setting property TCP_TOS (11) F3F83DBC
TCBF316C998 setting property TCP_PMTU (45) F3F83D48
TCBF316C998 setting property TCP_RTRANSTMO (36) F3F83D9C
TCP: Random local port generated 24819, network 1
TCBF316C998 bound to 172.16.14.1.24819
Reserved port 24819 in Transport Port Agent for TCP IP type 1
TCP: sending SYN, seq 3941922061, ack 0
TCP0: Connection to 172.16.14.4:179, advertising MSS 1460
TCP0: state was CLOSED → SYNSENT [24819 → 172.16.14.4(179)]
TCP0: state was SYNSENT → ESTAB [24819 → 172.16.14.4(179)]
TCP: tcb F316C998 connection to 172.16.14.4:179, peer MSS 1460, MSS is 1460
TCBF316C998 connected to 172.16.14.4.179
TCBF316C998 setting property TCP_NO_DELAY (0) F3F83D9C
TCBF316C998 setting property TCP_RTRANSTMO (36) F3F83D9C
R1#
%BGP-5-ADJCHANGE: neighbor 172.16.14.4 Up 
R1#u all
All possible debugging has been turned off

And below is R4 output. Both are self-explanatory

R4#debug ip tcp transactions
TCP special event debugging is on
R4#
TCBF31AB410 created
TCBF31AB410 setting property TCP_PMTU (45) F31764C8
TCBF31AB410 setting property TCP_TOS (11) F31764F0
TCBF31AB410 setting property TCP_VRFTABLEID (20) F31AB0D4
TCBF31AB410 bound to 0.0.0.0.179
TCBF31AB410 setting property TCP_ACCESS_CHECK (5) 8F076F8
TCBF31AB410 setting property TCP_MD5KEY (4) 0
Reserved port 179 in Transport Port Agent for TCP IP type 1
TCBF31AB410 listening with queue 1

TCBF31C6948 created
TCP0: state was LISTEN → SYNRCVD [179 → 172.16.14.1(24819)]
TCP: tcb F31C6948 connection to 172.16.14.1:24819, peer MSS 1460, MSS is 516
TCP: sending SYN, seq 991876611, ack 3941922062
TCP0: Connection to 172.16.14.1:24819, advertising MSS 1460
TCP0: state was SYNRCVD → ESTAB [179 → 172.16.14.1(24819)]
TCBF31AB410 accepting F31C6948 from 172.16.14.1.24819
TCBF31C6948 setting property TCP_VRFTABLEID (20) F31AB0D4
TCBF31C6948 setting property TCP_PMTU (45) F3F0A150
TCBF31C6948 setting property TCP_NO_DELAY (0) F3F0A178
TCBF31C6948 setting property TCP_ACK_RATE (37) F3F0A180
TCBF31C6948 setting property TCP_RTRANSTMO (36) F3F0A178
%BGP-5-ADJCHANGE: neighbor 172.16.14.1 Up 
R4#
TCP0: ACK timeout timer expired
R4#u all
All possible debugging has been turned off

Another lab trick (do not attempt to use such debugs on the production equipment as they may crash), is to use ‘debug ip packet detail’ to see that exchange.

Here it is on R4:

R4(config)#access-list 100 permit tcp any host 172.16.14.1
R4(config)#access-list 100 permit tcp host 172.16.14.1 any

R4(config)#router bgp 65104
R4(config-router)#no neighbor 172.16.14.1
R4(config-router)#do debug ip packet detail 100
R4(config-router)#neighbor 172.16.14.1 remote-as 65104
R4(config-router)#end
R4#

This produces rather large output. But here is the gist:

  
R4#
FIBipv4-packet-proc: route packet from (local) src 172.16.14.4 dst 172.16.14.1
FIBfwd-proc: packet routed by adj to Ethernet0/0.14 172.16.14.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 44, sending
    TCP src=35036, dst=179, seq=3608906138, ack=0, win=16384 SYN
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 44, sending full packet
    TCP src=35036, dst=179, seq=3608906138, ack=0, win=16384 SYN
IP: s=172.16.14.1 (Ethernet0/0.14), d=172.16.14.4, len 44, rcvd 0
    TCP src=179, dst=35036, seq=2263598807, ack=3608906139, win=16384 ACK SYN
FIBipv4-packet-proc: route packet from (local) src 172.16.14.4 dst 172.16.14.1
FIBfwd-proc: packet routed by adj to Ethernet0/0.14 172.16.14.1
FIBipv4-packet-proc: packet routing succeeded
IP: s=172.16.14.4 (local), d=172.16.14.1 (Ethernet0/0.14), len 40, sending
    TCP src=35036, dst=179, seq=3608906139, ack=2263598808, win=16384 ACK

The take away from this TCP 3-way exchange is that R4 becomes a client, R1 is a server, and the TCP session has been established.

Here is the proof:

  
R4#show tcp brief
TCB       Local Address               Foreign Address             (state)
F31F82F0  172.16.14.4.35036           172.16.14.1.179              ESTAB
R4#

R4#show ip bgp neighbor 172.16.14.1
BGP neighbor is 172.16.14.1,  remote AS 65104, internal link
  BGP version 4, remote router ID 10.1.1.1
  BGP state = Established, up for 00:11:43
[snip]
Local host: 172.16.14.4, Local port: 35036
Foreign host: 172.16.14.1, Foreign port: 179
[snip]

The ‘internal link’ means it is an iBGP sessions. Both R1 and R4 share the same AS number 65104.

In the following output, notice two things:

State shows nothing (it means it is established)
PfxRcd (prefixes received) is 0

  
R4#show ip bgp summary
BGP router identifier 10.4.4.4, local AS number 65104
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.14.1     4        65104      23      23        1    0    0 00:16:56        0
R4#

Unlike IGP routing protocols (OSPF/ISIS/EIGRP/RIP), BGP does not advertise any network prefixes. They will need to be advertised manually by the admin.

Sunday, July 12, 2020

ip-geo-location

Previous | Linux | Next

In my work I often need to block particular IP addresses on the firewall. Those are typically some attackers who try to either scan for network vulnerability or just attack some resources.

I am usually curious where these attacks are coming from. There are plenty of resources out there that help geo-locating IP addresses. One of them is

https://www.geolocation.com/

For instance, if I wanted to find out the location of one of Microsoft Name Server:

40.90.4.205

I could go to the website and type and get the results like that:

But when I hit enter, the url field shows the exact query sent to their server.

The query looks like this:

https://www.geolocation.com/?ip=40.90.4.205#ipresult

And that can be easily automated in Bash.

The best way is to use an example. Let's say I want to find the location of Microsoft NS servers.

Step 1 - Obtain IP addresses

jr@rat $ host -t ns microsoft.com
microsoft.com name server ns3-205.azure-dns.org.
microsoft.com name server ns1-205.azure-dns.com.
microsoft.com name server ns4-205.azure-dns.info.
microsoft.com name server ns2-205.azure-dns.net.
jr@rat $

Okay. Not exactly what I want is it? Let's 'cut' the output and get just the name of the servers:

jr@rat $ host -t ns microsoft.com | cut -d " " -f4 > microsoft-ns.txt
jr@rat $ cat microsoft-ns.txt 
ns3-205.azure-dns.org.
ns1-205.azure-dns.com.
ns4-205.azure-dns.info.
ns2-205.azure-dns.net.
jr@rat $

Better. But I need IPs rather than names.

jr@rat $ while read ip; do host $ip; done < microsoft-ns.txt 
ns3-205.azure-dns.org has address 13.107.24.205
ns3-205.azure-dns.org has IPv6 address 2a01:111:4000::cd
ns1-205.azure-dns.com has address 40.90.4.205
ns1-205.azure-dns.com has IPv6 address 2603:1061::cd
ns4-205.azure-dns.info has address 13.107.160.205
ns4-205.azure-dns.info has IPv6 address 2620:1ec:bda::cd
ns2-205.azure-dns.net has address 64.4.48.205
ns2-205.azure-dns.net has IPv6 address 2620:1ec:8ec::cd
jr@rat $

Well, I'd rather have IPv4 addresses only. One more shot at this:

jr@rat $ while read ip; do host $ip | grep "has address" | cut -d " " -f4; done < microsoft-ns.txt > ip.txt
jr@rat $ cat ip.txt
13.107.24.205
40.90.4.205
13.107.160.205
64.4.48.205
jr@rat $

With this ip.txt file and only IP addresses in it, I can proceed to step 2.

Step 2 - Use IP Geolocation Server

So, the script could look like this:

jr@rat $ while read ip; do host $ip | grep "has address" | cut -d " " -f4; done < microsoft-ns.txt > ip.txt
jr@rat $ cat ip.txt
13.107.24.205
40.90.4.205
13.107.160.205
64.4.48.205
jr@rat $

The last line will fire up the web browser and get me the information I wanted:

jr@rat $ firefox &
jr@rat $ while read ip; do firefox -new-tab https://www.geolocation.com/?ip=$ip#ipresult;done < ip.txt
jr@rat $

In Bash it is very easy to automate those boring tasks.

Networking Next Step

Home | Next Step | Cisco | Linux

>> First Lab Here

In order to hone skills the playground is necessary.

First, I need a lab to work on. So, here is this virtual environment, a bit buggy as well but hey, that's all I have for now :)

The switches are connected as follows:

Here is the initial configuration of all devices.

And here is the 'show cdp neighbors' output.

Also, there are two Raspberry PIs (love 'em), two laptops and one very, very old Dell Optiplex 745 desktop.

All computers run Linux. It looks like I have more than enough to have techno-fun :)

I am ready to rock'n'roll then.