The power aspect is a lot bigger of a factor than I would have thought. I had an old computer I was going to use as a server for Foundry that I could keep up all the time, but when I measured its wattage and did the math, it would cost me $20 a month to keep on. A pi costs like $2 to keep running, so it paid for itself pretty quick
Relevant xkcd’s
I would throw out that Windows executables work surprisingly well on Linux these days via “wine.” I use EndeavorOS and it’s pretty much no work on my part, I double-click a .exe and it starts it up via wine. I think the only thing that’s been spotty for me is Meshmixer crashes sometimes, but it’s also abandonware so I’m not sure it actually runs better on Windows.
To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.
A simple example hopefully highlighting the difference
Window1:
nc -nvlp 5555 #"far nc"
Window2:
nc -nv 127.0.0.1 5555 #"local NC"
Hi there[Enter]
Hi [Ctrl+D]There[Ctrl+D][Enter]
Window3:
strace -p [pid of local nc]
Window2:
[Right arrow][Right arrow][Ctrl+D]
[Ctrl+D]Uh oh[Enter]
What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.
From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.
The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it
Sorry, I was looking more specifically at that DNAT rule
8 480 DNAT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2222 to:192.168.101.4:22
That rule exists in the host 192.168.86.73, correct? And from the guest, 192.168.101.4 you are attempting to ssh into 192.168.86.73:2222?
It might not be your issue (or only issue), but that DNAT rule says that if a connection comes in on port 2222, instead send it to 192.168.101.4:22. So 192.168.101.4->192.168.86.73:2222->192.168.101.4:22. I would have thought you’d want it to be a DNAT to 192.168.86.73, functionally doing port bending, so it goes 192.168.101.4->192.168.86.73:2222->192.168.86.73:22.
That doesn’t explain the connection refused, though, based on what you’ve said; there’s some fringe possibilities, but I wouldn’t expect for your setup if you hadn’t said (like your ~/.ssh/ssh_config defining an alternate ssh port for your guest OS than 22). It’s somewhat annoying, but it might be worthwhile to do a packet capture on both ends and follow exactly where the packet is going. So a
tcpdump -v -Nnn tcp port 22 or tcp port 2222
For general awareness, not all flags can match all parts of an iptables command; the part you included there with “–to offset” is only valid with the string module, and not the DNAT action. That said after playing around with it a little, iptables actually does short flag matching, so ‘DNAT --to 1.2.3.4’ ‘DNAT --to-d 1.2.3.4’ and ‘DNAT --to-destination’ are all equivalent, so not the source of your issue.
I am having trouble following the IP scheme, though. Is your Alma guest 192.168.101.4, or is that the host IP? If it’s Alma’s and you are attempting to ssh from that IP to the host with that iptables rule, what should happen is that DNAT would then redirect that connection back to Alma. If the guest doesn’t have a :22 listener, you’d get a connection refused from itself.
Your hook has
/sbin/iptables -t nat -I PREROUTING -p tcp --dport $HOST_PORT -j DNAT --to $GUEST_IP:$GUEST_PORT
But I’d didn’t think that “–to” was a flag for DNAT, I thought it was “–to-destination”
If you ‘iptables -nvL’ and ‘iptables -t nat -nvL’ do you see both your DNAT and forwarding rules (although if the default is ACCEPT and you don’t have other rules, the FORWARD one isn’t needed), and do you see the packet count for the rules increase?
Because it’s your computer
Ah, gotcha, I was thinking more in terms of software attacks than hardware, and that some vulnerability would come up at some point for them to get root access, at which point I think they’d be able to get the key one way or another. I’d imagine it also depends on how locked down the system can be based on the nature of their duties; arbitrary internet access makes shipping it off somewhere a bit easier. Another consideration would be that the drive could also be imaged, and if the key were ever recovered at a later date through whatever method/mistake/etc. the entirety of the data could be recovered.
But, yeah, definitely agree that that’s all moving well outside the bounds of disgruntled/opportunistic employee and more into the persistent adversary realm.
Fundamentally, once someone has some of the data, they have that data, and you can make no guarantees to remove it. The main question you need to ask is whether or not you’re okay with limiting it to the data they’ve already seen, and what level of technical expertise they need to have to keep the data.
Making some assumptions for what’s acceptable as a possibility, and how much you want to invest, I’d recommend having the data on a network-mapped share, and put a daily enforced quota for their access to it. Any data they accessed (presumably as part of their normal duties) is their’s, and is “gone.” But if you remove their access, they can’t get any new data they didn’t touch before, and if they were to try and hoover up all the data at some point to copy it off, they’d hit their quota and lose access for a bit (and potentially send you an alert as well). This wouldn’t prevent them from slowly sucking out the data day after day.
If they only need to touch a small fraction of the customer data, and particularly if the sensitivity of the data goes down over time (data from a year ago is less sensitive than data from a day ago) this might be a decent solution. If they need to touch a large portion of the data, this isn’t as useful.
Edit: another nice bit is that you could log on the network share (at your location) which of the customer data they’re accessing and when. If you ever want to audit, and see them accessing things they don’t need, you can take action.
I think the next best solution is the VDI one, where you run a compute at your location, and they have to remote into it. If they screen capture, they’ll still save off whatever data they access, and if they have poor, or inconsistent, connection up your network it’ll affect their ability to do their job (and depending how far away they are it might just be super annoying dealing with the lag). On top of that, it’s dependent on how locked-down they need to be to do their job. If they need general Internet access, they could always attempt to upload the data somewhere else for them to pull it. If your corporate network has monitoring to catch that, you might be okay, but otherwise I think it’s a lot of downside with a fairly easy way to circumvent.
I’m not the most up to speed on TPM’s, but does it have the capability to directly do network access in order to pull the key? Otherwise, you’re going to need the regular OS to get it to the TPM somehow, in which case that’s the weak link to pull the key instead of ripping it from the TPM itself.
And once they have the key once, how do you enforce them having to re-request it? Is there a reason that that point they couldn’t just unplug from the Internet (if even necessary) and copy the entirety of that drive/partition somewhere else?
Microsoft has fired two employees who organized an unauthorized vigil at the company’s headquarters
But they contended that Thursday’s event was similar to other Microsoft-sanctioned employee giving campaigns
Seems like employer approval is an important piece.
But I think the most interesting part of the article is
Nasr said his firing was disclosed on social media by the watchdog group Stop Antisemitism more than an hour before he received the call from Microsoft. The group didn’t immediately respond Friday to a request for comment on how it learned about the firing.
Also made the switch not too long ago, only using Manjaro. Steam’s proton had gotten extremely good at playing Windows games, so there’s a good chance that it could run your old strategy game.
You might already have this on your set-up, but having wine auto-launch for Windows executables has been fantastic. I regularly pull and run Windows executables without really giving it a second thought, and so far it’s generally “just worked.”
No place like loopback
What would be more intuitive? It seems to me to be a
a=1 b=a a=2
Where you’d expect b to be 1, which is the case for bash.