Linux is the best playground for curious minds.
Monday, July 27, 2020
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
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
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
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
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=4099mtu 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=4163mtu 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
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
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
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:
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
Okay. Not exactly what I want is it? Let's 'cut' the output and get just the name of the servers:
Better. But I need IPs rather than names.
Well, I'd rather have IPv4 addresses only. One more shot at this:
With this ip.txt file and only IP addresses in it, I can proceed to step 2.
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
>> 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.
Subscribe to:
Posts (Atom)
-
In my previous post I tried to stress the need for redundant connections between the switches. Multiple paths help us avoid a single point o... -
Previous | Home | Next I would like to invite you to embark on this journey with me. Learning how networks operate can be fun. So if yo... -
Previous | Linux | Next A few times, I had this issue with some client connected to one our servers that was filling up the disk spa...