• 18 Posts
  • 392 Comments
Joined 2 years ago
cake
Cake day: June 3rd, 2023

help-circle
rss

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









  • It likely depends on the courthouse, but generally speaking you’ll show up, sign in, someone will give a little talk about how things work, and then you’ll wait in a waiting room for a few hours while various names are called. Then you’ll go into the court room and the actual jurors will get selected from the pool. They’ll ask some questions and depending on the answer some people will get removed (having a family member who’s a police officer is pretty common).

    If you’re not selected, you’ll probably go back to the waiting room to see if you get pulled for another case. If you are, you’ll sit and listen to the details of the case and eventually make a determination. Depending on the case/jurisdiction, you might also be a “backup juror” where you’ll sit through the entirety of the case, but won’t actually be part of the deliberation at the end unless another juror had to drop out for some reason.

    I ended up getting a murder trial, which was pretty interesting. Overall wasn’t a horrible experience, but definitely glad I brought a Steam Deck while I was waiting.





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