Linux Firewalls - Michael Rash [124]
22:14:51.098233 IP 71.157.X.X.80 > 144.202.X.X.37788: R
3646903381:3646903381(0) win 0
22:14:51.313974 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1
win
1460 22:14:51.314043 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0 22:14:51.748920 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 22:14:51.748969 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0 22:14:52.610322 IP 144.202.X.X.37788 > 71.157.X.X.80: P 1:229(228) ack 1 win 1460 22:14:52.610396 IP 71.157.X.X.80 > 144.202.X.X.37788: R 3646903381:3646903381(0) win 0 The NF_DROP Macro A look at the source code confirms that the iptables REJECT target drops matching packets. Specifically, if you look at the file linux/net/ipv4/netfilter/ipt_REJECT.c in the kernel sources, you will see the following return statement at three places in the reject() function (and there are no other return statements): return NF_DROP; Thus, the macro NF_DROP is the only possible return value for the reject() function, and it instructs iptables to drop any matching packet on the floor. A matching packet is prevented from continuing up the stack or being forwarded on to its intended destination. Therefore, in our attack example, even if the attacker filters the incoming RST, the webserver still never sees the incoming /Setup.php attack. * * * [66] 3 Recall from Chapter 3 that this RST packet from iptables does not have the ACK bit set because the malicious packet that triggered the rule match is part of an established TCP connection and therefore itself has the ACK bit set, and RFC 793 mandates that any RST packet generated in response to such a packet will not set the ACK bit. A RST/ACK is sent only if the previously received packet did not set the ACK bit. Thwarting Metasploit Updates The Metasploit Project (http://www.metasploit.com) is one of today's most important open source security projects. Its continued development has far-reaching implications for computer security, and it is consistently rated among the top security tools by security researchers in Fyodor's Top 100 Network Security Tools list (http://www.sectools.org). Metasploit is a pluggable framework for automating the development and use of attacks for software vulnerabilities, and the community that has built up around Metasploit has contributed greatly to the state of vulnerability research and automation. (As with many security technologies, Metasploit's exploit capabilities can be abused by those who endeavor to break into systems, but the net effect of Metasploit on the security landscape is a positive one—more software vendors will pay greater attention to security.) Metasploit Update Feature If people are using your corporate network as a launching point for Metasploit attacks, they are almost certainly violating your local security policy (unless this is an officially sanctioned activity such as a professional penetration test). One good way to detect such activity is to look for traffic associated with the Metasploit update process. The Metasploit developers regularly release exploits for new vulnerabilities, and Metasploit provides an online feature for its exploit database so that users can take advantage of these new exploits without having to wait for the next Metasploit release. From a security perspective, it is not so interesting when a user casually browses to the http://www.metasploit.com website. It is much more interesting when a user is actually using the software, and the Metasploit update process is a good indicator of such activity. The goal of this section is to show how fwsnort and psad can work together to stop Metasploit updates once a Snort rule is developed. All Metasploit updates take place over SSL by default with a self-signed SSL certificate. Figure 11-1 shows a Metasploit client launching an update through an iptables firewall running fwsnort and