TOR nmap scanning and esuring they fail closed

I recently ran into an issue where we had a nmap scan going over TOR, then for some reason proxychains shit the bed and it started to leak the real IP address of the server.

That's obviously not very nice, so how can we prevent this? Assuming you setup TOR to run as a specific user ID, debian-tor in my case, you can use the following iptables rules to ensure that attempts to connect to the scanning ip address will fail closed.

 #!/bin/bash  
 TOR_EXCLUDE="192.168.0.0/16 172.16.0.0/12 10.0.0.0/8"  
 # The UID Tor runs as  
 # change it if, starting tor, the command 'ps -e | grep tor' returns a different UID  
 # TOR_UID="debian-tor"  
 TOR_UID="debian-tor"  
 # Tor's TransPort  
 TOR_PORT="9040"  
 iptables -t nat -A OUTPUT -m owner --uid-owner $TOR_UID -j RETURN  
 iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53  
 iptables -t nat -A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53  
 iptables -t nat -A OUTPUT -p udp -m owner --uid-owner $TOR_UID -m udp --dport 53 -j REDIRECT --to-ports 53  
 #resolve .onion domains mapping 10.192.0.0/10 address space  
 iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040  
 iptables -t nat -A OUTPUT -p udp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040  
 #exclude local addresses  
 for NET in $TOR_EXCLUDE 127.0.0.0/9 127.128.0.0/10; do  
 iptables -t nat -A OUTPUT -d $NET -j RETURN  
 done  
 #redirect all other output through TOR  
 iptables -t nat -A OUTPUT -p tcp --syn -j REDIRECT --to-ports $TOR_PORT  
 iptables -t nat -A OUTPUT -p udp -j REDIRECT --to-ports $TOR_PORT  
 iptables -t nat -A OUTPUT -p icmp -j REDIRECT --to-ports $TOR_PORT  
 #accept already established connections  
 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  
 #exclude local addresses  
 for NET in $TOR_EXCLUDE 127.0.0.0/8; do  
 iptables -A OUTPUT -d $NET -j ACCEPT  
 done  
 #allow only tor output  
 iptables -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT  
 iptables -A OUTPUT -j REJECT  

Most of this was taken from ParrotSec's anonsurf module, which I ported to work with Kali and most other Debian based OSes. If you install and use that module, it will automate all of the setup.

Using these iptables rules, your OS should drop any packets that aren't routing through TOR. In the example below, you can see I used the -A switch which nmap seems to ignore proxychains for.
(IP addresses have been changed)

 # proxychains nmap -A -Pn -v -p 6660,6282 8.8.8.8  
 ProxyChains-3.1 (http://proxychains.sf.net)  
 Starting Nmap 6.49BETA5 ( https://nmap.org ) at 2015-12-01 13:04 EST  
 NSE: Loaded 122 scripts for scanning.  
 NSE: Script Pre-scanning.  
 Initiating NSE at 13:04  
 Completed NSE at 13:04, 0.00s elapsed  
 Initiating NSE at 13:04  
 Completed NSE at 13:04, 0.00s elapsed  
 Initiating Parallel DNS resolution of 1 host. at 13:04  
 Completed Parallel DNS resolution of 1 host. at 13:04, 0.29s elapsed  
 Initiating SYN Stealth Scan at 13:04  
 Scanning (8.8.8.8) [2 ports]  
 Completed SYN Stealth Scan at 13:04, 3.06s elapsed (2 total ports)  
 Initiating Service scan at 13:04  
 Initiating OS detection (try #1) against (8.8.8.8)  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49466 > 8.8.8.8:37521 A ttl=40 id=44666 iplen=60 seq=2536213131 win=32768  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49467 > 8.8.8.8:37521 FPU ttl=45 id=25588 iplen=60 seq=2536213131 win=65535  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49466 > 8.8.8.8:37521 A ttl=38 id=39622 iplen=60 seq=2536213131 win=32768  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49467 > 8.8.8.8:37521 FPU ttl=57 id=46900 iplen=60 seq=2536213131 win=65535  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49466 > 8.8.8.8:37521 A ttl=59 id=11645 iplen=60 seq=2536213131 win=32768  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49467 > 8.8.8.8:37521 FPU ttl=47 id=65288 iplen=60 seq=2536213131 win=65535  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49466 > 8.8.8.8:37521 A ttl=58 id=16083 iplen=60 seq=2536213131 win=32768  
 sendto in send_ip_packet_sd: sendto(5, packet, 60, 0, 8.8.8.8, 16) => Operation not permitted  
 Offending packet: TCP 192.168.15.169:49467 > 8.8.8.8:37521 FPU ttl=53 id=41775 iplen=60 seq=2536213131 win=65535  

(IP addresses have been changed)

Now compare that to:

 # proxychains nmap -sT -Pn -v -p 6660,6282 8.8.8.8  
 ProxyChains-3.1 (http://proxychains.sf.net)  
 Starting Nmap 6.49BETA5 ( https://nmap.org ) at 2015-12-01 11:47 EST  
 Initiating Parallel DNS resolution of 1 host. at 11:47  
 Completed Parallel DNS resolution of 1 host. at 11:47, 16.50s elapsed  
 Initiating Connect Scan at 11:47  
 Scanning 8.8.8.8 [2 ports]  
 |S-chain|-&lt;&gt;-127.0.0.1:9050-&lt;&gt;&lt;&gt;-8.8.8.8:6660-<--denied data-blogger-escaped-br="">|S-chain|-&lt;&gt;-127.0.0.1:9050-&lt;&gt;&lt;&gt;-8.8.8.8:6282-<--denied data-blogger-escaped-br="">Completed Connect Scan at 11:47, 0.55s elapsed (2 total ports)  
 Nmap scan report for 8.8.8.8  
 Host is up (0.27s latency).  
 PORT   STATE SERVICE  
 6282/tcp closed unknown  
 6660/tcp closed unknown  
 Read data files from: /usr/bin/../share/nmap  
 Nmap done: 1 IP address (1 host up) scanned in 17.09 seconds  

(IP addresses have been changed)

The most important moral of this story is to ensure you are doing a TCP Connect scan (-sT) when attempting to do nmap scans over TOR.