The replace Snort option is only applicable when Snort is running in inline mode and is deployed inline to the packet data path. In this mode, Snort becomes a true intrusion prevention system with the ability to forward packets in and out of a protected network only after they have been inspected by Snort's detection engine. The replace option operates on application layer data and allows a sequence of bytes that have been detected by the content option to be replaced with a different sequence of equal length.
The requirement that the strings are of equal length stems from the fact that sequence and acknowledgment numbers must continue to make sense in the context of the existing TCP session. If a longer string were to be substituted, then the receiving side would receive more data than actually sent by the sender, and this would break TCP.
Within a Snort rule with Snort running inline, in order to have the string "/usr/local/bin/bash" replaced with "EqualLengthString!!", we would use the two options: content: /usr/local/bin/bash and replace: EqualLengthString!!. This type of operation is only supported by iptables if the --replace-string patch provided by the fwsnort project has been applied to the string match extension. This patch is only compatible with 2.4 kernels and takes liberties with the notion of an iptables "match," since matches are not supposed to modify packet data; a future version of this patch will implement a new iptables target that will allow packet data to be modified. In the meantime, on your old 2.4 kernel, the following command allows iptables to replace the string "/bin/sh" with "/abc/de" (which would never correspond to an actual path to a binary on a real system) in all TCP traffic over port 80:
[iptablesfw]# iptables -A INPUT -p tcp --dport 80 -m string --string "/bin/sh" --replace-string "/abc/de" -j ACCEPT
The target in the iptables rule above is set to ACCEPT, and so the packet is permitted to continue on to its destination even after modification takes place within the kernel. The webserver at the destination can then decide what to do with the funny-looking "/abc/de" path it receives; an application error code will most likely be generated and returned to the client.
Replacing application layer data en route requires transport layer checksums to be recalculated; this is mandatory for TCP and optional for UDP, depending on whether the original packet had the UDP checksum calculated first. Inline data replacement offers the potential to silently break certain exploits, and this is a stealthier method of responding to attacks than generating session-busting traffic or instantiating firewall blocking rules—such methods are loud and not easily missed by an attacker.
Was this article helpful?