A anon asked about Whonix security on other thread and I suggested OpenBSD instead. I thought this might be useful for other people, so here's how to make it route all trafic through Tor:
- Install Tor:
block all
non_tor = "{ 192.168.1.0/24 192.168.0.0/24 }"
match all scrub (no-df random-id reassemble tcp)
antispoof for egress inet
block return log on egress all
pass in quick on lo1 inet proto tcp all flags S/SA modulate state divert-to 127.0.0.1 port 9040
pass in quick on lo1 inet proto udp to port domain divert-to 127.0.0.1 port domain
pass quick on { lo0 lo1 }
block return in on ! lo0 proto tcp to port 6000:6010
pass out quick inet proto tcp user _tor flags S/SA modulate state
pass out quick inet proto udp to port domain route-to lo1
pass out quick inet to $non_tor
pass out inet proto tcp all route-to lo1
- Done. The next reboot it should already be working. If you use public wifi, don't forget to write "lladdr random" on your interface config to spoof mac address (read the hostname.if(5) man page). Don't forget disk encryption (read the FAQ about softraid-crypto). Also, you can raise securelevel and make the transparent proxy "permanent":
>>4675 KIST is not supported on systems other than Linux. From man page:
>KIST will only work on Linux kernel version 2.6.39 or higher.
And KISTLite has nearly the same benefits, but works on OpenBSD:
>KISTLite will work on all kernels and operating systems, and the majority of the benefits of KIST are still realized with KISTLite.
It's going to be a dusy getting this up on my laptop. I don't think its even compatible.I burned the iso file to a dvd and booted from disk,but I'm missing directory <cd0> and some other one :/. Basically not working. I'll try some other time, and since I can only do a single partition just makes things more crazy, wiping OS everytime I try to download OPENBSD. Are there specific laptops for openbsd?
I can get into the installation with the cli, but there some obstacles with missing directory.
>>4682 >I'm missing directory <cd0>
What do you mean? It boots the DVD at least? You should see in the screen options like: (S)hell , (A)utomatic, (M)anual and so on. Just follow this FAQ:
https://www.openbsd.org/faq/faq4.html
>>4675 >A anon asked about Whonix security on other thread and I suggested OpenBSD instead. I thought this might be useful for other people, so here's how to make it route all trafic through Tor:
I think the point of Whonix is that you isolate the Tor apps in a vm or container, you don't need to dedicate your entire system to Tor.
Since OpenBSD doesn't have containers or VMs or any concept of horizontal security it doesn't seem like a good replacement.
Also does OpenBSD have Tor Browser? Because stomping around the web with vanilla Firefox is not the same thing. Even if your IP is hidden they can correlate your activities with your unique browser config and the moment you drop the transparent proxying and use your real IP address now there's a link between your Tor and non-Tor identities.
>>4727 >OpenBSD doesn't have containers
It doesn't need to, almost everything now uses pledge(2) and unveil(2).
>or VMs
If you want VMs, you can run it with vmd(8), even though it wouldn't add more security, since virtual machines on x86 run using microcode:
https://www.openbsd.org/faq/faq16.html
>Also does OpenBSD have Tor Browser?
It does:
# pkg_add tor-browser
>vanilla Firefox is not the same thing.
Pretty much is. TBB has very few patchs over firefox, with all the complexity/bugs/vulnerabilities in it included.
>unique browser config
True, but Links offers a spoofed http header that is the same of firefox.
>the moment you drop the transparent proxying
Same for any other system.
>>4730 >It doesn't need to, almost everything now uses pledge(2) and unveil(2).
The difference is I as a user choose what goes into a container and what the restrictions are.
With pledge and unvail I need to depend on the software author to sandbox their shit correctly.
Sorry I know OpenBSD fans bet butthurt when they hear this but it's not comparable.
>even though it wouldn't add more security, since virtual machines on x86 run using microcode:
What? Your link doesn't say anything about microcode. I can't even guess what you mean.
>Pretty much is.
No it's not and this is important so listen. If you use the same uniquely identifiable browser with and without Tor then YOU ARE NOT ANONYMOUS. This is exactly the reason they killed Tor Button and created a dedicated Tor Browser instead.
https://blog.duszynski.eu/tor-ip-disclosure-through-http-301-cache-poisoning/
>It does:
That's good. If Tor Browser is available then use it.
>running Tor in VMs
Even if it's for some reason not more secure, it probably does offer some extra protection against leaking a hardware fingerprint of some sort.
>You should really have one machine for clearnet and a different one Tor stuff. Using the same machine for both is probably not a good idea.
>A anon asked about Whonix security on other thread and I suggested OpenBSD instead.
One important purpose of Whonix is to guarantee that your real IP address will not be leaked, even if the root account of the Whonix Workstation is compromised.
You will not have the same guarantee with this setup, even with OpenBSD's securelevel set to 2. The root user can edit sysctl.conf and reboot to a lower securelevel.
Also if you raise securelevel to 2 make sure to disable the in-kernel debugger in sysctl.conf as well.
https://man.openbsd.org/securelevel.7 >Because securelevel can be modified with the in-kernel debugger ddb(4), a convenient means of locking it off (if present) is provided at securelevels 1 and 2. This is accomplished by setting ddb.console and ddb.panic to 0 with the sysctl(8) utility.
>>4735 >what goes into a container and what the restrictions are.
What's the advantage of this over having everything privsep'd?
>Your link doesn't say anything about microcode
It doesn't, the link was about virtualization in openbsd.
About VM security: in x86 there's no separate processor to run virtualizations, as in SPARC. In x86 VMs run using microcode (VT-x and AMD-V) because it reduces hardware costs and uses less energy. This mean you rely on microcode correctness for your security and, as we have seem in these two last years, microcode is full of bugs.
Not even to say about bugs and complexity:
http://taviso.decsystem.org/virtsec.pdf https://marc.info/?l=openbsd-misc&m=119318909016582&w=2 https://marc.info/?l=openbsd-misc&m=119326303217813&w=2
About the article you linked, this uses persistent cache. Links browser doesn't have persistency like "modern" browser (such as Chrome Canary, as the author used in the article). If you want to be such, you can just disable caching on Links. Add this to ~/.links/links.cfg:
>>4739 >hardware fingerprint
And what would be those? As I said, you should spoof the mac address with llrandom. Also, TCP timestamp will be randomized by pf "reassemble tcp" option.
>>4740 >root account of the Whonix Workstation is compromised.
I highly doubt Whonix disabled root completely and single user mode. Couldn't find anything about that.
>reboot to a lower securelevel
You would need to not just compromise root, but also reboot, as you said. If a attacker already has root, then it's game over. You can also use chflags to make it harder to change pf.conf:
# chflags schg /etc/pf.conf
>disable the in-kernel debugger
Good point. Thanks.
>>4743 >I highly doubt Whonix disabled root completely and single user mode.
Ok, so you don't understand what Whonix is at all.
There are two VMs: the workstation and the gateway. Your VM setup ensures that all traffic in the workstation is routed through the gateway. The gateway torifies all traffic it receives.
Therefore, the only way to get the real IP of the user is to compromise the gateway VM or the hypervisor/host OS. That's why your IP won't leak even if the root account of the Whonix WORKSTATION is compromised.
>>4744 I understand how it works, I just don't think it works as you are trying to explain. The Tor client inside the gateway needs to run in some kernel, be it linux or *BSD.
>That's why your IP won't leak even if the root account of the Whonix WORKSTATION is compromised.
I'll ask again: the VM running the gateway has no root? Because if you compromise the gateway (or the workstation) and get root, you can just do whatever you want with the tor client, firewall rules and VM.
If it doesn't have root, please link me to some document where they explain it. I did a fast search and couldn't find anything talking about this.
>>4745 >the VM running the gateway has no root?
I'm not sure, but that isn't relevant to anything I've said so far.
>if you compromise the gateway (or the workstation) and get root, you can just do whatever you want with the tor client, firewall rules and VM
The VM manager on the hypervisor/host OS disallows the workstation from connecting directly to the Internet. It creates a virtual LAN connecting the workstation and gateway and ensures that this is the only network the workstation has access to. The firewall rules on the workstation aren't responsible for preventing connections to clearnet, and nothing the workstation does should allow it to do so.
I tried to find a better source to support my claims but the wiki isn't very clear on this matter. If I am wrong please correct me but this is my general understanding of how Whonix works.
>>4744 >What's the advantage of this over having everything privsep'd?
The differences is containers give the *user* control.
With coding tricks like privsep/pledge/unvail you are still cucked by the developers.
>In x86 VMs run using microcode (VT-x and AMD-V) because it reduces hardware costs and uses less energy.
Erm no actually virtualization extensions are to manage virtualizaed page tables in hardware instead of software. THAT is where all the bugs are and the reason Your Fearless Leader condemned virtualization in the past and why Qubes dropped paravirtualization all together. You linked this same email but you don't seem to understand the contents.
https://marc.info/?l=openbsd-misc&m=119318909016582 https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ Theo greenlit vmm exactly because hardware virtualization is more secure not less.
>And how do you think TBB is diferent?·
Yes because all Tor Browser users look the same on the outside so you can't deanonymize them by linking Tor and non-Tor browsing. Why is this so hard to understand?
>Please go read their patchs. There's nothing special about them:·
Dude you can't even understand an email. Stop larping.
>I highly doubt Whonix disabled root
It doesn't matter. The point is getting root in Whonix doesn't break anonymity. In OpenBSD it does. But getting root on OpenBSD is arguably harder because vertical security is basically all they focus on.
>If a attacker already has root, then it's game over.
Not if you're in a VM. Pay attention.
>>4745 >if you compromise the gateway (or the workstation) and get root, you can just do whatever you want with the tor client, firewall rules and VM.
No because they're isolated. Only if you compromise the machine running the firewall do you break anonymity but by far the highest risk is the browser. That's why you need to isolate it from the firewall.
>>4746 >that isn't relevant to anything I've said so far.
It is, because the gateway is running the Tor client.
>isallows the workstation from connecting directly to the Internet.
The primary OS needs some way to connect with the hardware and pass the packets to the VM.
>his is the only network the workstation has access to.
How is this enforced? By Virtual LAN? This isn't different than diverting the packets using a simple firewall.
>but the wiki isn't very clear on this matter
Exactly. Whonix documentation is trash.
>If I am wrong please correct me
I'm not sure you're wrong, but I don't see how using VM and VLAN is better than good privsep and firewall enforcement. It seems lazy.
>>4747 >you are still cucked by the developers.
What do you even mean? Unless you audit the entire code yourself, you have to trust developers in the first place. Also, this isn't /pol/ stop using their slangs.
>Your Fearless Leader
He is not my leader, I just give him some credit for his work. This guy has been coding secure software since before most of us here were even born.
>You linked this same email but you don't seem to understand the contents.
What part of the email I didn't understand?
>SLAT (EPT)
I don't see how this is different, except that now Intel has control over memory virt.
>"Certified Qubes Hardware"
>Hardware Certification Process: Pay the Qubes team a flat monthly rate.
>"There is currently no specific hardware (e.g., specific laptop model) that the Qubes team recommends for individual users"
Hah.
>Tor Browser users look the same
And I'm telling you TBB is not the only one that can use "camouflage". The most identifiable piece of information from browsers is the http-header. Other browsers can fake the same header TBB uses. As I said (for the third time now), Links has this option.
>Mozilla's code signing cert.
Nice, I honestly didn't know, that's why I asked.
>The point is getting root in Whonix doesn't break anonymity.
Getting root always is game over. If you get root on the gateway, you can just modify the Tor client. If you get root on the workstation, you can just modify the Virtual LAN.
>by far the highest risk is the browser.
I agree.
>>4749 (me)
>>4747 Forgot to comment this part:
>Theo greenlit vmm exactly because hardware virtualization is more secure not less.
Probably not true. I didn't see anyone in the community saying this is a security feature. This was made most probably because it is easier to deploy VMs than buying new hardware to do actual physical isolation. One of the devs of vmm was reyk@ and he runs a network company.
>>4749 >Whonix documentation is trash.
It has a lot of good info, but a better description of the virtual LAN in the "Design and Goals" page is needed.
>Getting root always is game over.
>If you get root on the workstation, you can just modify the Virtual LAN.
This is where I think you're wrong.
http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/KVM#Importing_Whonix_.E2.84.A2_VM_Templates >The supplied XML files serve as a description for libvirt, that tell it what properties a Whonix ™ machine and networking it should have.
>If the definition of the Whonix ™ internal network fails because the virtual bridge "virbr2" already exists, edit the internal_network*.xml file and change the name to one that doesn't exist
https://www.linux-kvm.org/page/Networking#Private_Virtual_Bridge >Private Virtual Bridge
>Use case: You want to set up a private network between 2 or more virtual machines. This network won't be seen from the other virtual machines nor from the real network.
This is what I presume is the "virtual LAN". Again, this definitely should be more explicit in the wiki.
>>4756 I started to read the wiki and there is some nice information, but some bits are very funny:
>Use multiple Tor Browser instances or Whonix-Workstation ***s
I can only imagine their thought process: "you know, this doesn't seem secure, so lets get this 16M loc piece of shit browser and run in multiple VMs, each running another complex code, so we can finally get more secure. Because, you know... you need to compartimentalize".
>>4749 >Unless you audit the entire code yourself, you have to trust developers in the first place.
If I trust the developers of the container then I don't need to trust the developer of the shit I put inside.
With OpenBSD there are no containers, you need to explicitly trust everything you run.
privsep/pledge/unvail only lets the developers secure their own code but that doesn't help if you don't trust them in the first place.
That's the advantage of containers.
>What part of the email I didn't understand?
That Theo was only talking about paravirtualization but you tried to pass it off as evidence that hardware virtualization is insecure because you don't actually know what you're talking about.
>I don't see how this is different, except that now Intel has control over memory virt.
Intel always had control over virtual memory mapping. Before VT-x the MMU didn't know about virtual machines so you can't just pass virtual addresses from the guest straight to the MMU hardware because then the VM can overwrite host memory and break out. So hypervisors had all this extremely complicated MMU emulation code running inside ring0 to make virtual machines "secure". That's what Theo was talking about in his email and it's still the source of severe vulnerabilities in the oldest and most stable hypervisros like Xen. Getting Intel to do this in hardware removes all these bugs and you already trust Intel to do virtual memory mapping for your bare metal operating systems anyway so don't act like this is some big new Mossad backdoor or whatever stupid conspiracy shit you believe.
>And I'm telling you TBB is not the only one that can use "camouflage".
If you're the only person using it then it's not "camouflage". It's weird that you are such an expert on understanding the TBB patches and you think "http-headers" are the only thing that matters.
>If you get root on the workstation, you can just modify the Virtual LAN.
Obviously the workstation is not routable to the internet. The workstation can only access the gateway. That's the whole point. The traffic goes through Tor or it goes no where. Nothing inside the workstation including root has any control over that.
>Nice, I honestly didn't know, that's why I asked.
No you asked like "look at this suspicious thing I'm so clever to find and you pathetic cucks actually trust this insecure not OpenBSD crapware HAHAHAHA". Well that backfired didn't it.
>Hah.
And the fake humility is gone 3 seconds later.
>>4760 >I can only imagine their thought process:
Unfortunately your strawman falls apart if you quote the whole line instead of just the beginning.
>Use multiple Tor Browser instances or Whonix-Workstation ™s TO BETTER COMPARTMENTALIZE CONTEXTUAL IDENTITIES.
>>4769 >I don't need to trust the developer of the shit I put inside.
Pic related.
>you already trust Intel to do virtual memory mapping
I don't, because I don't use Intel. You assumption of security is based on Intel. It's already a fault reasoning.
>don't act like this is some big new Mossad backdoor or whatever stupid conspiracy shit you believe.
I never said anything about conspiracy. You're just projecting.
>you think "http-headers" are the only thing that matters
I never said it was the "only thing", but it is definetly the most important. Care to quote what are the other most important ones?
I've read the patchs. Basically what they do is disable javascript features, protocols and put everything in a 'sandbox'. All problems caused by firefox complexity in the first place. The only patch I saw that as something to look forward is the http-pipelining randomization, as explained here:
https://blog.torproject.org/experimental-defense-website-traffic-fingerprinting >you're the only person using
Doesn't matter. Http header is the same.
>The workstation can only access the gateway.
The gateway runs the internet-stack drivers? It has root? This is what me and the other anon are searching on Whonix wiki but couldn't find yet.
>Well that backfired didn't it.
Hanlon's Razor. But, if you want to think that way, go ahead.
>And the fake humility is gone 3 seconds later.
Why do I need "humility" when I see something so ridiculous like "Certification Process: Pay the Qubes team a flat monthly rate"?
I just think it's funny they are asking money just to put it on Qubes pages.
>if you quote the whole line instead of just the beginning.
It doesn't change what I said. Running a complex software multiple times just to "compartimentalize" is completely idiotic. You can just add some kind of privsep to Tor and the browser and have the same isolation minus the milions of lines of code.
The pic of >>4760 is exactly what it feels like.
>>4771 > The gateway runs the internet-stack drivers?
If by that you mean the VLAN setup, then it's handled by the VM software. Neither the gateway nor the workstation can change that as far as I know.
> It has root?
Yes. Even passwordless root if you choose to enable it on Qubes-Whonix.
> Running a complex software multiple times just to "compartimentalize" is completely idiotic.
If you trust your VM software, it doesn't matter how bloated or vulnerable whatever you have inside is - the only vulnerability is breaking out of the VM. Running everything on the same machine requires trusting more moving parts.
> Doesn't matter. Http header is the same.
Http header isn't the only fingerprinting method, it's a pretty obvious one. The way the browser processes css, frames, html5 bullshit, even the timing, can all be used to track you. Essentially, the only way of being 100% sure you have the same fingerprint as a TBB user is by using TBB yourself.
t. not the anon you're replying to but a long time Whonix user
op I finally got openbsd up and functioning. its good. absolutely bare bones. now i have a better grasp of the lingo and i'll begin configuring tor. thanks again senpai.
>>4857 >it's handled by the VM software
So it basically push drivers/firmware to the userland, just like a microkernel? That is pretty sofisticated, but I'm not sure is is possible are you guys are explaining... not with linux kernel.
>Yes. Even passwordless root
If the VM has root then you can compromise the Tor client. That's my point.
>the only vulnerability is breaking out of the VM
Except if the VM is running on microcode no one knows. That's the case of x86.
>The way the browser processes css, frames, html5 bullshit, even the timing
Only for things that require a 'feedback'. For example, if the page has html5 video and the browser doesn't support, the server can 'see' you didn't download the video. So, in general, that's very minimal fingerprinting and the trade-off between bloated firefox vs simple Links is still very good. For a attacker exploit those minimal fingerprints he would require quite a lot of effort. Probably on intel agencies can do that, because they can subpoena ISPs.
>t. not the anon you're replying to but a long time Whonix user
Thanks. Nice to see other people contributing to discussion. Nanochan quite slow.
>>4859 > So it basically push drivers/firmware to the userland
No, supported VM software is already capable of emulating VLANs, you just need to set it up (or have it automatically set up, on Qubes at least)
> If the VM has root then you can compromise the Tor client.
Indeed, altough the attacker would need a tor zeroday, since you're not supposed to run anything else other than tor on the gateway, or even touch it at all. If it is compromised, they're still contained in the VM, altough with full internet access if you don't have another traffic whitelisting VM between the gateway and your Internet capable VM/host.
>Probably on intel agencies can do that
Ad/tracking companies do a lot of malicious shit. I wouldn't put such things past them.
>>4888 >Ad/tracking companies do a lot of malicious shit.
Glowers just need to tap those companies and they can save all the same information, the companies do all the work.
Other companies already 'made' laptops with these requirements (such as Vikings, from Libreboot folks) and the Qubes team didn't put on their list of "approved". Most probably because they didn't paid the fee required. Pathetic.
Just buy a old x60/x220 and you can do everything this "Insurgo" does.
I'm not saying it is bad, though. My problem with this is that they didn't even said anything about other companies already doing the same thing.
For people that want something that just works, such as journalists, this is "Insurgo" seems great.
Also:
>Heads provisioned pre-delivery to protect against malicious interdiction.
Heads will not protect against interdiction. Someone can just flash a new ROM with a SPI flash and no one would know. They should send the SHA-512 hash in their website order, so people can dump the firmware with flashrom and compute the hash themselves.
## Configuration file for a typical Tor user
## Last updated 22 December 2017 for Tor 0.3.2.8-rc.
## (may or may not work for much older or much newer versions of Tor.)
##
## Lines that begin with "## " try to explain what's going on. Lines
## that begin with just "#" are disabled commands: you can enable them
## by removing the "#" symbol.
##
## See 'man tor', or https://www.torproject.org/docs/tor-manual.html, ## for more options you can use in this file.
##
## Tor will look for this file in various places based on your platform:
## https://www.torproject.org/docs/faq#torrc
## Logs go to stdout at level "notice" unless redirected by something
## else, like one of the below lines. You can have as many Log lines as
## you want.
##
## We advise using "notice" in most cases, since anything more verbose
## may provide sensitive information to an attacker who obtains the logs.
##
Log notice syslog
## Uncomment this to start the process in the background... or use
## --runasdaemon 1 on the command line. This is ignored on Windows;
## see the FAQ entry if you want Tor to run as an NT service.
RunAsDaemon 1
## The directory for keeping all the keys/etc. By default, we store
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
DataDirectory /var/tor
## Drop privileges for moar security xDDDD
User _tor
Sandbox 1
>>5002 >Sandbox 1
This doesn't work on OpenBSD. Remove and restart Tor.
>AllowNonRFC953Hostnames 0
Remove that. Default is already zero.
>HTTPTunnelPort
Why? Tor works with SOCKS5 and, if you can't proxy through SOCKS5 because some software doesn't support it, the firewall (transparent proxy) will just redirect the request. Use torsocks for that and remove the HTTPTunnelPort.
>SafeSocks 1
Sometimes this config is bugged. If you do everything I said above and it still doesn't work, try to disable SafeSocks.
Another thing: your clock needs to be precise.
Here is what I do:
- Disable the pf.conf temporarily
- Change the clock to UTC:
$ doas ln -fs /usr/share/zoneinfo/UTC /etc/localtime
- Write this to your /etc/ntpd.conf
listen on 127.0.0.1
servers pool.ntp.org
sensor *
- Then run this:
$ doas ntpd -sd
- Wait some seconds and quit (Ctrl + C).
This will syncronize the clock.
If your machine supports it, you can also use HPET (reboot the machine after this change and repeat the ntpd process):
>>5004 None of this has any effect. My clock was inaccurate by 1 hour due to me changing the motherboard battery a few days ago, but now it's accurate and that doesn't help.
I think the pf configuration may be the problem.
# destinations you don't want routed through Tor
non_tor = "{ 0.0.0.0/8 10.0.0.0/8 100.64.0.0/10 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 192.168.0.0/16 192.88.99.0/24 198.18.0.0/15 198.51.100.0/24 203.0.113.0/24 224.0.0.0/4 240.0.0.0/4 255.255.255.255/32 }"
# Tor's TransPort
trans_port = "9040"
match in all scrub (no-df random-id reassemble tcp)
antispoof for egress inet
block return log on egress all
pass in quick on lo1 inet proto tcp all flags S/SA modulate state divert-to 127.0.0.1 port $trans_port
pass in quick on lo1 inet proto udp to port domain divert-to 127.0.0.1 port domain
# uncomment the following line if you want to use hidden services
pass out quick on lo0 inet proto tcp to 127.192.0.0/10 route-to lo1
pass quick on { lo0 lo1 }
# uncomment the following line if you need to be able to connect to this system
# from elsewhere on your $non_tor subnet
#pass in proto tcp from $non_tor to $non_tor port { 22 }
pass out quick inet proto tcp user _tor flags S/SA modulate state
pass out quick inet proto udp to port domain route-to lo1
pass out quick inet to $non_tor
pass out inet proto tcp all route-to lo1
I think you're overdoing it with OpenBSD. Whonix offers torrification and isolation out-of-the-box. You can do whatever you want and not be scared of infecting your OS or getting hardware fingerprinted. If you're paranoid you can use Gateway on other machine (I don't know how to do it but it's possible).
>>5010 So, first of all, you're not using the same pf rules I recommended in OP. Test the exact instructions in the OP before doing your own modification or else I can't help you because I can't know what you did in the system.
Add this to your torrc:
TransProxyType pf-divert
>$trans_port
This bugs sometimes. Please check if the port is really loaded in the rules:
$ pfctl -s rules
If it is not, just hardcode it (write the direct number instead of a alias).
>non_tor
Why did you add so many addresses? Just "192.168.1.0/24 192.168.0.0/24" is enough.
>uncomment the following line if you want to use hidden services
Why is this even here? Tor has a option if you want to block hidden services, this shouldn't be done inside the firewall.
Also, you're not blocking remote connections from Xenocara. As I said, use the rules in OP:
block return in on ! lo0 proto tcp to port 6000:6010
>>5020 Give more information. I'm using these exact same rules right now and it is working (I'm using 6.5 release).
Can you access internet at all? What software are you using? Did you set port 9050 SOCKS5? Is the dns pointing to localhost? Does Tor initialise normally? Is the internet connection working without Tor?
Btw, are you just testing using a VM or did you actually install OpenBSD? Because I'm not sure these configs will work on VM.
I can assure you the tutorial in the OP works fine, you just have to copy-paste. As I said, I'm using it right now without issues.
>>5469 There's no reason to use vmm for that. Read the thread.
I do think, though, applying properly pledge and unveil to the Tor client would be very nice. You could ask on the mailing list if that would be possible for the port maintainer (pascal@) to could apply a patch for it...
https://cvsweb.openbsd.org/ports/net/tor/
>>5470 >Read the thread.
I did and all I saw was fanboys either lacking any understanding of what the point of whonix is or (more likely) pretending to.
Is vmm not capable of such a setup? From the docs it seems like it should be.
>>5371 >lacking any understanding
Explain then.
>Is vmm not capable of such a setup?
Probably is. You have to do basically as the OP tutorial, but instead of routing to Tor ports you use the vmm interface. But there's no point in doing that, since a simple rule in pf will do the same thing.
>>5472 If someone got to execute arbitrary code on such a set up, wouldn't it suffice to execute the openbsd alternative of `ip addr`? Even if there's a way (I'm pretty sure there is) of preventing a user from executing such a command, it's still hard to tracks all these little things. And still, the advisory would be able to know a lot about your system.
With whonix however you don't need to think about every detail, if you need access to something outside the vm you have to explicitly allow it first, from the host of course. And most of the time you don't need anything besides accessing one or two folders on the host. Needless to say the vm adds another barrier: "just" getting root access on the vm where the browser runs wouldn't give the attacker much info.
Also, whonix uses an isolating proxy, not a transparent one like OP.
>>5483 I already answered the same questions you did in >>4743 But let's do it again:
>execute arbitrary code
If you execute arbitrary code on the VM you will be fucked the same way. The attacker could simply modify the Tor client to enable them to see your real IP.
>preventing a user from executing such a command
With the OP setup the attacker would need to find a exploit in the pf firewall and disable/modify it. Also, as I said before, most of openbsd base system is now privsep'd with pledge and unveil.
>"just" getting root access on the vm where the browser runs wouldn't give the attacker much info.
Getting root is always game over.
I don't get why you guys can't understand it. Do you think VM is a magick trick for security?
The attacker could easily replace the Tor binary with another one modified if he had root access. Or he could drop the firewall, open any door he wanted and a simple TCP request would reveal your real IP. Example using openbsd (linux would be the same process, but using some different commands):
You wouldn't even know someone modified your Tor VM and would be like 2 seconds to run the script.
Virtual machines does not defeat the laws of reality, stop thinking it's the solution for security, it is not.
>>5485 >If you execute arbitrary code on the VM you will be fucked the same way. The attacker could simply modify the Tor client to enable them to see your real IP.
Are you kidding? TOR runs on a different goddamn VM.
>With the OP setup the attacker would need to find a exploit in the pf firewall and disable/modify it. Also, as I said before, most of openbsd base system is now privsep'd with pledge and unveil.
Does firewall prevent the execution of that command? Does it prevent from getting sensitive hardware info?
>Do you think VM is a magick trick for security?
I'm starting to think it is. How else could one explain people not understanding it?
>>5477 >Also, as I said before, most of openbsd base system is now privsep'd with pledge and unveil.
How's that even related to fucking anything? Or is it more like a mantra or something?
>>5489 And you can't understand what you've read. Here, I'll quote for you the same anon you linked:
>The gateway torifies all traffic it receives.
>Therefore, the only way to get the real IP of the user is to compromise the gateway VM
It is not that complex to understand.
Whonix passes the trafic throught a VM ("gateway"). If you can compromise this VM, you can modify the Tor binary. If you compromise the host, you can simply modify the gateway.
>>5488 >I'm starting to think it is.
See. This is not a /g/-tier imageboard. GTFO.
>Does firewall prevent the execution of that command?
It prevents from leaking the real IP.
>Does it prevent from getting sensitive hardware info?
What "sensitive hardware info"?
The IP is proxied through Tor, the MAC address is spoofed. What more will you get?
>>5490 >How's that even related to fucking anything?
The other anon said about "execution of arbitrary commands". Pledge and unveil limits the possibility of that.
I don't know if you guys are just dumb or I'm being baited.
>>5491 >Whonix passes the trafic throught a VM ("gateway"). If you can compromise this VM, you can modify the Tor binary. If you compromise the host, you can simply modify the gateway.
You'd actually need to compromise tor itself, because that's not the vm where browser and shit runs.
>It prevents from leaking the real IP.
You can get the IP through that command. You can send it back through tor.
>What "sensitive hardware info"?
Models, serial numbers.
>>5500 >that's not the vm where browser and shit runs.
The same applies to the host. Except instead of just modifying the Tor binary you would be able to do even more nasty shit.
>You can get the IP through that command.
I don't understand.
>Models, serial numbers.
If someone has the ability to run arbitrary commands do you think they would only get serial numbers? This doesn't make any sense. The traffic itself will not contain hardware information. The MAC address is randomized and pf is also stopping TCP timestamps.
Unless you're talking about servers. In this case port scanning with nmap could potentially reveal hardware information. But we were discussing client, not server.
Not sure if OP still lurks here. Are these instructions reliable for a computer with a fresh install of openBSD? Aside from this question, I assumed there had to be some config files made prior to these instructions, but that is an assumption.
>>6377 >some config files made prior to these instructions
Nope. Just install according with the FAQ in the website (openbsd.org) and then follow the instructions.
The only thing is that, if you're using wifi, you will have to configure it. There's a session on the FAQ, but the process is like this:
- Find what interface you're using. Type "ifconfig". If nothing shows, run the command "fw_update".
- Create a hostname.if(5) file. For example, if your interface is athn (atheros cards), you have to create a file called hostname.athn0 inside /etc/
- After that, you have to write your nwid and wpakey. For example (where "xxxx" is the name of the wifi and the password):
lladdr random
nwid "xxxxx" wpakey "xxxxxx"
dhcp
- Reboot the system or run "sh /etc/netstart"
Do the configs in OP and done. The only issue is time syncronization. OpenBSD uses OpenNTPD for that, but NTP uses UDP, which is not supported by Tor. So you have two options:
- Temporarily disable the pf firewall to allow UDP traffic. Put this inside /etc/ntpd.conf:
listen on 127.0.0.1
servers pool.ntpd.org
sensor *
Then run "doas ntpd -sd", wait a little bit and then kill the process. Turn on again the firewall and done.
- Or, use TLS timestamps using curl:
>>6377 >>6382 (me)
Btw, besides the configs I'm posting here, I just install and configure some software I need and use every day. Let me know if you're interested in these other configs.
>>6383 Oh anon, your computer love and compassion is endeared, for sharing knowledge. Because most people will not endure a career in coding or computer science, I can only thank you so much for sharing your knowledge. I am such a nerd when it comes to lurking the internet and I thank you. I will try to get this shit top to run torbrowser. Honestly, people don't know this,but sharing is one of the most important actions we can do among each other. The internet is a miracle.
>>6035 (me)
Addendum to this config:
- Links might override the configs if you hardcode the links.cfg file. This happens specifically with the cache and html settings, all the others seems fine. You can change the file permission to read-only or you can add this to the ~/.config/i3/config file while using i3wm (you have to reload i3 using Alt+Shift+R after this to take effect):
bindsym F1 exec pkill -SIGHUP tor && "/usr/local/bin/links -g -no-connect -format-cache-size 0 -memory-cache-size 0 -font-cache-size 0 -image-cache-size 0 -aggressive-cache 1"
- The above config will also rotate the Tor exit node every time you open a new browser using the "F1" key (even though the torrc recommended on OP already does that). This will not work if you fork the browser doing "Esc>l>w", but only by pressing the F1 key. So you need to copy the link (using "Esc>l>c"), then press F1 and finally paste on the bar (press "g" and then Shift+Insert).
Few questions op and thanks for this thread.
1)
How would one take this tor setup and auto-route its traffic through a vpn? So you get tor -> vpn?
2)
Once 1) is accomplished how would I make the setup tor -> vpn -> tor so that I can access hidden services?
3)
What would be a good way to auto-disable this so you can handle captcha portals at wifi spots?
>>6767 >tor > vpn
I don't have knowledge about that and I don't think this is safe, sorry.
OpenBSD has it's own VPN implementation, called OpenIKED:
https://www.openiked.org/
So I guess you have to setup a server with OpenIKED and Tor first. Then you open a door for external connections to the IKED and configure to internally route the traffic to Tor (using a loopback interface and the "divert-to" rule in pf firewall).
So all you have to do is use Tor on your machine to connect to the server and then the server will do the VPN>Tor connections for you.
But I don't know how to do that exactly and, as I've said, I don't think this is safe.
I would suggest you start reading here:
https://www.openbsd.org/faq/faq17.html >auto-disable this so you can handle captcha portals at wifi spots
Using pf rules. On the OP rules, see this bit: "pass out quick inet to xxx.xxx.xx:xx"
You could also temporarily disable the pf rules and then turn on again.
A very useful way of doing that is using aliases in .kshrc.
Write this to your ~/.profile:
export ENV=$HOME/.kshrc
Then create a file called ~/.kshrc and write the aliases. For example, I always do these on my systems:
alias cp="cp -i"
alias mv="mv -i"
alias q=exit
alias cl=clear
alias l="ls -pa"
alias rm="rm -f"
alias p=mpv
Now, when you open a new terminal, these aliases will be loaded.
The same can be done for pf rules. Create one pf.conf with your Tor rules and other one for non-Tor. Then you can:
alias notorrules="doas pfctl -f /etc/pf_notor.conf"
alias torrules="doas pfctl -f /etc/pf.conf"
Now when you type "notorrules" it will prompt the password for changing the pf rules...
To check what pf rules are currently loaded use:
>>4669 Not sure if op is alive still, this might sound dumb, what ever. I did everything in instruction, but what is the command to actually launch the browser?
Current state of tor process is sleep/1. Not sure how to get the interface going. Anyone know what might be missing? thanks frens
getting this error on boot. did everything in OP. tor relay launches no problem, but I can't launch the tor webbrowser. There are no packets to extract in openBSD so it's hard to even launch it from a directory. In the mean time I'll keep researching.
>>7861 You forgot one dot in your /etc/hostname.lo1
>>7848 What browser? Tor Browser? Use Links instead: >>6035 If you want to use Tor Browser, install using pkg_add and it should work out of the box. If not, type "pgrep tor" to see if it's running. If not, run it using "doas tor". Try connecting again. If you can't connect anyway, you need to get more informations and post here (what message the TBB gives? What is on Tor daemon /var/tor/)?
>>7863 >>7867 It's running. Maybe I'm asking the wrong question. It's running, but I don't know how to access onion links with out using the actual tor web browser, or rather, I'm only familiar using tor browser to access onions. I am not familiar with using another web browser to visit onion links, but from the sounds of it, Links can be used.Okay thanks for the update, appreciate it.
>>7869 Yes, Links can be used. As well as any browser supporting SOCKS5 connections.
To use Links the way I personally use and recommend, do "pkg_add links+--" and follow >>6035 and >>6590 (the links.cfg formatting got fucked on >>6035, but it's meant to be one line for each option).
>>7863 >links
Just a warning, don't expect the same level of anonymity as with tor browser.
>doas tor
doas rcctl start tor
>pgrep tor
rcctl check tor
>>7869 Any connection that goes through tor's proxies can access onions.
>>7870 Built in socks proxy is unnecessary, torsocks or proxychains are generally safer
>>7871 I feel like tired of replying when I see these comments.
>Just a warning, don't expect the same level of anonymity as with tor browser.
Already discussed 1 billion times. Don't go over it again.
>doas rcctl start tor
torrc already enforces daemonization. Executing tor binary will do exactly the same thing.
>rcctl check tor
pgrep will just check the process. Logs should go to /var/tor/. Another unnecessary comment.
>Any connection that goes through tor's proxies can access onions.
Not true. You can block onion access in torrc.
>torsocks or proxychains are generally safer
And where exactly is the source for that? It's not true, btw. Torsocks can accept outbound leaks (see "AllowOutboundLocalhost") and doesn't seem to be maintained anymore. A well implemented native SOCKS5 support is much better and is the prefered way of using tor.
>>7873 If you launch Links one time and then exit, this folder will be created automatically. If not, you should:
>>7876 ah I see, that's understandable. Well. I'll give it a shot again. I have to figure out why, after doing OP instructions, I can no longer install software packets.
>pkg_add links
>"https://cdn.openbsd.org/pb/OpenBSD/6.5/packages-stable/amd64/:ftp:cdn.openbsd.org no address associated with name.
>prior
A fresh install of openBSD had no issues with pkg installations, but only after I made OP settings, the above happened.Having had to retype the Op'S instructions is laughable, just so I could get a closer idea of what was causing this problem. The next thing I tried was commenting out the commands, but that did nothing. So I guess I'll reinstall this cunt all over again and install links FIRST. Maybe then it will function.
A anon asked about Whonix security on other thread and I suggested OpenBSD instead. I thought this might be useful for other people, so here's how to make it route all trafic through Tor:
- Install Tor:
# pkg_add tor--
- Disable ICMP timestamps:
# echo "net.inet.icmp.tstamprepl=0" >> /etc/sysctl.conf
- Create a new loopback interface:
# ifconfig lo1 create up 127.0.0.2
# echo "inet 127.0.0.2" > /etc/hostname.lo1
- Make dns resolve to localhost:
# echo "supersede domain-name-servers 127.0.0.1;" > /etc/dhclient.conf
- Add this to /etc/tor/torrc:
AutomapHostsOnResolve 1
TransProxyType pf-divert
TransPort 9040 IsolateClientProtocol IsolateDestPort IsolateDestAddr
SocksPort 9050 IsolateClientProtocol IsolateDestPort IsolateDestAddr
DNSPort 53 IsolateClientProtocol IsolateDestPort IsolateDestAddr
Schedulers KISTLite
- Create a new /etc/pf.conf using these rules:
block all
non_tor = "{ 192.168.1.0/24 192.168.0.0/24 }"
match all scrub (no-df random-id reassemble tcp)
antispoof for egress inet
block return log on egress all
pass in quick on lo1 inet proto tcp all flags S/SA modulate state divert-to 127.0.0.1 port 9040
pass in quick on lo1 inet proto udp to port domain divert-to 127.0.0.1 port domain
pass quick on { lo0 lo1 }
block return in on ! lo0 proto tcp to port 6000:6010
pass out quick inet proto tcp user _tor flags S/SA modulate state
pass out quick inet proto udp to port domain route-to lo1
pass out quick inet to $non_tor
pass out inet proto tcp all route-to lo1
- Done. The next reboot it should already be working. If you use public wifi, don't forget to write "lladdr random" on your interface config to spoof mac address (read the hostname.if(5) man page). Don't forget disk encryption (read the FAQ about softraid-crypto). Also, you can raise securelevel and make the transparent proxy "permanent":
# echo "kern.securelevel=2" >> /etc/sysctl.conf