Selective HTTP Proxying in Linux, (Thu, May 21st)
\n \t
\n
<\/BR>
\n
\n \t
\n
<\/BR><\/p>\n
Recently, Rob wrote about a tool, Proxifier<\/a>, that can intercept requests from specific processes. Proxifier is available for Windows, macOS, and Android. But I have not seen a generic Linux option yet. The advantage of a tool like Proxifier is the ability to target specific software. For debugging, reverse engineering, and similar tasks, selecting a specific process is quite useful, as it creates less noise to sift through and simplifies analysis.<\/p>\n There are a few methods for how proxies are usually configured in Linux:<\/p>\n Many software programs look for the environment variables http_proxy and https_proxy. These environment variables\u00a0can be targeted by setting them for specific processes. Open a shell, set the environment variables, and run the software you wish to inspect in the same shell.<\/p>\n export http_proxy=\"http:\/\/proxy.example.com:80\" The Linux firewall code, iptables, has a number of lesser-known interesting options that can help. For example, traffic can be redirected for a specific user:<\/p>\n iptables -t nat -A OUTPUT -m owner --uid-owner\u00a01234\u00a0-j REDIRECT --to-ports\u00a08080<\/tt><\/p>\n<\/blockquote>\n This example will direct all traffic generated by the user with UID 1234 to port 8080. Now start the software as this specific user (maybe set up a test user for that purpose), and you will only see traffic created by this specific user. There is no option to select a pid as pids are constantly changing, and there may be multiple pids if the process uses multiple threads, which is common for networking.<\/p>\n Usually, a particular Linux system uses a single routing table. Network namespaces enable the creation of separate routing tables for different processes. First, you create a new namespace. You need to assign interfaces to it, as namespaces cannot\u00a0“see” network interfaces unless you explicitly add them.\u00a0<\/p>\n \nThere are a number of more complete “recipes”\u00a0for network namespaces available online. I find it\u00a0the most versatile solution, particularly if environment variables do not work. The iptables solution is often simpler than namespaces, but you may end up with some unintended additional traffic.<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n — (c) SANS Internet Storm Center. https:\/\/isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.<\/p><\/div>\n \tEnvironment Variables<\/h3>\n
\n
\nexport https_proxy=\"http:\/\/proxy.example.com:443\"
\n.\/software-under-test<\/tt><\/p>\n<\/blockquote>\niptables<\/h3>\n
\n
Network Namespaces<\/h3>\n
\n
ip netns add testing # adding namespace 'testing'
\nip link set dev ens18 netns testing # add ens18 interface to testing. However, most use virtual interfaces
\nip netns exec testing software-under-test # execute software-under-test in namespace<\/code><\/p>\n<\/blockquote>\n
\nJohannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu<\/a>
\nTwitter<\/a>|<\/p>\n
\n
<\/BR><\/p>\n