hazardous

tmux-as-a-service

"powered by tmux"

i was joking with a friend in real life that hazardous "was powered by tmux". this is all you need to know about the context from which this article spawned. :)

you might be able to piece together what i sort of meant by this: hazardous is not only a webserver but a server in general, running a variety of services over more than just http.

since alot of this stuff is somewhat developmental or experimental, i don't often find myself bothering with systemd service or daemon configurations. i do have experience now with creating my own configurations, but it's not something i feel comfortable doing on the regular.... yet!

enter tmux.

if you're familiar with screen, tmux or similar programs, you'll have a sense of the above terminal's window layout. basically: i remotely tunnel into this server via SSH, and attach my session to a running tmux server session.

you'll notice that the active window appears to be some sort of server application¹, logging to stdout. this window is one of four windows - the first window pane is running a live IRC server, also logging connections to stdout. the other two windows are vim buffers, one of which is this very article!

i first started relying on tmux as a way to easily keep my tunnel connection alive. i know how this sounds, but i simply have not looked into why my SSH connections to remote servers always seem to time out unless i am inside a tmux session. the obvious answer is some sort of function tmux runs beside or around ssh.

while i do control nginx through systemd, both my IRC and note-sync servers are both very experimental projects, requiring me to dive into areas I am only somewhat familiar with - such as using nginx to pipe API's over different ports, all through the .zardo.us domain name. this is pretty basic networking, but i'm learning how to do it 'by hand', how to manipulate internet traffic at the kernel(?) level and stuff.

anyways - tmux. with e.g. my IRC server², i wrestled with the initial setup / configuration for a long time, and when i finally got it working, the last thing on my mind was having to go 'daemonize' the program and tie it in with system boot.

of course every dev worth their salt is probably screaming at how bad of an idea this is.

and - you're not wrong, none of you would be wrong.

as of the publish date i will likely now "lock down" my environment, and daemonize both my IRC and note syncing servers. i don't really feel like googling up on vulnerabilities associated with leaving processes running in screen/tmux sessions over ssh, but i assume it's inherently never going to be as secure as processes that are executed and run locally by loginless users.

when it comes to security, however, i do try to retain a realistic sense of threats. and i think the payoff for anyone with malicious intent would be so little that this server is likely not an "active" target on anyone's radar. once again this is poor infosec-via-opsec (do as i say not as i do) but i know that my servers are doorknocked by bots all day long, but i am confident that noone's getting in with just some rainbow tables.

basically: at the point where someone would exploit a live tmux session to compromise my server, they would clearly have to be so invested that they are likely going to be getting in one way or another. to get to that point they would have to have already compromised certain pieces of private information that renders having to worry about tmux as a vector, useless.

so?

i digress - what i am trying to say is this: if you're hacking away on a development-level server, and you are looking for a cheap way to run binaries without daemonizing them - look to tmux as a pretty decent short-term solution. your mileage may vary! but as long as you're confident in your server uptime, and appraised of the potential security risks, it's been a surefire solution here at hazardous. with the combination of nginx+tmux, the hazardous domain has served as the front door for multiple layers of services and API's, while still handling HTTP traffic with the most bleeding edge³ protocols. :)

August 15, 2021