Can I block a plugin from seeing my network?

[bobbob1016]

I have a plugin or two that I don't want to see my *local* network devices, but I do want it to see the internet. How would I set this up? Static routes? I'm not sure exactly what to search for, so any advice would be appreciated.

 

[pirateghost]

Why would the plugin see any network drives? There should be no CIFS/NFS/afp in the jail....

 

[bobbob1016]

Why would the plugin see any network drives? There should be no CIFS/NFS/afp in the jail....

I'll admit it's tinfoil hat thinking, but my concern is closed source plugins/things I manually install in a jail could be port scanning/watching insecure traffic on my network. I was trying to think of a way it'd only see the internet, not local. I'm aware I'd have to jls/lynx to use it, but it's a set and done program.

I also know opensource != safe, bgut it's usually safer^n.

 

[cyberjock]

Yeah.. there's no easy way to do that. Frankly, if their software is port scanning you should be able to see it on the firewall of other devices on your network. My antivirus/firewall actively blocks IPs that it detects as portscanning.

 

[bobbob1016]

Yeah.. there's no easy way to do that. Frankly, if their software is port scanning you should be able to see it on the firewall of other devices on your network. My antivirus/firewall actively blocks IPs that it detects as portscanning.

I'm not really concerned about Port Scanning per say. Just tin foil hatting on running closed source apps that could, in theory, brute force to my other devices over SSH. I have two networks, one only open source save a few plugins. I need one or two closed source plugins, but I'd prefer that they couldn't be used to fingerprint my network/see traffic. I have a DDWRT router, but I'd imagine the settings would have to be tweaked in FreeNAS not elsewhere.

Edit: Now that I think about it, couldn't I just put it on another subnet? That should in theory block it from seeing my other devices.

 

[cyberjock]

Edit: Now that I think about it, couldn't I just put it on another subnet? That should in theory block it from seeing my other devices.

No.. FreeNAS won't be too happy if the server is on one IP and the jail is on another. That didn't work at all in my testing.

There really is no good fix for this. And frankly, if you're that worried about it, you've probably got bigger problems to deal with than this as there are so many ways that this could go badly for you. ;)

Just accept the jail and let the jail do its thing. Jails are supposed to be secure, but programs running have to be trusted to some extent unless you plan to setup firewall rules for all of the other machines on the network. At some point the effort is not worth the gain.

 

[jgreco]

Probably the shortest path to success would be to manually install some ipfw rules.

Assuming your jail is at 192.168.1.200 and your local network is 192.168.1.0/24

Code:

#! /bin/sh -

PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH

ipfw add 1000 deny ip from 192.168.1.200 to 192.168.1.0/24
# technically not necessary since default rule would pass this
ipfw add 1100 pass ip from 192.168.1.200 to any
exit 0

then save it to a datastore and set up a startup script call. Or if it is never going to be more complicated than that, you could just code it in as a single command (the rule 1000 one).

 

[robles]

Code:

PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH

What does this line do? is it so you don't have to type the whole absolute paths to the binaries?

 

[jgreco]

Correct. I write shell scripts all the time. In this particular case it is kinda ridiculous, but us old-timers have a hard time breaking good habits.

 

[bobbob1016]

I'm assuming I enter this on my NAS itself, not SSHed in to the jail. Just so I'm sure what I'm adding, as manpages can only do so much sometimes. I've also tweaked it a bit, but I'm unsure if for the better. I'm asking questions about it to learn, not critique as if I could critique, I wouldn't have needed the help.

1. #! /bin/sh - #
   
2. 
   
3. PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH # <- Sounds like it's saving this script to one of those locations?
   
4. 
   
5. ipfw add 1000 deny ip from 192.168.1.200 to 192.168.1.0/24 # <- adding a rule, called "1000" to deny .1.200 from seeing anything on .1.x/24, but why ip instead of all? Found "all" while researching, why "ip" instead of "all"? Same with "deny" instead of drop?
   
6. # technically not necessary since default rule would pass this
7. ipfw add 1100 pass ip from 192.168.1.200 to any # <- I'm a little confused here, guessing that this is the "off switch" for rule "1000"? Like the "anti-rule 1000"?
   
8. exit 0

 

[jgreco]

Needs to be written as a file onto the filer somewhere and then executed. Writing it to a file on your pool means that it is potentially persistent and can be easily tested. Calling the script on bootup makes it actually persistent.

The remainder are generic choices that you can make as you wish. "ip" is because there could be side effects from messing with other protocols - feel free to experiment. "deny" is equivalent to "drop".

 

[bobbob1016]

Thanks for the help. I'll look in to tweaking it, as I thought it was ipfw something, just not really familiar cli stuff until I've used them before. My thought with "deny" vs "drop" was deny says "no" and drop says nothing. As in, drop wouldn't even say there's a door there to pick the lock on, and deny would.

 

[jgreco]

It's worth checking out the FreeBSD manpage.