Sunday, November 11, 2018

Radius Server with Linksys WRT 300N - PT

I am trying to demonstrate the working of Radius Server on Packet Tracer 7.1.  Components I have are
  • End Devices -> Server - PT (Radius Server)
  • Wireless Devices -> WRT300N (Linksys Wireless Router)
  • End Devices -> Laptop - PT (Wireless Client
Topology
First, we have to insert Wireless adapter in 'Laptop0'.  See the post Basic Wireless with Linksys WRT 300N

Connect ethernet cable(copper straight-through) from Ethernet1 of WRT300N to FastEthernet0 of Server-PT.
  1. Click 'Connections' -> 'Copper Straight-through'
  2. Click WRT300N, select Ethernet1 from the dropdown
  3. Click on Server-PT , select FastEthernet0 from the dropdown.

IP Address Configuration

  • Wireless Router will have default IP address
  • On Server configure '192.168.0.10/24' 
    • Click 'Server' -> 'Config' tab -> 'FastEthernet0' -> 'Static' from 'IP Configuration' -> IP Address '192.168.0.10' ; Subnet Mask '255.255.255.0'
  • In Laptop, set DHCP

Aim

Establish wireless connection from laptop to WRT300N thru WPA2-AES security with the help of Radius Server

AAA Configuration in Server 

Server AAA Configuratioin
  1. Click 'Server' -> 'Services' tab -> 'AAA' section
  2. Add Linksys WRT300N as a Radius Client
    • Service 'On' -> Client Name 'actrouter' ; Client IP '192.168.0.1' (IP Address of Wireless Router) ; Secret 'actkey' ; ServerType 'Radius' ; Click 'Add' 
  3. Add a User who will connect from laptop
    •  Username 'actuser' ; Password 'actpass' ; Click 'Add'

AAA Configuration in Router

Router AAA Configuration
  1. Click 'Router' -> 'Config' tab -> 'Wireless' section
  2. SSID 'actwifi' -> Authentication 'WPA2' -> Encryption Type 'AES'
  3. Radius Server IP and Credentials
    • IP Address '192.168.0.10' ; Shared Secret 'actkey'

AAA Configuration in Laptop

Laptop AAA Configuration
  1. Click 'Laptop' -> 'Config' tab -> 'Wireless0' section
  2. SSID 'actwifi' -> Authentication 'WPA2' -> Encryption Type 'AES'
  3. Radius user credentials configuration
    • User ID 'actuser' Password 'actpass'
  4. IP Configuration is DHCP

Connection Success

Wireless Connection between Laptop and WRT300N will be visible.

Connection Testing


Open the command prompt of Laptop, and verify ping to WRT300N and Radius Server.

Basic Wireless with Linksys WRT 300N - PT

Using Cisco Packet Tracer 7.1

Setup will comprise 2 components
  1. Linksys WRT 300N wireless router (Network Devices -> Wireless Devices ->WRT300N)
  2. Laptop ( End Devices -> End Devices -> Laptop)
Laptop by default do not contain wireless card.  We have to physically configure like the following:
  1. Click on laptop -> 'physical' tab 
  2. Click and drag the ethernet module on the image, to the left panel.  A empty slot will be created
  3. Click and drag 'WPC300N' to the empty slot
Aim, is to establish connection from laptop to router thru WPA2-AES wireless encryption.

We configure on wireless router 
  1. Click router -> 'Config' tab -> 'Wireless' section
  2. SSID 'actwifi' ; Authentication 'WPA2-PSK' ; PSK Pass Phrase '12345678' ; Encryption 'AES'
Router Configuration
Now laptop configuration
  1. Click laptop ->'Config' tab -> 'Wireless' section
  2. SSID 'actwifi' ; Authentication 'WPA2-PSK' ; PSK Pass Phrase '12345678', Encryption Type 'AES'
  3. IP Configuration 'DHCP'
Move the mouse over laptop, information of wireless connection(Data rate, signal strength) and DHCP alloted IP address 192.168.0.101 can be seen.

Connection Success
To verify ping, click laptop -> 'Desktop' tab -> 'Command Prompt' -> Issue ping command.

Sunday, August 26, 2018

TCP open connection with scapy

Today, I am going to try to create TCP 3-way connection with the help of scapy and iperf.  The full wireshark capture is
TCP 3-way Connection

192.168.1.10 (client: port 40508: scapy) ------->> 192.168.1.200 (server: port 5000: iperf)

As we donot have a conventional TCP client program running on the client side.  Whenever server sends SYN-ACK packet to client, the kernel on the client responds with Reset TCP connection.  To avoid this, we should place a rule in IPTables, to drop any Reset's packets initiated from client side.  This can be done using the following command on the client side:

# iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.1.10 -j DROP

On the server side, we create a server listening on port 5000, using 

# iperf -s -p 5000
------------------------------------------------------------
Server listening on TCP port 5000
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

In another session, observe that the output of netstat command, its in listen state

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN

On the client side, we open scapy session, send a TCP SYN packet and receive the response.  sr1 implies send (ip/SYN) and wait till ONE response is received.


# scapy
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
INFO: Can't import python Crypto lib. Won't be able to decrypt WEP.
INFO: Can't import python Crypto lib. Disabled certificate manipulation tools
Welcome to Scapy (2.2.0)
>>>
>>> ip=IP(src="192.168.1.10",dst="192.168.1.200")
>>> SYN=TCP(sport=40508,dport=5000,flags="S",seq=0)
>>> SYNACK=sr1(ip/SYN)
Begin emission:
.......Finished to send 1 packets.
.*
Received 9 packets, got 1 answers, remaining 0 packets

Netstat on the server side, the state would have been

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.200:5000      192.168.1.10:40508      SYN_RECV

Now, on the client, we create and send the 3rd handshake message ACK to complete the TCP connection. This has to be sent as quick as possible, because there is a chance that the server may have timed out and dropped the TCP connection.

>>> ACK=TCP(sport=40508,dport=5000,flags="A",seq=SYNACK.ack+1,ack=SYNACK.seq+1)
>>> send(ip/ACK)
.
Sent 1 packets.

Netstat shows that the TCP connection is established.

# netstat -na | grep 5000
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN
tcp        0      0 192.168.1.200:5000      192.168.1.10:40508      ESTABLISHED

Tuesday, July 31, 2018

DHCP Broadcast - Notes

In my last post on DHCP, DHCP Offer and DHCP ACK were unicast frames.

DHCP Unicast Flag
In the Bootp Flags, the broadcast bit is set to 0(means unicast).  It means DHCP Client tells that it is expecting unicast responses from DHCP server.  So, the reply from DHCP server(DHCP Offer and DHCP ACK) will have Unicast MAC and IP Addresses. 

On a linux machine, this can be seen using command 'dhclient eth0'

Broadcast

There are cases when they will be broadcast.  From linux machine, we can use 'dhclient -B eth0' to request Broadcast responses.  Most of the times, DHCP starts from DHCP Offer, instead of Discovery.  So, by googling I found that we had to release the existing IP address for the transaction to happen from Discovery.  Like this

# dhclient -r  eth0
# dhclient -B  eth0

DHCP Broadcast
Observe that the Bootp flag here is '1'(means Broadcast flag set).  Client is asking the server to give broadcast responses.  Therefore, the DHCP Offer and ACK from the server has broadcast MAC and IP addresses.


Sunday, July 29, 2018

DHCP Notes

Dynamic Host Configuration Protocol.  Server automatically gives IP address to those machine that request it.

  • Message Exchanges (DORA), Discovery, Offer, Request, Acknowledgement.  
  • UDP Protocol - port 68 (server) - port 67 (client)
  • Wireshark decodes it as Bootp Protocol, because Bootp also uses same port numbers
  • Transaction ID same for one transaction of DHCP packets

DHCP

DHCP Discovery

  • DHCP Client ---> DHCP Server
  • Source MAC is client's MAC.  Destinatation MAC is FF:FF:FF:FF:FF:FF 
  • Source IP is 00:00:00:00 (it was not configured with any IP address yet)
  • Destination IP is FF:FF:FF:FF (not sure which one is DHCP server)
DHCP Discovery

DHCP Offer

  • DHCP Server ----> DHCP Client
  • Source MAC and Destination MAC self-explanatory
  • Source IP (Server)
  • Destination IP(Client).  
  • This packet is unicast, but client's IP address is not yet configured. Some cases, the packet will be broadcast.  This needs explanation and it will be done in the next tutorial with Scapy.
  • 'Your (client) IP address' is the IP address given by server to client
  • Rest of the fields are self-explanatory
DHCP Offer

DHCP Request

  • DHCP Client ---> DHCP Server
  • Source MAC is client's MAC.  Destinatation MAC is FF:FF:FF:FF:FF:FF 
  • Source IP is 00:00:00:00 (it was not configured with any IP address yet)
  • Destination IP is FF:FF:FF:FF 
  • The reason why destination MAC and IP are broadcast, even though the client is aware about the server IP address is:  It helps other DHCP servers in the network to be aware that the client has already got hold of another DHCP server and it can reallocate the client-offered IP address to some other machine.
  • Client requests the IP address to the server, and configures IP address on its interface
DHCP Request

DHCP Acknowledge

  • DHCP Server ---> DHCP Client
  • Client would have configured IP address by now, so Destination MAC and IP will be of Client's.
  • All the properties will be the same that of DHCP Offered packet
DHCP Ack

Sunday, July 22, 2018

DNS Notes

While browsing, we give the URL, 'www.xyz.com' something like that.  In internet, it is always converted into IP address for any further processing.  For conversion, we use DNS protocol, Domain Name System.

  • Query & Response
  • UDP protocol, 53 port
DNS Query

DNS Response

Observations
  • Transaction ID is same for both Query and Response
  • In flags, query is 0, response is 1
  • Type: Record type.  A is mapping IPv4 address and DNS name.  MX is mapping IPv4 address and Mail Exchange server.
  • Class: of a Record. belongs to 'IN' Internet name space.

Thursday, June 14, 2018

ARP Notes

I am not going to describe more in detail of the packet formatting.  ARP is the protocol primarily used to retrieve MAC address of a known IP address.  In addition to Ethernet header, following are some of the contents that we usually see (in Ethernet network)
  • Size of MAC address
  • Size of IP address
  • Option(request or reply)
  • Sender MAC address
  • Sender IP address
  • Destination MAC address
  • Destination IP address
Scenario 1

For convenience, we say PC1 is PC with IP address 192.168.1.1 and PC10 is PC with IP address 192.168.1.10

PC1 is wants to get MAC address of PC10.


After this packet reaches PC10, "PC10 will update PC1 details in its ARP cache" by looking ARP request. PC10 will reply to PC1.
PC1 will update PC10 details.  From then on, PC1 and PC10 will not ask for the MAC details of its peers.  Once information is received, till the time the MAC entries are not flushed in its ARP cache, it will use the MAC addresses.

Scenario 2

This is about gratuitous ARP.  A new machine connected to a network advertises its details.  It depends on OS implementation.  I say PC100 is the machine.


  • Dest. MAC in Ethernet header is FFFF..... It is destined for all machines.  If destined for unique machine, all machines will drop the packet and not process it.
  • It will always be ARP request
  • Source MAC in Ethernet Header = Source MAC in ARP packet
  • Source IP in ARP packet = Destination IP in ARP packet
  • Target MAC is all 0s, because it has to abide by the packet structure of ARP Request.