LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-27-2018, 06:41 AM   #1
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Rep: Reputation: Disabled
"Address already in use." errors when trying to restart tor


I am running Tor 0.3.2.9 (git-9e8b762fcecfece6) installed via SBo on Slackware64-14.2 and today suddenly I've started to get the "Address already in use." error when I try to restart tor manually using /etc/rc.d/rc.tor restart

Code:
netstat -anp | grep 9050
Shows me the PID of a tor process. Neither kill PID nor kill -9 PID succeed with killing it, so it looks like it became unkillable.

I have even tried to rebuild and reinstall the tor package, but it didn't help.

The major change I did today just before this problem started was the kernel upgrade to 4.4.118 that fixes Spectre variant 1.

Code:
ps aux | grep tor
shows a D disk sleep (uninterruptible) state for the process

Edit1: I think I have narrowed it down a bit more. Once the system starts, tor starts fine. Restarting tor works fine. One of the things I'm using tor for is anonymizing traffic for a specific user, as described here https://trac.torproject.org/projects...raspecificuser As soon as I start a program as that user and it tries to go online - tor locks into D state, then I can't kill it. Even going to single user mode with init 1, then back to multiuser mode with init 3 (so this reloads the daemons) doesn't help. Only a full system restart.

Last edited by FlinchX; 02-28-2018 at 02:20 AM. Reason: Added more info
 
Old 02-28-2018, 08:23 AM   #2
coralfang
Member
 
Registered: Nov 2010
Location: Bristol, UK
Distribution: Slackware, FreeBSD
Posts: 836
Blog Entries: 3

Rep: Reputation: 297Reputation: 297Reputation: 297
What happens if you run this when the problem happens?
Code:
# kill -HUP $(pidof tor)
(this should restart the process)

Sometimes if tor isn't working (various reasons), this command tends to fix things for me.
 
Old 02-28-2018, 08:36 AM   #3
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by coralfang View Post
What happens if you run this when the problem happens?
Code:
# kill -HUP $(pidof tor)
(this should restart the process)
Nothing happens. Tor process stays locked in same state.

Quote:
Originally Posted by coralfang View Post
Sometimes if tor isn't working (various reasons), this command tends to fix things for me.
I've been using tor for years and this is the first time when I notice this problem.

PS: the other tor (the one that comes bundled with tor browser) is working fine, but I assume it's just used as socks proxy by the browser.
 
Old 02-28-2018, 08:49 AM   #4
coralfang
Member
 
Registered: Nov 2010
Location: Bristol, UK
Distribution: Slackware, FreeBSD
Posts: 836
Blog Entries: 3

Rep: Reputation: 297Reputation: 297Reputation: 297
Quote:
Originally Posted by FlinchX View Post
Nothing happens. Tor process stays locked in same state.



I've been using tor for years and this is the first time when I notice this problem.

PS: the other tor (the one that comes bundled with tor browser) is working fine, but I assume it's just used as socks proxy by the browser.
Yeah, the tor browser only send the actual browser requests through tor, if you want other apps to be routed through it you would need the tor daemon.

Well if it's any use, i am also running Tor version 0.3.2.9 (git-9e8b762fcecfece6) here, although with kernel 4.14.21, which appears to be working. Have you tried rebuilding the tor package? Only other thing i could suggest is try to use a different kernel, and see if the problem persists.
 
Old 02-28-2018, 09:19 AM   #5
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by coralfang View Post
Well if it's any use, i am also running Tor version 0.3.2.9 (git-9e8b762fcecfece6) here, although with kernel 4.14.21
It worked for me as well with all the kernels before this last update. I think 14.2 had at least 3-4 kernel updates.

Quote:
Originally Posted by coralfang View Post
Have you tried rebuilding the tor package?
I did that, as mentioned in the first post.

Quote:
Originally Posted by coralfang View Post
Only other thing i could suggest is try to use a different kernel, and see if the problem persists.
I'd like to wait for more feedback before getting myself involved into such a big adventure. I prefer to stick to the Slackware stock kernel, since it's been many years since I compiled my last kernel from source (and I never made kernel slackware packages compatible with stock ones). I don't even know if it's possible to just grab the kernel packages (which ones?) from -current and install them as upgrades in 14.2
 
Old 02-28-2018, 03:03 PM   #6
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
@FlinchX

The tor guys implemented some crypto/execution hardening in the latest tor versions (past 1/2 - 1 year). This might conflict with the Spectre/Meltdown kernel mitigation, but that would be also mentioned in the tor project page / forums. I cannot replicate your issue, because I quit using tor after they imposed that (Curve25519) elliptic-curves cryptography over AES, but can suggest to have a look at the tor output logs - I remember there was a launch file (DataDirectory) and the tor.log (defaults in syslog) file (available depending on where you have defined the paths in your torrc configuration file).
https://www.torproject.org/docs/tor-manual.html.en

Additionally, I hope that you are not launching tor as root and I would also suggest to compile an older tor version - 0.2.9 for example:
https://blog.torproject.org/category...stable-release

Last edited by abga; 03-01-2018 at 09:05 PM. Reason: factual about the crypto choice
 
Old 02-28-2018, 04:45 PM   #7
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
@FlinchX
but can suggest to have a look at the tor output logs[/url]
My biggest problem isn't even that tor stopped working (though that ruined a big chunk of my daily workflow), but that I can't just kill it without a full system restart. It looks like I'll need to try and replicate the problem by cloning my tor setup inside a virtual machine, at least restarting the virtual machine will be less painful and faster. Once I get time to do that, if I can replicate it, I will enable maximum verbosity for tor and see if I can get anything useful in the logs.

Quote:
Originally Posted by abga View Post
Additionally, I hope that you are not launching tor as root
I am running tor from SBo, it suggests creating a tor user/group for this, which I did. I did not step away from the recommended way of running tor - my tor process doesn't run as root.

Quote:
Originally Posted by abga View Post
I would also suggest to compile an older tor version - 0.2.9 for example:
https://blog.torproject.org/category...stable-release
I saw that tor also has a newer, alpha version, perhaps I shall try that too, but like I said above, I need to try the same version, to see if I can reproduce the issue.
 
Old 02-28-2018, 05:23 PM   #8
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by FlinchX View Post
My biggest problem isn't even that tor stopped working (though that ruined a big chunk of my daily workflow), but that I can't just kill it without a full system restart.
There is an interesting explanation/answer on the state observed on your tor process - first answer (the one with 460 approvals):
https://unix.stackexchange.com/quest...-does-not-work
https://en.wikipedia.org/wiki/Sleep_...ruptible_sleep
- this suggest a filesystem / network storage (I/O) issue, you might want to check that too

Generally, when the 9 (SIGKILL) signal doesn't work, you can always try 30 (SIGPWR) to ungracefully & instantly kill a weird behaving process.
https://unix.stackexchange.com/quest...f-kill-signals
 
1 members found this post helpful.
Old 02-28-2018, 07:55 PM   #9
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
There is an interesting explanation/answer on the state observed on your tor process - first answer (the one with 460 approvals):
https://unix.stackexchange.com/quest...-does-not-work
https://en.wikipedia.org/wiki/Sleep_...ruptible_sleep
I went through some of these before posting here in forum, to educate myself. Because it's literally the first time in my life when I hit this particular process behavior.

Quote:
Originally Posted by abga View Post
- this suggest a filesystem / network storage (I/O) issue, you might want to check that too
I run logwatch and I read the mail it sends everyday, also dmesg doesn't show any filesystem I/O errors.

I have to run r8168 for my network cards as you might remember from an older forum post, since the r8169 (IIRC) kernel driver has troubles. But all other network programs work fine, none of them jams like this. Even the other tor that's bundled with tor browser works fine, it didn't fail the same way ever, not a single time.

Quote:
Originally Posted by abga View Post
Generally, when the 9 (SIGKILL) signal doesn't work, you can always try 30 (SIGPWR) to ungracefully & instantly kill a weird behaving process.
Didn't work either.
 
Old 02-28-2018, 08:56 PM   #10
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
I took a look over the instructions & SlackBuild script at:
https://slackbuilds.org/repository/14.2/network/tor/

Compared them to my very old (3-4 years) tor compilation+installation+configuration notes and found out some differences:
- I remember and also have notes about the fact that I had issues with tor writing my log file and I had to define /var/log/tor/ as the home for the tor user. Proper r/w rights for the tor user should be also set for the DataDirectory & the folder where the geoip files are to be found. I configured /var/log/tor for everything tor needs and ran a: chown -R tor:tor /var/log/tor/
- I also used these two configure parameters when building tor:
Code:
--disable-largefile
--disable-threads
I'll maybe try to replicate your setup tomorrow if I have some time to goof around with the SlackBuild, as I already have the 4.4.118 kernel in place on a system.

EDIT>
P.S. You've stated that everything was working fine before the kernel update and I forgot to mention that you should try and recompile tor (modify the SlackBuild) and add --disable-threads in the configuration section. It might help in conjunction with the recent hardening of tor & the kernel patching.
I disabled the threads because I ran tor occasionally on a slow system with limited amount of RAM.

Last edited by abga; 02-28-2018 at 09:13 PM. Reason: -added P.S.
 
1 members found this post helpful.
Old 02-28-2018, 11:26 PM   #11
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
I was able to reproduce the exact problem in a VirtualBox VM.

This is what I did:

1. Created a new VM, picked UEFI (not sure this is relevant, but my real hardware install is UEFI).

2. Did a full Slackware64-14.2 install

3. Ran slackpkg update; slackpkg install-new; slackpkg upgrade-all, copied new kernel to EFI partition, rebooted

4. Booted into a fully patched system running kernel 4.4.118

5. Installed sbopkg, installed tor using it

6. Added user 'user' for regular work, user 'anon' that is supposed to run anonymized programs. Nothing fancy, just ran adduser, added them to all default groups.

7. Added the following rules to /etc/rc.d/rc.firewall

Code:
#!/bin/sh

IPTABLES=/usr/sbin/iptables
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anon -m tcp -j REDIRECT --to-ports 9040
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anon -m udp --dport 53 -j REDIRECT --to-ports 53
$IPTABLES -t filter -A OUTPUT -p tcp -m owner --uid-owner anon -m tcp --dport 9040 -j ACCEPT
$IPTABLES -t filter -A OUTPUT -p udp -m owner --uid-owner anon -m udp --dport 53 -j ACCEPT
$IPTABLES -t filter -A OUTPUT -m owner --uid-owner anon -j DROP
8. Added the following at the end of /etc/tor/torrc:

Code:
AutomapHostsOnResolve 1
DNSPort 53
TransPort 9040
9. Modified /etc/resolv.conv to contain

Code:
nameserver 127.0.0.1
10. Rebooted, it picked up my firewall rules

11. Manually started tor with '/etc/rc.d/rc.tor start' just because I didn't bother to include it into another boot script, I'll need to restart it many times anyway by hand

12. Tor starts and works. 'dig google.com' shows that name gets resolved via 127.0.0.1 that is served by tor. '/etc/rc.d/tor restart' works

13. Ran firefox as regular user 'user', set socks 5 proxy to point to localhost:9050 served by tor, Browser uses the socks proxy and an IP checking site shows another IP than mine. Tor is functional, '/etc/rc.d/tor restart' works

14. Log as anon user, run pidgin (without any proxy settings, since it's supposed to be torified transparently). Pidgin freezes. Tor shows up in D state in output of ps aux. '/etc/rc.d/tor restart' fails

Quote:
Originally Posted by abga View Post
you should try and recompile tor (modify the SlackBuild) and add --disable-threads in the configuration section. It might help in conjunction with the recent hardening of tor & the kernel patching.
This is the next thing I'm going to do and I will report back here.
 
Old 02-28-2018, 11:40 PM   #12
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
I recompiled tor with --disable-threads option, reinstalled the slackware package and did a full reboot. It didn't help. The symptoms are exactly the same: tor works fine as DNS service / SOCKS proxy but freezes as soon as I try to transparently anonymize a program through it.
 
Old 03-01-2018, 05:52 AM   #13
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
- sorry to hear it didn't work compiled with --disable-threads

- if that is your whole&only firewall, then, as a general rule, add some rules flushing before you run your tor related rules:
Code:
#flush all rules
/usr/sbin/iptables -F
/usr/sbin/iptables -t nat -F
/usr/sbin/iptables -t mangle -F
/usr/sbin/iptables --delete-chain
/usr/sbin/iptables --table nat --delete-chain
- the new kernel you updated also contains the modules iptables needs to run and before moving to an older "unhardened" tor version (as suggested in one of my posts above), I'd try to rule out that tor isn't entering a loop because of some iptables related issue - more specifically, the -m owner parameter and its related xt_owner module might not work well.
Can you please try to route all internet traffic through tor and see if this setup works well:
https://trac.torproject.org/projects...tionThroughTor
- this setup contains a specific rule to not route tor traffic through itself:
Code:
# Don't nat the Tor process, the loopback, or the local network
iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
iptables -t nat -A OUTPUT -o lo -j RETURN
 
1 members found this post helpful.
Old 03-01-2018, 08:50 PM   #14
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 666

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
- if that is your whole&only firewall
It is, in the test VM.

Quote:
Originally Posted by abga View Post
as a general rule, add some rules flushing before you run your tor related rules:
Code:
#flush all rules
/usr/sbin/iptables -F
/usr/sbin/iptables -t nat -F
/usr/sbin/iptables -t mangle -F
/usr/sbin/iptables --delete-chain
/usr/sbin/iptables --table nat --delete-chain
As far as I know, vanilla Slackware comes without a firewall script and no software after a full Slackware install tries to set up its custom rules. Are these things needed in this particular situation? I am asking this for eventually learning something I didn't know rather than just for the sake of arguing. Regardless of it, I went and added these rules at the top of the firewall script. After a full VM reboot, the tor problem persists.

Quote:
Originally Posted by abga View Post
- the new kernel you updated also contains the modules iptables needs to run and before moving to an older "unhardened" tor version (as suggested in one of my posts above), I'd try to rule out that tor isn't entering a loop because of some iptables related issue - more specifically, the -m owner parameter and its related xt_owner module might not work well.
Can you please try to route all internet traffic through tor and see if this setup works well:
https://trac.torproject.org/projects...tionThroughTor
- this setup contains a specific rule to not route tor traffic through itself:
Code:
# Don't nat the Tor process, the loopback, or the local network
iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
iptables -t nat -A OUTPUT -o lo -j RETURN
As I can see, there's quite a big example firewall script. I'm afraid my firewall knowledge is not even enough to make me able to estimate how much time would I need to study it before trying to apply on my test VM. But I will be reading on this setup for sure, because I am really interested to get back tor to a fully functional state. If anybody manages to try this scenario before me, just please post some feedback here.
 
Old 03-01-2018, 09:04 PM   #15
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
I got some time (a little more than planned) to replicate your scenario, detailed in post #11, and ended up with the same results.
Since you stated that everything worked fine before the 4.4.118 kernel, I fear that something related to the MeltDown&Spectre patches is conflicting with tor.
The netfilter modules look OK at the first glance, I did some additional testing on them, since I also rely heavily on iptables and feared that I might get myself in trouble if these modules are somehow broken. I'm still not ruling out that they might also be/cause an issue.

My recommendation is to make sure that the new kernel is what breaks tor, this will require a kernel downgrade and I don't really know where (or if) the previous version of the Slackware kernel is available.
Report a bug at tor and point them to this thread. You can mention it anonymously on their blog page (not really the best way) or create a ticket:
https://trac.torproject.org/projects/tor/newticket

- extra: I'll "polish" my post #6 - keep it only factual about their crypto choice, just to not influence your chance of getting helped (I lost my interest in tor, nothing to gain/loose)


Technical details of the investigation:

- after failing with Tor 0.3.2.9 (git-9e8b762fcecfece6) I looked after an older version. According to:
https://blog.torproject.org/category...stable-release
- it looks like they were all patched&hardened recently and I cannot get an older pre-patching version to test with.
- I took the following from the tor repo:
https://dist.torproject.org/
https://dist.torproject.org/tor-0.2.9.14.tar.gz
- output of /var/log/tor/tor.log for the older version I tested with:
Code:
Tor 0.2.9.14 (git-3f9bd01bf5736ff6) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2n and Zlib 1.2.8.
- anon user definition:
Code:
id anon
uid=1002(anon) gid=100(users) groups=100(users)

finger anon
Login: anon                             Name: (null)
Directory: /home/anon                   Shell: /bin/bash
Never logged in.
No mail.
No Plan.
-ps ax - anon & tor related:
Code:
anon     14215  0.0  0.0  20624  3560 pts/2    S    21:41   0:00      \_ -su
anon     14260  0.0  0.1  36492  8880 pts/2    S+   21:46   0:00          \_ lynx www.google.com
tor      14205  0.4  0.4  68356 32796 ?        D    21:40   0:01 /usr/bin/tor
- /etc/tor/torrc additions:
Code:
AutomapHostsOnResolve 1
DNSPort 53
TransPort 9040
VirtualAddrNetwork 10.192.0.0/10
- nslookup www.google.com as user anon (tor process has apparently no issues with DNS requests):
Code:
iptables -vnL
Chain INPUT (policy DROP 1 packets, 32 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    2   136 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
   33 10551 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp dpt:9040
    1    60 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002
    1    76 ACCEPT     all  --  *      lo      0.0.0.0/0            127.0.0.1           
   29 10391 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 1 packets, 32 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.192.0.0/10        tcp flags:0x17/0x02 redir ports 9040
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
    1    60 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.0/8         
    0     0 RETURN     all  --  *      *       0.0.0.0/0            10.0.0.0/8          
    0     0 RETURN     all  --  *      *       0.0.0.0/0            172.16.0.0/12       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/8           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            100.64.0.0/10       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            169.254.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.0.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.2.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.88.99.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.18.0.0/15       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.51.100.0/24     
    0     0 RETURN     all  --  *      *       0.0.0.0/0            203.0.113.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            224.0.0.0/3         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp redir ports 9040
    0     0 REDIRECT   udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53 redir ports 53

Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
 pkts bytes target     prot opt in     out     source               destination
- after running lynx www.google.com as the anon user (subsequent tor freeze - entering D state):
Code:
iptables -vnL
Chain INPUT (policy DROP 5 packets, 160 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  133 12074 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 1044  880K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 2 packets, 80 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    9  1928 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp dpt:9040
    7   420 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002
  113  8778 ACCEPT     all  --  *      lo      0.0.0.0/0            127.0.0.1           
 1063  134K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW,RELATED,ESTABLISHED

iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 5 packets, 160 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 115 packets, 6623 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.192.0.0/10        tcp flags:0x17/0x02 redir ports 9040
    3   144 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 220
   60  3983 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.0/8         
    0     0 RETURN     all  --  *      *       0.0.0.0/0            10.0.0.0/8          
   18   864 RETURN     all  --  *      *       0.0.0.0/0            172.16.0.0/12       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/8           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            100.64.0.0/10       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            169.254.0.0/16      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.0.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.0.2.0/24        
    0     0 RETURN     all  --  *      *       0.0.0.0/0            192.88.99.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.18.0.0/15       
    0     0 RETURN     all  --  *      *       0.0.0.0/0            198.51.100.0/24     
    0     0 RETURN     all  --  *      *       0.0.0.0/0            203.0.113.0/24      
    0     0 RETURN     all  --  *      *       0.0.0.0/0            224.0.0.0/3         
    1    48 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 tcp redir ports 9040
    0     0 REDIRECT   udp  --  *      *       0.0.0.0/0            0.0.0.0/0            owner UID match 1002 udp dpt:53 redir ports 53

Chain POSTROUTING (policy ACCEPT 116 packets, 6671 bytes)
 pkts bytes target     prot opt in     out     source               destination
- strace output for the tor process. The last lines after the execution, nothing else happened after the DNS and the lynx www.google.com anon user requests:
Code:
brk(0x558171620000)                     = 0x558171620000
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
read(3, "MemTotal:        8060140 kB\nMemF"..., 1023) = 1023
read(3, "     3006464 kB\nDirectMap1G:    "..., 1023) = 44
read(3, "", 1023)                       = 0
close(3)                                = 0
pipe([3, 4])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fcfd41029d0) = 2327
close(4)                                = 0
read(3, 0x7ffdf0aa52c7, 1)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2327, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
read(3, ".", 1)                         = 1
read(3, "", 1)                          = 0
exit_group(0)                           = ?
+++ exited with 0 +++
- the firewall I used - I took some rules that I considered useful from https://trac.torproject.org/projects...tionThroughTor

Code:
#!/bin/sh

# some var definitions first
_tor_uid=`id -u tor`
# Tor's VirtualAddrNetworkIPv4 - needs definition in torrc - add VirtualAddrNetwork 10.192.0.0/10
_virt_addr="10.192.0.0/10"
# LAN destinations that shouldn't be routed through Tor
_non_tor="127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16"
# Other IANA reserved blocks (These are not processed by tor and dropped by default)
_resv_iana="0.0.0.0/8 100.64.0.0/10 169.254.0.0/16 192.0.0.0/24 192.0.2.0/24 192.88.99.0/24 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 224.0.0.0/3"
#flush all rules
/usr/sbin/iptables -F
/usr/sbin/iptables -t nat -F
/usr/sbin/iptables -t mangle -F
/usr/sbin/iptables --delete-chain
/usr/sbin/iptables --table nat --delete-chain
#ipv4 default policies
/usr/sbin/iptables -P INPUT DROP
/usr/sbin/iptables -P FORWARD DROP
/usr/sbin/iptables -P OUTPUT DROP
### *nat OUTPUT (For local redirection)
# nat .onion addresses
iptables -t nat -A OUTPUT -d $_virt_addr -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 9040
# Don't nat the Tor process, the loopback, or the local network
/usr/sbin/iptables -t nat -A OUTPUT -m owner --uid-owner $_tor_uid -j RETURN
/usr/sbin/iptables -t nat -A OUTPUT -o lo -j RETURN
# Allow lan access for hosts in $_non_tor
for _lan in $_non_tor; do
  iptables -t nat -A OUTPUT -d $_lan -j RETURN
done
for _iana in $_resv_iana; do
  iptables -t nat -A OUTPUT -d $_iana -j RETURN
done
# redirect user anon traffic through tor
/usr/sbin/iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner anon -m tcp -j REDIRECT --to-ports 9040
/usr/sbin/iptables -t nat -A OUTPUT -p udp -m owner --uid-owner anon -m udp --dport 53 -j REDIRECT --to-ports 53
/usr/sbin/iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner anon -m tcp --dport 9040 -j ACCEPT
/usr/sbin/iptables -t filter -A OUTPUT -p udp -m owner --uid-owner anon -m udp --dport 53 -j ACCEPT
/usr/sbin/iptables -t filter -A OUTPUT -m owner --uid-owner anon -j DROP
# allow normal traffic
/usr/sbin/iptables -A INPUT -i lo -j ACCEPT
/usr/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A OUTPUT -d 127.0.0.1/32 -o lo -j ACCEPT
/usr/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Getting "SIOCADDRT: No such process" when running "service network restart" cmlorentz Linux - Networking 1 11-26-2010 01:06 PM
"bad_pool_error" & "Your system is not fully acpi compliant get your Bios updated" errors in WinXP Aquarius_Girl General 10 07-30-2010 11:27 AM
How do I disable "shutdown" and "restart" options in KDE logout screen for all users? maxgsp Linux - Distributions 1 12-12-2008 03:18 PM
Lost "Shutdown" and "Restart" From system menu in FC6 Nader1 Linux - Software 3 02-12-2007 04:40 PM
"Shutdown" and "Restart" option missing after upgrade hansalfredche Mandriva 8 11-02-2006 07:23 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration