I’m trying to harden my host to not leak anything to clearnet.
I have an idea to get EntryNodes IP addresses from TorProject site, add them to iptables as allowed, and prohibit other traffic.
Question:
Do TOR or WG connect to other IPs except entrynodes during normal operation?
Any directory services or anything else?
Can I spoil something with this configuration?
I am very confused by various information 
My manual solution is more transparent to me.
Will WG TOR work correctly if I only allow entrynodes traffic on the host?
Sorry for the weird URLs above, but the forum doesn’t allow me to post links.
There is no easy solution for your question. I am providing pointers if you like to research this more.
corridor is “90%” done for non-Qubes, i.e. Debian based hosts. Implementing the remaining 10% may be doable but difficult.
https://github.com/rustybird/corridor as per original upstream can be used on a physically isolated, physically separate gateway computer in front of any other computer (using Whonix). In that case you can ignore the fork of corridor by Whonix at whonix .org/wiki/Corridor.
software fork: https://en.wikipedia.org/wiki/Fork_(software_development)
Whonix host firewall is in development but initial version might not have this feature. Not clear if it ever will have this feature.
Your initial questions are Tor specific questions. Not Whonix specific questions. https://www.whonix.org/wiki/Free_Support_Principle explains that it’s better to ask such questions elsewhere. For what you plan on doing it doesn’t matter if you are using Whonix or Tor Browser. Therefore these questions can be directed at the general Tor community.
What you’re asking for isn’t done in an easy, out of the box way. Only options are to exert great effort or wait and check later.
Helia,
You can try this on your host, assuming you have a “NAT” connection.
Iptables rules can accomodate your needs nicely. Instead of whitelisting all entry nodes (which would be a quite large and convoluted list), see what your current Entry/Guard node is. You can see this by using Nyx in the Gateway. Once you know this, on your host, set rules like this (with sudo privileges):
First, default drop policy
These will make it so everything NOT listed as a rule will be discarded/dropped. You will cut off all incoming and outgoing traffic except for what is explicitly defined with an iptables rule.
And for incoming,
Right under that,
You do not need any dns rules for Tor on your host. You do need localhost though for both incoming and outgoing:
and
This enables your host to talk only to Tor. The entry/guard is the only IP that can communicate in either direction, and localhost of course. Put those rules into a small script, give it chmod +x privs and run it before you start Whonix. Keep in mind, entry guards change periodically, so every now and again, check Nyx to see what the current one is and adjust the iptables rules. Those wll get you started. I encourage you to take a closer look at the Whonix Firewall code for both the Gateway and Workstation on Github. There are some useful, all purpose rules that you can optionally add to your configuration.
That’s exactly what I wanted to do 
But on the TOR forum I received information that there may be additional connections to directory caches and directory authorities.
What do you think about it?
Sure, there are those connections, but remember that these happen over your Tor connection. Directory authorities are a listing of all trusted relays and nodes. (the “consensus”) This is Tor’s way of verifying trust for the nodes on its network that gets updated real time every hour or so. The actual verification protocol is part of your Tor client code; you do not have to do anything on your end.
You can use the rules above and not have any problems accessing Tor’s network. Add to them according to your network but those should get you started
I thought the connections to directory authorities were before connecting to the input nodes. Now I understand that they are part of the code after establishing connection with Entry Guards, for example.
So I can add IP addresses from the TOR status file (/var/lib/tor/state) to iptables permissions, because they will not change for about 30 days?
Well, here is what I would do in order to make sure you add the correct address: If you are using a Bridge, then add it’s address right away. If using an Entry/Guard node, then either the state file would work, or simply make a Tor connection for a day or two, and observe the address of your Guard/Entry node. Use Nyx (in the Gateway list of programs) to do this. Click on Nyx, once it opens, press the right arrow key once (–>) That screen shows you your circuits. Number 1 “Guard” is your Guard/Entry address.
The reason I suggest Nyx in addition to the state file is because sometimes the state file lists the connection by “nickname” and not the actual IP. At least in Nyx you can easily find it.
I have already discovered Nyx and it is a very nice program
You’re right, the state file contains a list of Guards by nickname, and I’d have to use metrics.torproject.org/rs.html to find out each Guard’s IP from my state file.
I noticed a small problem with me: Quite often, Nyx shows me a change of Guard. Every few or several hours. They are always in the state file, but they change.
That’s why I thought about adding everyone to iptables, but first look up their IP addresses https://metrics.torproject.org/rs.html
When using Tor with Entry Guards (as opposed to a bridge), Tor will pick a couple different Entrys for the client; that’s what you see in the state file. Sometimes, if you use the netstat command, you may see that there are 3 or more connections open, but you are connected to only one Guard. That’s normal. Tor keeps the connections open in case something happens like a network interruption.
The reasons that a Guard can change during a session are varied. Sometimes it’s because there are modifications in the torrc file. Modifying options like Exit Nodes, Number of Entry Guards and others can cause these changes to take place. Sometimes it’s something on the server side also. Bottom line is that if you leave your Tor client to do its magic on its own without modifying any parameters related to routing and network pathways, then what you see is normal behavior. Tor works best when left to sort out its paths through the network on its own.
So if you would like to, you can add your separate Guards to your iptables rules and still the ruleset would be secure because only Tor connections would be allowed. The Guards do not lead anywhere else except to a middle node in Tor’s network.
Also, Whonix introduced Onion Vanguards recently that offers several types of protection methods both for hidden services and for Tor clients accessing hidden services. Very interesting material. All of these different algorithms and protocols work together to keep Tor relatively secure.
Thank you for your help!
I have a iptables ruleset too, but this one filters traffic by user. Best when tor is running as a system account. Regular user accounts have too many processes.
Example works for Debian. If you use sdwdate then you should allow by group and not user. uid-owner is user, gid-owner is group. Pick one, not both.
Examples that filter outgoing traffic are rare, so I doubt if OUTPUT needs RELATED ctstate or not. Does anyone have the answer to that?
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp -m owner --uid-owner debian-tor -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp -m owner --gid-owner debian-tor -j ACCEPT