Network - From the NIC to the Internetz

Free TCP 443 :

Setup SSLH (source, man page) :

Re-configure SSH accordingly :

1. disable the existing rules (the way you'll do this depends on your setup : you _may_ not want to flush everything )
2. create the new rules :

   iptables -I INPUT -p tcp -d 127.0.0.1 --dport 22 -m state --state NEW -m recent --set
   iptables -I INPUT -p tcp -d 127.0.0.1 --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP

3. test the new rules
4. make them reboot-proof :
   systemctl enable netfilter-persistent.service && systemctl start netfilter-persistent.service

configure the webserver so that it listens on 127.0.0.1:443 instead of 0.0.0.0:443

                    binary                                  decimal
host address        aaaaaaaa.bbbbbbbb.cccccccc.00101000     10.27.25.40
subnet mask         11111111.11111111.11111111.11100000     255.255.255.224
                    |<----------27 bits--------->|

subnet address      aaaaaaaa.bbbbbbbb.cccccccc.00100000     10.27.25.32		host address AND subnet mask
broadcast address   aaaaaaaa.bbbbbbbb.cccccccc.00111111     10.27.25.63		subnet address with host bits set to 1

CLOSE_WAIT (sources : 1, 2)

CLOSE_WAIT means that the local end of the connection has received a FIN from the other end, but the OS is waiting for the program at the local end to actually close its connection.

Having plenty of CLOSE_WAIT is caused by a program running on the local machine not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the connection open. It's the responsibility of an application (i.e. not to the OS) to close its socket once the remote computer closes its side of the TCP communication.

Once the local program closes the socket, the OS can send the FIN to the remote end which transitions you to LAST_ACK while you wait for the ACK of the FIN. Once that is received, the connection is finished and drops from the connection table.

If you are seeing a large number of connections persisting in CLOSE_WAIT state it's probably a problem with the app itself : connections have been torn down but your side of things still has a file descriptor open.
Solutions :

• restart the application : it will clear the connections temporarily but obviously the same problem will occur later on.
• kill processes in CLOSE_WAIT state : will get you rid of those connections, but it can be dangerous because these processes still have right to send remaining data in queue
• fix your software

TIME_WAIT

When an application connection is closed between a server and its client, TCP maintains the connection for a little while before effectively closing it. "Closing" a connection actually means releasing a pair of connection sockets, that are instantly available for new connections. Keeping the connection "alive" for some extra seconds is just in case some packets were lost / late and prevent them from :

• reaching a newly established connection with the same as before sockets numbers
• OR being replied with a RST signal (source)

keepalive (details in RFC 1122)

Periodically probes the other end of a connection when the connection is idle, even when there is no data to be sent.
Used in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure.

1. enumerate the existing devices to identify those to be bridged : ip addr show
2. bring down the interfaces to bridge : ifdown eth0; ifdown eth1
3. create the bridge interface : brctl addbr br0 (br0 is just an example, you can name the bridge interface as you like)
4. "connect" the eth0 and eth1 interfaces to the br0 bridge : brctl addif br0 eth0 eth1
5. bring the br0 interface up, and voilà! This is the only interface that will get an IP address (?)

1. Edit /etc/network/interfaces so that it looks like :
   • For general purpose :

     # The loopback network interface
     auto lo br0
     iface lo inet loopback
     
     # Set up interfaces manually, avoiding conflicts with, e.g., network manager
     iface eth0 inet manual
     iface eth1 inet manual
     
     # Bridge setup
     iface br0 inet dhcp
     	bridge_ports eth0 eth1

   • For virtualized environments :

     # The loopback network interface
     auto lo br0
     iface lo inet loopback
     
     # Set up interfaces manually, avoiding conflicts with, e.g., network manager
     iface eth0 inet manual
     iface eth1 inet manual
     
     # Bridge setup
     iface br0 inet dhcp
     	bridge_stp	off		# disable Spanning Tree Protocol
     	bridge_waitport	0		# no delay before a port becomes available
     	bridge_fd	0		# no forwarding delay
     	bridge_ports	none		# if you do not want to bind to any ports
     	bridge_ports	regex eth*	# use a regular expression to define ports

2. To enable the bridge : ifup br0

• list devices in a bridge : brctl show br0
• remove an interface from a bridge : brctl delif br0 eth0
• shutdown a bridge : brctl delbr br0

1. on the host having the files to share (aka theServer), cd to the directory containing those files
2. share files :
   • with Python 2 : python -m SimpleHTTPServer port
   • with Python 3 : python -m http.server port
3. On the client side, files will be available at http://theServer:port. You can retrieve files easily with wget -c url

Let's start by generating some test data :

The Python method :

The scp method :

The Rsync method :

Results :

Proxy settings are saved in /etc/profile or /etc/environment (system-wide settings) or in ~/.bashrc (personal settings including proxy credentials) :

export http_proxy="http://proxyUser:proxyPassword@proxyHost:proxyPort/"
export https_proxy=$http_proxy
export ftp_proxy=$http_proxy

After editing one of these files, reload it : source theFileIJustEdited

All fields (and especially the password) must be url-encoded.

• ARP is used to convert IP addresses (or hostnames) into MAC addresses. It's implemented in all the operating systems that are able to connect to a network.
• RARP is reverse-ARP and converts MAC addresses into IP addresses. It's seldom implemented in operating systems since once any host is reachable through ping, a basic arp -a | grep any_MAC_address may output the answer.

Before going further, make sure you understand the basics of ARP. If you want to know more, just have a look at the RFC 826. FrameIP.com also seems to be a good starting point.
Our target is to play the MitM, capture some traffic and understand why switched environments security is a fairy tale. You should read first this presentation on ARP attacks with arp-sk (french version).
This means we're about to alter the ARP table of a distant host (target) with fake IP-MAC value pairs to let target believe it's connected to resource whereas it's actually connected to sniff. But since packets are expected back from resource to target, we also have to let resource believe it's connected to target, whereas it's actually connected to sniff.

To do so, we'll have to :

• route packets going through sniff
• perform double simultaneous ARP cache poisoning

Format of ARP requests :

Who has target_IP ? Tell sender_IP

The ARP packet itself contains (among other things) :

Ethernet Frame (or "Link Layer")		arp-sk option
SRC MAC	MAC address of host sending the request	-s (can be used to specify either MAC / IP / host)
SRC IP / host	(not used)
DST MAC	broadcast : ff:ff:ff:ff:ff:ff	-d (can be used to specify either MAC / IP / host)
DST IP / host	(not used)
ARP message		arp-sk option
Sender MAC	MAC address of host sending the request	-S :MACxx:xx:xx:xx:xx:xx
Sender IP	IP address of host sending the request	-Sxxx:xxx:xxx:xxx
Target MAC	00:00:00:00:00:00	-D :MACxx:xx:xx:xx:xx:xx
Target IP	IP address of host receiving the request	-D xxx:xxx:xxx:xxx

• The ARP protocol doesn't specify there MUST be consistency between the Ethernet frame data and the ARP message content itself.
• Dynamic ARP cache entries expire after 2 minutes when unused. Otherwise, used entries are automatically renewed every 10 minutes (details 1, details 2).
• Some operating systems like Solaris do not accept ARP replies without first initiating an ARP request, so they are not vulnerable to this attack. In this case, an ICMP spoofed packet (ping) is used. The goal is to get a valid entry in target's ARP cache, because when they receive an ARP reply from you they will first check their cache to see if you're already there and if you're not, they simply won't add you at all.

• from GitHub
• for FreeBSD

arp-sk -w -d host -s MAC -S IP -c 1

• -w means we're sending a fake ARP "who has ... ?" query
• host is the hostname / IP of the machine which ARP cache is going to be modified
• MAC is the MAC address to insert into host's ARP cache
• IP is the IP address matching MAC in host's ARP cache
• -c n : send n packets. If omitted, packets will be sent continuously (which is a good thing anyway since ARP cache could be refreshed with "good" values, which is not what we want.)
• -T n : wait n seconds (or un microseconds) between sending each packet. You can also use --rand-time n to randomize the sending period between -n and +n.

To perform a DoS :

• host is the IP / hostname of the station you want to disconnect
• MAC is fake (01:23:45:67:89:0a works fine but looks too obvious. Have a look at the --rand-arp option)
• IP is the IP / hostname of the resource host will be disconnected from

To perform a MitM attack :

1. enable packet routing on sniff
2. As sniff, make target believe you're resource : arp-sk -w -d IP_t -s MAC_sniff -S IP_r
3. As sniff, make resource believe you're target : arp-sk -w -d IP_r -s MAC_sniff -S IP_t

• the gateway must be on the same network than the current network interface.
• the default gateway should be the one through which go the greatest number of routes instead of the network traffic.

• On Evergreen (SuSE 9.0), I have to declare :

  route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.5.1 eth0
  route add -net 192.168.4.0 netmask 255.255.255.0 gw 192.168.4.3 eth1

  so that the kernel knows where to send packets.
• On P600 (XP Pro), I just have to define 192.168.5.1 as the default gateway.

• On Atlantis (Mandrake 9.2), the appropriate routes are defined while setting up the Internet connection
• On Evergreen (SuSE 9.0), I just have to declare that Atlantis is the default gateway to the Internet. To do so:

  route add default gw 192.168.4.2 eth1

  Explanations:
  • route add : usual command to add a route towards a new host or a new network.
  • default : it's an alias for -net 0.0.0.0 netmask 0.0.0.0. It means all the networks, whatever netmask they have, which matches with Internet. It's also to specify to apply this route whenever none of the others routes match.
  • gw : for gateway. Just a keyword of the route command.
  • 192.168.4.2 : This is the address where Evergreen's packets should be sent in order to reach Internet. This is Atlantis'IP address.
  • eth1 : the interface through which the packets must be sent to 192.168.4.2.

echo 1 > /proc/sys/net/ipv4/ip_forward

Running this on the router side will overwrite the existing /proc/sys/net/ipv4/ip_forward file and simply write a 1 inside.

• Linux : route add -net networkAddress netmask netmask gw gatewayToTargetNetwork ethX
• W2K : route add networkAddress mask netmask gatewayToTargetNetwork

ifconfig wlan1 down hw ether 00:15:AF:99:3E:27 && ifup wlan1

As this is a software hack, the real MAC address will be restored the next time the interface will be "re-discovered" by the kernel : reboot or reload of the kernel module.

1. Edit /etc/network/interfaces
2. Find the section matching the interface you want to edit. Should look like :

   allow-hotplug eth0
   iface eth0 inet dhcp

3. Append a new line with the new MAC address :

   allow-hotplug eth0
   iface eth0 inet dhcp
   	hwaddress ether B0:0B:50:00:00:02

4. Restart the network, and check the new settings : service networking restart; service networking restart; ip link show eth0
   I don't know why so far, but it doesn't work unless you restart the network twice...

   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
   link/ether b0:0b:50:00:00:02 brd ff:ff:ff:ff:ff:ff

And it also survives a reboot

• dhclient eth0
• ifdown eth0 && ifup eth0
• /etc/init.d/networking restart

• configuration : /etc/dhcp3/dhclient.conf
• leases :
  • for all interfaces : /var/lib/dhcp3/dhclient.leases
  • for each interface : /var/lib/dhcp3/dhclient.wlan0.leases

• Telnet
• Netcat
• Nmap

Test the socket (source) :

Send an HTTP request (source) :

https://stackoverflow.com/questions/18743962/python-send-udp-packet/62275967#62275967

import socket

UDP_IP = "10.27.25.129"
UDP_PORT = 123
MESSAGE = "hello world"

print("UDP target IP: %s" % UDP_IP)
print("UDP target port: %s" % UDP_PORT)
print("message: %s" % MESSAGE)

sock = socket.socket(socket.AF_INET, # Internet
                     socket.SOCK_DGRAM) # UDP
sock.sendto(MESSAGE.encode(), (UDP_IP, UDP_PORT))

Test the socket (source)

Send an HTTP request (source, details about redirections and file descriptors) :