'Invisible Intercept' Function Of Burp

The little used 'invisible intercept' function in Burp can be useful if testing basic client applications that do not support proxy settings, or in the case of the test I was on this week, to intercept Flash applications (that do not honour proxy settings in Chrome). Unfortunately there is little information on how to actually force your [locally generated] traffic through the proxy using iptables.

As a proxy will always 'terminate' a TCP connection and create a new one to the target server, it's not quite as simple as you may think. If you intercept and redirect everything going out on port 80 in the 'OUTPUT' chain, you'll create an infinite loop; iptables simply does not know whether the outbound connection has already been intercepted - unlike the PREROUTING chains you cannot test for originating interface/address or mark packets to indicate they have already passed through the chain. 

The upshot is that you *must* run your client app as a different user to allow iptables distinguish between a request from the proxy and the client app. You can then test for the process owner uid and route accordingly:

iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner <PROXY UID> -j REDIRECT --to-port 8080

The above example will only redirect packets not originating from the UID of the proxy process. If you're going to be doing this on a regular basis, run your intercepting proxy as a dedicated user on the machine (not standard practice for tools such as Burp). If you just want to test it against a client app you trust, and you understand the risks, run your browser as root.