Attack mitigation solutions
Denial-of-Service attack
Upgrading the server’s resources could migrate DoS attack, however, that would require additional costs as well as potentially cause downtime. A better solution is to implement system firewall rules in order to block malicious packets from being processed. A common pattern with SYN flood attacks is that the Max Segment Size (MSS) is set to a high value or never set at all. This fact can be used to implement methods to protect from a SYN flood attack.
Configuring firewall rules
iptables was used to set up IPv4 packet filtering rules in the Linux kernel. The following command was issued on the Ubuntu server:
iptables -t mangle -I PREROUTING -p tcp -m tcp --dport 80 -m state --state NEW -m tcpmss ! --mss 536:65535 -j DROP
iptables -t mangle -I PREROUTING: Tells iptables to add a new incoming packet filtering rule.
-p tcp -m tcp --dport 80: Looks for TCP packets with the destination port of 80.
-m state --state NEW: Only filter new connections.
-m tcpmss ! --mss 5360:65535: Looks at packets that have an MSS between 5360 and 65535.
-j DROP: Do not process and drop any packets that match the criteria.
Configuring system security settings
Further configuration changes were made to the Ubuntu server in an attempt to mitigate a SYN flood attack. The sysctl.conf file is a configuration file that controls kernel-level system parameters. The following command was issued to edit the text file.
sudo nano /etc/sysctl.conf
Then the following line was uncommented in order to enable SYN cookies:
net.ipv4.tcp_syncookies = 1
SYN cookies is an attack mitigation solution in which the webserver responds to SYN requests with a pre-crafted SYN/ACK packet. This allows the server to keep resources free until the source sends back the ACK packet.
Next, the following line was added to the file:
net.ipv4.tcp_synack_retries = 3
This setting controls how many times the server will resend the SYN/ACK packet. The default is 5. Lowering this value allows the webserver to process packets faster.
The file was closed and saved as sysctl.conf.
After the firewall rules and system security settings were in place another SYN flood attack was issued against the webserver. A packet capture was taken during this second attack. The SYN flood was still able to commence, however, fewer incoming packets were being processed. Now the webserver was able to keep up with the number of SYN requests and did not deny connections.
Video of the website running during the SYN flood
Hydra login cracker
Hydra takes advantage of vulnerabilities in services running on the network. It is advised to restrict these services to only allow connections from trusted IP addresses. Access control lists were configured and implemented on the defend router to prevent future brute-force attacks.
The following commands were issued on the defend router while in global configuration mode:
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq ftp: Permits FTP packets coming from the 192.168.0.0 - 192.168.255.255 IP range to any destination.
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq 22: Permits SSH packets coming from the 192.168.0.0 - 192.168.255.255 IP range to any destination.
Next, the following commands were used while in global configuration mode to apply the access list.
interface gigbitethernet0/1: Switches to the interface configuration mode.
ip access-group 100 in: Applies the access list to inbound traffic.
Because there is an implicit deny statement with access control lists, the HTTP traffic had to be allowed along with OSPF hello messages. The following two access lists were applied to the defend router:
access-list 100 permit tcp any any eq www: Permits any HTTP traffic coming from any source destined to any IP address.
access-list 100 ospf permit ospf any any: Permits OSPF hello messages from any source to any destination.
The ping command was used on a host within the defend network after the access control lists were applied. The gateway interface to the network responded with a packet filtered message. This indicated that the host is up, but is not processing an echo-reply.
After the access control lists were configured the Hydra attack was run again. Another Wireshark packet capture was taken during the attack. A flood of retransmitted FTP packets was seen. This shows Hydra's attempt to attack the system, but it is unable to get through and keeps retrying.
Metasploit reverse shell
The Metasploit Framework exploit was mitigated by updating system services running on the network. It was also prevented entirely by limiting access to critical services such as FTP to only trusted IP addresses. All security strategies should be taken into consideration to prevent malicious attacks from all angles.
Very Secure File Transfer Protocol Daemon (VSFTPD) version 2.3.4 contains the vulnerability used in the Metasploit exploit. The service was updated to version 3.0.3 in order to patch the backdoor into the system. However, any version higher than 2.3.4 would have prevented this specific exploit.
The following command was issued to update the service: sudo apt-get install vsftpd
This command forces the system to check for any updates pertaining to the VSFTPD service and installs them.
The exploit was run again after the VSFTPD service was updated. A connection was made to the FTP server, however, the exploit was not successful. The FTP server was also seen running version 3.0.3.
A Wireshark packet capture was taken during the second attack. An FTP connection was still made to the server, however, the connection was reset immediately after the login attempt failed.