Until I can find somewhere to host my slides, I'll post the "core" of the talk here.
I like using IPtables to solve problems because it adds a bump between the kernel and the application/service. If you can "solve" a problem using IPtables, you can implement that solution for any app without re-coding or re-configuring.
Of course, best practice is to use good auth & encryption with standard solutions, like SSL/TLS. Enough about that for now.
Most of the tricks I know are based on the '
-m recent' filter, which stores an IP address and timestamp(s) in a named recency table. Don't confuse this with the state tables like ESTABLISHED or chains like INPUT. It's a different beast altogether.
Trick 1:
Port knocking with IPtables.
In this trick, create a finite state machine using multiple new chains and recency tables. The way it works is that the INPUT chain checks to see if the IP address is in the recency table for a state, moves to the associated chain, and adds the address to the recency table for the next state. Here's a 4 state example:
- icmp ping
- TCP echo
- TCP port 8000
- TCP port 3306
- icmp ping:
iptables -A INPUT -p icmp --icmp-type 8 -m recent --name seenping --set -j ACCEPT
The filters in this line are "-p icmp --icmp-type 8", icmp echo-request (ping), and can be narrowed down more with -s or -d options. The final action for this line is "-j ACCEPT", to send the packet through. The differentiator is "-m recent --name seenping --set", which adds the source IP address of the packet to the recency table called "seenping".
- tcp echo
iptables -N ADD_ECHOiptables -A INPUT -p tcp --dport echo -m recent --name seenping --rcheck -j ADD_ECHOiptables -A ADD_ECHO -m recent --name seenecho --set -j ACCEPT
Line a: Create a new chain called ADD_ECHO to represent the 2nd state in the finite state machine. It's necessary to use an additional chain for each state, as the "-m recent" syntax only allows for a single recency table reference per command. Fortunately, recency tables references can be isolated into different chains, as in lines b and c.
Line b: This is the filter command. If the packet matches the next state, TCP echo, with the source IP address listed in the "seenping" recency table, then move processing to the ADD_ECHO chain.
Line c: the ADD_ECHO chain only does 2 things: add the source IP address to the "seenecho" recency table (priming the filter for the next state), and allowing the packet. Priming the next state is handled by "-m recent --name seenecho --set".
The action in line c is '-j ACCEPT'. During my talk, there was a great question: does the action have to be an ACCEPT? The answer is, no, it can be whatever you want. There can even be no action listed in this policy. If iptables reaches the end of the ADD_ECHO chain without finding a terminating action (.e.g ACCEPT, DROP, REJECT), it will automatically pop the stack back to the calling chain. Additionally, returning to the calling chain can done explicitly via the "-j RETURN" action target.
- Back-end port: TCP 8000
iptables -N ADD_BACKENDiptables -A INPUT -p tcp --dport 8000 -m recent --name seenecho --rcheck --seconds 10 -j ADD_BACKENDiptables -A INPUT -m recent --name seenecho --removeiptables -A ADD_BACKEND -m recent --name seenbackend --set -j ACCEPT
Line a: Create iptables chain called "ADD_BACKEND" to allow state transition to the next state, from 8000 to 3306.
Line b: Filter the incoming packets and trigger the execution of the ADD_BACKEND chain. The filter here is "-p tcp --dport 8000", combined with the source IP address listed in the "seenecho" recency chain. The action is to jump to the "ADD_BACKEND" chain.
The new parameter in line b is the "--seconds" filter. An attacker might be port-scanning the system and accidentally open the state machine up to this state. Placing a time restriction is a simple method of reducing false positives on the port knock.
Line c is the next line in the INPUT chain after the state transition filter. If the packet is NOT a match, line c will clear the IP address out of the "seenecho" recency table. If the client IP host does ANYTHING other than try to connect to TCP port 8000 after sending the TCP echo, the state machine will reject its actions as invalid, and the port knock will fail. What happens from here isn't specified in this example, so the client could re-send a TCP echo to reset the state and timer for "seenecho". (Note that the IP is never explicitly purged from "seenping", which is probably bad practice.) Alternatively, the IP address could be banned for a period of time using another IP tables rule or trick.
Line d is the state progression command, same as step 2.
- TCP port 3306
iptables -A INPUT -p tcp --dport 3306 -m recent --name seenbackend --rcheck -j ACCEPT
The closing state of the state table allows the client IP address to connect to the mysql port. Since there's no "next" state, there's no need for another recency table, nor for another chain.
An alternate version of this step would be to create a chain specifically for the "opened" state to aid in overall policy maintenance through separation of rules into discrete chains.
iptables -N MYSQL_OPENEDiptables -A INPUT -m recent --name seenbackend --rcheck -j MYSQL_OPENEDiptables -A MYSQL_OPENED -p tcp --dport 3306 -j ACCEPT
If there is additional packet-munging you want to perform once the port knocking is done, use this second approach, and replace line c with whatever you want at this stage of the policy.
Note that, for each stage of this example, state progression happened blindly as the first rule in a chain. If the overall iptables policy is modified to include additional references to that chain, there will be additional methods of prgressing through the port knock. Whether or not this is a good idea is up to you.
So, there you have it. That's a 4-stage port knock with false positive rejection done entirely in IPtables, using 3 recency tables for state storage, plus 3 chains (beyond INPUT and ACCEPT) for state progression.
If you have read this far, you have all of the knowledge necessary for the next batch of Stupid IPtables Tricks, which I'll put in my next blog post.
To
really make sure you understand the recency tables, check out the excellent example in the iptables tutorial called
recent-match.txt. If I hadn't slogged through it, I wouldn't know how this stuff works.
