In a Documentation I found for the SocksPolicy other options for the policy that allows SOCKS connections to SOCKSPort localhost, internal/private IP addresses and prohibits all others. →
Now is that a mistake or is there just a different spelling?
For me these are differences
In the ExitPolicy it is written correctly with “* : *”
Could someone clarify?
regards
Edit: i had to make spaces before and after the colon because of formatting
The second directive of your torrc sets the socks port to 9060. I imagine that any other port at this point is rejected by default, therefore reject * means reject any IP, besides the ones allowed, on the port 9060, as any other port is automatically rejected. At least, this is how I would assume it works.
So laziness from the developer to put two more characters?
Because normally you ban everything first and then set the permissions, that’s what I learned here at ipfire.
And if every port except the specified one would be blocked, then all IPs except the specified one would have to be blocked as well.
you might want to consider being more charitable with your assumptions about other people actions. I will follow my own advice and assume that you had no intention of offending the developers of IPFire and you had just a poor choice of words (which could happen to anyone).
Lets clarify that I know nothing about the argument. As I was curious, I just read the torrc manual page, quickly. I read part of the manual pages, found no clear answer about the syntax of just using * and based on my limited experience of configuring network servers I made few assumptions. Reading the source code would be the way to know how this works, which is beyond my ability.
This is my assumption, if you set the socks server to port 9060, you need to ban only the IP address, as even if the IP alone will not be enough for a complete ban, any other port will not find a process listening. This is what I meant with my previous post, but I recognize I was not clear. Why tor developers find the necessity to introduce a syntax, where you can use a glob pattern expansions also for the ports and not just the IP, which alone should be sufficient? Maybe because there is also the control port? But then, why not banning just the IP and ignore the ports? I do not know, and I confess I am a bit baffled by this.
I did not want to offend anyone, please, we are all lazy and if it is possible to write like this, that’s great. Only I wonder if this is really correct. The access to the proxy from the outside is also not possible, is nicely blocked as a drop in in the log, but probably by the Firerwall, who knows if it is not somehow possible, if that was not written out correctly. Therefore the question here. According to the instructions I linked the spellings are different, in the Accept policiy there is also a * and that means all internal IPs but is then also prefaced with a colon. This is strange for me. And machines are stupid, why should options be accepted in different spellings.
And why should the general firewall configuration, I forbid everything and enable only what I need change here?
And please don’t take my words as an insult, what would I have to gain by poking at any developers? That is absolutely not my intention. I only ask, could also be wrong. I can’t test it, at least I don’t know how.
How I get the manual page from torrc, which command is needed, I only know man pages from programs not config files? Or have you a link for me, I also like to read up on it myself, np?
I also read that you can run multiple Tor instances, for example using one instance as a proxy and the other as a relay to separate them even at the process level.
These policies syntax’s are also valid for the exit node and there everything can or should be forbidden and only the ports you want to serve should be enabled. If you only want to operate a relay, just leave it at ExitPolicy reject * : * and set no permissions.
It is also strange that a DirPort 9030 for the relay is not opened, or is not recognized by the authorities and written to the directories, is it because of the ipv4only syntax behind it?
I have also addressed the circumstance months ago, this has not changed yet and there were certainly already two updates of the tor package since then.
If I have time, I look for information and if I notice something, I ask about it, no one else does apparently.
Or is this wrong?
I know nothing about tor. I don’t use it and have never used it so all I have to contribute is some info from some searching I did.
https://github.com/torproject/tor/blob/main/src/config/torrc.sample.in
The above link shows the torrc.sample file which gives indications on the various entries that can be used. On line 28 there is SOCKSPolicy Reject * so a * on its own is allowable and even given as an example.
Looking up SOCKSPolicy it says that the allowed policies are the same as for EXITPolicy and that section has the following info
ExitPolicypolicy,policy,…
Set an exit policy for this server. Each policy is of the form “accept[6]|reject[6]ADDR[/MASK][:PORT]”. If /MASK is omitted then this policy just applies to the host given. Instead of giving a host or network you can also use “*” to denote the universe (0.0.0.0/0 and ::/128), or 4 to denote all IPv4 addresses, and 6 to denote all IPv6 addresses. PORT can be a single port number, an interval of ports “FROM_PORT-TO_PORT”, or "". If PORT is omitted, that means "".
This says that ADDR[/MASK][:PORT] can be used but * can be used on its own to denote the universe of ip addresses and ports.
The entries in torrc come from the output of tor.cgi, the WUI page for tor. Bear in mind that if you change any entries directly in the torrc file then accessing the tor.cgi page will likely overwrite them, also the same could happen with a CU.
The cgi code looks for the available subnets and then adds the accept policy for the appropriate subnet.
The tor updates are relate to the tor package that is used within IPFire. However those updates will not change the entries in torrc as those come from the tor.cgi WUI page.
If you think the WUI page needs to be updated or improved then you are welcome to submit a patch for a change sent to the development mailing list as per the wiki page.
Please bear in mind that there are only around 6 or 7 regular core developers, all doing this work voluntarily in their spare time but they all have day jobs. The tor addon is an addon and not part of the core packages where their priority will mostly be focussed, together with working on the development of IPFire3.x.
If someone wants to step up and pick up the maintenance and development of the tor addon, I am sure the developers would be pleased to welcome them to the group.
Excellent this is the proof that laziness of zhe developer wins so both spellings are correct. Thank you very much for your research, seems to be I am to stupid to use startpage.com because I found all but not what I was searching for, or you know better where to search.
Yes I know this i have saved a extra file in directory, because I also added some other policy rules like mapaddress which the GUI is not provided. And I avoid to press the save button on tor page and stop/start tor over the services.cgi, then the torrc file will be not override at all.
Mister, I can a much of things from push a hammer on a nail, sailing a little boat over to set all settings on firefox that your privacy is safe, but please do not expect that I also learn to code! I know this is massive brainstorming work and I would not say what people have to do, but I guess also that the option is correct written in the torrc file and the mistake is a missing iptables rule. Because the option is correct, but Port is not open for the authorities. I see a related chain in iptables.cgi page, so not only the torrc file will write from the tor.cgi page. Anywhere is a little mistake .
I have been following this project for over a decade, in the old German/English forum for example I tried to find support on how to set up Ipfire as a VPN client of a VPN provider and I was almost banned from the village with torches and hooks. But since I had an irrepressible will at that time, I spent days on it and fought my way through it with try and error.
At the end I had a client that sends 100% everything through the VPN tunnel without DNS leak, killswitch and self-written scripts that detect an interruption and the connection is reestablished correctly. Sometimes it happened that a second tun device was opened and because of the configuration then no connection was possible, I wrote another script which recognized this and deleted the tun devices and restarted the connection. Also I realized that on different weekdays with different locations was connected. To achieve the highest level of privacy. I wrote a kilometer long how-to in the forum which was not respected and was simply deleted with the end of the forum. This configuration ran for years without errors on a HP server in my basement, until I had to migrate and moved the ipfire to a small but fine self-built server with a new installation.
That is not bad at all, should only be an example of how this works here, if you point out something and there is no one who cares, you have to do it yourself and then it happens that you no longer get support because you have made it yourself. Is all very sad unfortunately but hope dies in the end.
So I know the whole situation of ipfrie for a while and I don’t need anyone to tell me about patience or understanding. When I point out that something doesn’t work over updates is rather meant that it is not a version dependent problem and the error exists for a longer time.
And sorry but about ipfire 3.0 is already talked about since I know ipfire, how much functionality do you want to offer with 3.0, if now not even all packages can be maintained properly (<–no reproach, this is just very sad and hurts my heart).
I find the project ipfire simply ingenious, but unfortunately it does not seem to have the reach to attract enough volunteer developers who spend a few hours of their time here and fix the minor bugs and/or bring in suggestions of their own ideas. I am for example Highly pleased about the Dark theme, there seems to have found someone who likes this project too and rushes into work to make the look of the web interface eye-friendly, I am thrilled by and will be helpful with my ability to find inconsistencies there.
Unfortunately, that’s all I can contribute to calling mistakes and inconsistencies by their names.
The fix in the code must unfortunately take someone else, I am not qualified. Sorry.
so both spellings are correct. Thank you very much for your research, seems to be I am to stupid to use