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)
# 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|-<>-127.0.0.1:9050-<><>-8.8.8.8:6660-<--denied data-blogger-escaped-br="">|S-chain|-<>-127.0.0.1:9050-<><>-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)
