# Suggestions for securing network...

## danomac

I am going to have a roommate move in sometime over the next six weeks.

As part of the roommate agreement, I will allow access to the internet. He uses ubuntu (that I installed for him ages ago.)

The problem is I have my server running at all times. It runs nfs for file sharing, vncserver (that is used to spawn a remote VNC desktop), sshd, and a mythtv backend (with the supporting mysql server.) I do not want him to have any access to these. This is not a power user, chances are if something happens it's likely it will be an accident from him not knowing what he's doing.

I already have my network set up as static IPs. Has been for quite some time. I know about hosts.allow, hosts.deny and iptables. However, I'm not so sure about how far I should go securing the network. Generally speaking as long as the three mythtv frontends have access to NFS and the mythtv backend everything should be OK.

I do have a laptop that is DHCP and it might be a little bit more tricky, although I can use a reserved DHCP rule to get around that.

Has anyone else been in this type of situation? All I want is to make sure there's no "oops, all your recordings/files are gone."

Mythtv could be tricky as I think it uses udp as well, I'm not sure if hosts.* can deal with that, although surely iptables can.

Ideally it would be nice if my router could run multiple SSIDs, but I just checked and my router may not support it.

----------

## Hu

Packet filtering via iptables can handle all your IP access control requirements, though it may not be the ideal solution.  Based on the information available, my biggest concern would be that he uses one of the authorized MythTV frontends to issue an inappropriate deletion.  If you trust him to be non-malicious, this is probably an acceptable risk.  If you are very worried about this, there are some tricks you could use to prevent MythTV from wiping out all copies of the underlying recording, though that would affect all MythTV deletions, even ones from users who are supposed to be able to delete recordings.  Also, the straightforward way of doing that will still let MythTV's database reflect the deletion, but the file would be preserved for external playback via mplayer, vlc, etc.  I assume you care more about the recording data of the recording than the metadata (title, subtitle, stars, etc.).

Check that your /etc/exports uses safe values.  Export only to specific machines.  Use ro and/or root_squash wherever you can do so without breaking legitimate usage.

Consider whether you want to treat IP addresses as authoritative.  You say he is likely not malicious.  Would you agree that a connection from an IP normally associated with one of your systems can be assumed to be that system?  Absent specific filtering, he could use that IP address for one of his machines.

If you authorize your laptop to connect, check that your DHCP reservation does not permit any other machine to claim that address when the laptop is offline.  Different DHCP servers have different semantics about reserved versus free pools.

----------

## danomac

Regarding the roommate himself, I've known him for > 10 years. He would not intentionally set out to damage the system. He's stayed here before short-term (~5 weeks) while in between house sales (place he was in sold before possession date of next place.) Then he was too busy to be on the internet, so it wasn't an issue then. Come to think of it, back then I hadn't had all this effort put in to my mythtv setup.

My major concern with him (not insulting his intelligence or anything) is that he may not understand what he is doing. Say for example he installs mythtv from the ubuntu repos (which won't be compatible with mine.) I don't know his tendency to install random stuff on the internet, which is less of an issue with ubuntu - he doesn't use windows at all.

He doesn't know any passwords to gain access to any of my physical machines and he doesn't know how to boot/chroot to reset passwords. Although, I think maybe I'll password the bios on the mythtv backend and set it to boot from internal SSD only.

I have wired my whole house with cat6 and have a central wiring closet. While he will have physical access to this closet (and there's nothing I can do about it at this point, small house...  :Wink: ) he wouldn't touch anything in there. I would give him wifi access.

For the frontends, there's no services running other than ssh, and I will generate certificates for those and only allow specific IP addresses to connect to them remotely. 

Another thing I was thinking of doing is getting a cheapy router and plugging it into my router. He does a lot of streaming and browsing random websites on the internet, and he doesn't really download through bittorrent or anything. This way I can grant him his own SSID, set up a static IP for the router, lock the router down and block any access that originates from that IP.

Like I said, I am not concerned about direct attacks, I'm more concerned about "Whoops, I did something and everything's gone." 

He's not likely to use my existing myth frontends. While I won't say he's not allowed to use it. He doesn't watch TV much at all - he has it in his current place but he never watches it. I told him if he wants access to the antenna he can get a V4L card and I'll help him set it up (whether he just uses his own mythtv, unrelated to mine, or just [s]mplayer.

Does mythtv have a retention period for deleted stuff? I never even looked at that.

----------

## Hu

I am not aware of a retention feature.  My idea was to use hard links to mirror the recording directory to an area that would only be modified by hand.  MythTV normally unlinks a deleted recording without other changes, so having a second link to the file would preserve it until you explicitly deleted the second name.  However, MythTV can be configured in a way that breaks this, if you enable the slow delete feature.  That feature iteratively truncates the file down before unlinking it.  Slow delete is a hack to work around some filesystems that stall for a long time while deleting "big" files.

----------

