New to server operation

As title suggests, im new to server administration. Not new to tor, or compiling source code, working with linux, and OS X unix, etc…

I am interested in getting involved with the Tor project as a community member, and relay operator.

Im running into issues with tor not being able to autodetect IPv4 addresses, I figured a work around by using a dynamic DNS updater and registering a hostname. But im still running into issues with my router dropping packets, occasionally sending RST packets and closing sockets. Things being wonky as shit. So I’ve been wanting to put it at the front of the network, to act as both a gateway to my local network, and putting my wifi router behind it, with my wireless devices behind another firewall beyond my relay. That said, what can I do to increase security and stability? Im open to switching OS’s to something different if need be, but would like to stick with OS X Snow leopard if at all possible as its stable, and my relay node is running on an old, heavily modified Mac Pro.

Im also interested in running a Dir Mirror too, I’ve got an unmetered connection, and unlimited bandwidth, and im willing to donate half or a bit less of my bandwidth for this endeavor, and for now, don’t intend on running another relay until I’ve got this one sorted, pen tested, and stable.
Im most interested in running either a guard, or middle relay, not an exit.

Server nickname, MidWorldRelay9
Fingerprint: 51A3394C59BF5E414D57722335CD1E838C6EE986

Just as a heads up, in case you (whoever) searches for this relay nick, you may find up to 3. One I did a test run on a Linode hosted in Canada, and the other was a failure in compiling or config, not sure which, so I wiped the install, erased the keys and started from scratch. Which is why MidWorldRelay9 may show 2 results. I don’t have the fingerprint for the Linode, as I didn’t want to risk potentially de-anonymizing users that had circuits through it. So I completely wiped it before taking the Linode down, and redeploying on my Mac Pro.

Router kept dropping packets, sometimes would close circuits it didn’t like for evidently no reason (at least one I couldn’t find and verify anyway) so I went ahead and did what I was thinking about, and put the machine at the front my network, and put my wifi behind it. This way 2 firewalls are between the relay and all my personal shit. So that’s working, and the machine is also acting as the router coming out of the modem. Seems much more stable now than it was, which is good. Progress. Now im onto the pen testing stage.

Already found and patched a few vulnerabilities accessible via WAN.

Any tips, or advice relay management, and hardening services would be highly appreciated.

So cool Mephisto :slight_smile: I wish I could help you with the relay management but I can barely get snowflake sorted properly at this point lol. I do however have similar aspirations to yours so I hope you don’t mind me asking what modifications you’ve made to your old Mac Pro.

At the moment I’m running the snowflake proxy remotely on an old MBP 9,2 running 10.15.7, but I do have my old Snow Leopard install disc and I’d love to dig up a desktop machine to run it on as I work my way up to a skill level sufficient enough to actually run a relay. Reliable uptime is such a huge issue with laptops running more recent OS versions it seems, so a Mac Pro running SL might solve that problem (one hopes).

Thanks. And best of luck!

Nice to see another Mac enthusiast, seems to be rare. Well, among the mods I’ve made to my machine, one of them is getting my hands on a copy of OS X SL server addition (wouldn’t suggest, updates are… unstable. and Active directory master/standalone break permissions. Though I did figure out a work around, more of a hack really. When booted after new update, it freezes on spinning wheel of death. Booted into verbose mode to see what the issue is, mDNS responder was getting hung on a request due to “Permission denied”
So I booted into single user mode with a root SH prompt, ran a “chmod -r 755 /” and hard reboot, that fixed it and made it want to boot. So that’s cool, though id highly suggest staying away from this particular issue as I nearly went bald trying to figure out why OSX was so unhappy.

But that aside, I built a raid 10 config with 3 500GB hard drives, and another 4tb backup drive (defcon zoz has taught us many things, in that keeping daily redundant paranoid backups will save your ass)
Flashed firmware from 1,1 to 2,1, changed instruction from 32bit EFI to 64bit x86 EFI, so much more stable with that.
Upgraded the dual socket xeon dual cores to quad cores, for a total of 8 logical cores (no multithreading, old as shit yo)

I will warn, nearly all software used on this machine is compiled from open source. Most software that’s made for this OS is old and deprecated, badly and for good reason I might add. The default SSH and remote management client is of a version that’s old enough to cause problems. So I took those offline and made firewall rules saying anyone connecting from the external (wan) interface can’t connect on those ports, and went about compiling VNC and openSSH from source to patch those old vulnerabilities.

Just to be on the safe side, I removed pretty much all baked in software aside from the terminal, sys utilities, and Xcode (gcc compiler needed for open source software) just to be sure that no pre-installed software would attempt to connect or run, or be visible as a running service. This is an effort to reduce attack surface as much as possible.

Something to keep in mind compared to a server edition of OSX as apposed to a standard edition, is the server edition has an extra (what apple refers to as) smart firewall, that dynamically assigns open sockets for devices behind the router so keep state, and streaming can happen without interruption. The regular version of OSX does not have a smart firewall, or dynamic rules the same way. So in order to accomplish this, you’d need to build a firewall from scratch using the client built into MacOS (which for SL is the openBSD firewall prior to PF) and that’s accessible via terminal command, iptables

For more info, either google the man pages for iptables, or open a terminal in macOS and type ‘man iptables’

Also put in a lot more ram, installed a dynamic DNS client (im on a home connection, so dynamic DHCP assignment from my ISP, my public facing IP changes every couple days or so) and pointed the torrc config to that dynamic hostname. For whatever reason, the auto ipv4 was non functional. Though I couldn’t begin to speculate why, I tried to debug but eh, no need when ddns for a single domain is free anyway.

So I’d say my copy of OSX is closer to a linux distro than Mac. Most of the software available as source code for linux can be compiled on macOS.

Running a tor relay node on a MacBook running SL would probably be just fine most of the time, but the reason Im using a Mac Pro instead is because of the server/workstation grade hardware being better equipped the handle what tor needs. Registered ECC memory and xeon processors are just better at those sorts of workflows compared to standard intel core and non ECC memory. But I digress, for most machines not handling a large amount of traffic a setup like this is overkill. My Mac pro is not only just a tor relay, its also the router and DHCP server for my home network, and then my wifi router plugged in behind it, running its own DHCP server and NAT. So instead of the whole network on one subnet, its on 3. The public facing comcast subnet, the internal subnet, and then finally a 3rd layer subnet just for the wifi (network segregation is important for access security)

This way my router can ask the Mac for sockets it needs, and those won’t be shared with tor or the second layer, just tunneled directly and handled all by itself. The idea (I hope anyway) is that if an attacker were to gain access to the Mac, or the node, they couldn’t dig any deeper and infect devices on the wifi side of things, at least without some serious effort.

So this is how I solved the router dropping and sending RST packets to circuits it didn’t like (im fairly sure it was a limit in the max number of concurrent connections bogging it down)
So if you intend to run a relay on the internal side of your network, running it on a MacBook would probably be fine. But if you plan to run a relay that’s going to take in any serious amount of traffic, it needs to be at the front of the network, or given a dedicated cable to prevent collisions, and general… wonkiness. But for a reasonably small operation, say less than 3k concurrent connections and maybe… 2MB/s of transfer consistently per second should run fairly stable on what your after. (A third party or a mod may want to correct or add to this if inaccurate)

That said, I don’t want to give you false info, because many of the points I’ve made have been situationally dependent to me personally, and my clusterfuck of machines.
The only way to get decent at it, is it go do it and see what happens, and fix things as you go along, and remember to pen test your shit. Nmap/zenmap is a wonderfully versatile tool, use it. Use it often and use it on everything, this nmap -sS -sV --script vuln (insert target hostname or IP here) will tell you a lot about what’s going on.

If your intention is to use macOS and only macOS for most of your stuff, you should seriously look into both macports and homebrew.
MacPorts is much more reliable and stable for older machines, like my clusteruck, and brew is great for newer machines. MacPorts includes a -s or -b switch to specify whether you want to install from precompiled binaries, or compile from source using MacPorts (which I highly suggest on older machines, as binaries will sometimes install, then break for no apparent reason), building from source, and it failing, will teach you a lot more, and it tends to work a whole lot more stably than binaries do in a lot of cases. Again, this is a point made from the perspective of a long since deprecated OS. Building from source on newer machines isn’t necessary in a lot of cases, as newer machines, OS, and hardware specs are much more compatible with binaries, old shit like my Mac (which the processors DO NOT support multithreading/hyperthreading) will have a shitfit if a program tries to spawn another thread with a modern instruction that won’t work on that old machine. At least when its compiled from source, its compiled to work on your specific host and architecture.

I hope this helps answer some of your questions, and I hope I didn’t give you a turbo aneurism with this info dump. Please let me know if you have questions, or need clarification on some points.