# Secure computer for anti-security users

## tatterdemalian

I'm trying to make a Gentoo/Gnome installation for my parents as secure as possible. The computer will essentially be used for web browsing alone, no web server, no mail server (the users would rather use web mail), no DNS/DHCP server, just a 100% client computer running Gentoo.

Before anyone lectures me about what a waste this is, I should mention that the biggest sticking point my parents have is passwords. They do not want to use secure passwords, PERIOD, end of story. They would honestly rather buy Gateway/Windows computers and throw them away every three months after the accumulating pile of malware and trojans turns them into paperweights, than ever change their plaintext dictionary all-lower-case passwords. Every hacker group from Anonymous to LulzSec probably has their passwords on speed dial, and most of the portscans their ISP netmask gets probably try out their usernames and passwords before even bothering to start "John the Ripper." Thankfully, the only important documents they keep on the computer are photos of their grandchildren (that I regularly have to recover), but I keep dreading the day I have to explain to the FBI that my parents didn't mean to help the Russian mafia break into their system and post the names and home addresses of every undercover agent to 4chan, they just have an absolutely determined mindset when it comes to passwords that ensures any computer they own will be strutting through the internet covered with "Please Zombify Me" stickers.

Since I can't stop them from pouring their entire budget into the Best Buy Geek Squad Computer Replacement Plan, I figured the only other option would be to set them up with a Gentoo box and lock down their user accounts with as much security as possible. Fortunately they don't want to use their internet connection for much, just web browsing and the occasional YouTube video. If they need updates they can call me and I'll use my own account (with a proper password) to run portage.

My question is, are there any good guides to providing security for such inherently insecure accounts? Most of the guides I've found on all the major search engines focus on password security, which is not an option in this case, and don't generally have many suggestions beyond that. I've read the Linux Security HOWTO and implemented as many of their suggestions as possible, but I'm continuing to look for more advice to make the gaping hole a little less breezy. Something that provides advice on how to set up a password-free account similar to the Windows Guest account in Linux, and the steps needed to minimize its ability to wreak havoc with other accounts, would be ideal.

----------

## tel

This strikes me less as a linux issue, and more of a social issue.

If I understand you correctly, you are concerned about two issues:

1. The appearance of malware on your machine due to surfing inappropriate sites

2. The use of insecure passwords for any online accounts they may have.

Although I'm in no way an expert on linux security, it strikes me that problem number 1 is not a terribly big issue, given the nature of linux in general.  Should a malignant script be somehow downloaded from the web, the worst it could do is erase documents in the user's home directory (assuming you haven't given your parents root access.)  This doesn't strike me as a very hazardous situation, given how you describe your parents' web habits.

Problem 2 is a larger issue, and not so much linux-related (or related to any particular OS, for that matter).  You're concerned about their use of online accounts with weak or no password protection.  Why not make it easy on them, and install some sort of service to create strong passwords on the fly and to log them into their sites with those strong password automatically.  If nefarious people can't get a hold of the physical machine, this should be relatively safe.  Lastpass, for instance, is a free service that comes to mind that will serve these purposes.

Hope that helps...

----------

## Hu

 *tel wrote:*   

> Should a malignant script be somehow downloaded from the web, the worst it could do is erase documents in the user's home directory (assuming you haven't given your parents root access.)  This doesn't strike me as a very hazardous situation, given how you describe your parents' web habits.

 Generally, yes.  However, if the malicious script can trigger an unpatched privilege escalation, it could obtain root anyway.  This scenario can be mitigated by the OP keeping the system as updated as possible.  If the OP is willing to put enough effort into it, other techniques could be added, such as separate partitions to prevent unprivileged users writing to any location with execute permission, or even a hardened kernel.

----------

## tel

Noted, appreciated, and I stand educated.  Thanks.

Now, I throw the ball back into the court of the original poster - I guess you'll be the one keeping the system up to date?  Doesn't sound like that's your parents' forte...

----------

## depontius

For such a "limited" machine there are a few more hardening tricks you can pull...

- Put /home on a separate partition, and mount it "nosuid, nodev".

- Consider remounting stuff like /usr as readonly.  In the past I've put together systems with "/", "/var", and "/home".  Then a whole series of bind-mounts so that "/" is nearly read-only, all of the normal read-write stuff (including the portage tree) is under "/var", and /home is separate to survive a reinstall.

- You might want to get even more exotic...  Put /home on tmpfs, and have another place under /var to save their .mozilla directory.  At login copy .mozilla from tmpfs, and use cron to periodically back it up to the location under /var.  (I'd make sure and have at least 2 copies, so that one will be good even if the system dies (or is powered off) during the backup.  The basic idea here is to make any acquired evil as temporary as practical.  By the same token, /tmp should either be wiped at boot (a baselayout configuration option) or on /tmpfs.

You might even be able to set up a hardened box and use selinux.  I suspect that the default policies will allow firefox and flash, and most of the problems with selinux come in when you start trying to run arbitrary local applications.  That said, selinux can be rather hostile to oddball disk setups, like I've suggested above.

----------

## wcg

You might take a look at this guide:

http://www.eng.uwaterloo.ca/twiki/bin/view/Linux/LinuxKiosk

You can probably set something similar up using Gentoo as

the base linux system. Generally, a web search for

"linux kiosk" will provide links to the sort of setup that you

seek. Some of the information will be obsolete, there will

be a lot of noise, there are some commercial vendors of

linux kiosk "solutions" (corp speak), etc, but kiosk use of

linux has the same security problems that you need to

solve.

----------

## Hypnos

Set up a periodic clamav scan to catch infected files they may have downloaded, have the results emailed to you.

----------

## PaulBredbury

This sounds ridiculous. If their gmail password were e.g. "fred", Gentoo wouldn't be able to stop their gmail from being hacked - nor could FreeBSD or even OpenBSD.

Tell them the Ruskies want to infiltrate their PC to spread communist propaganda - maybe they'll get some cold-war protectionism spirit going  :Wink: 

----------

## tatterdemalian

Thanks for all the advice! Yes, a kiosk-style computer is definitely what I need to set up for them, though I still want to also use my own account with elevated (but not root) privileges for maintenance and log reviews. I'm still a newbie as far as Gnome and GDM are concerned, and I didn't know you could configure the login screen to automatically log in an account on physically-accessed selection while simultaneously denying W/LAN connection attempts the same privilege. I've already put their /home directories on a separate partition, and set it nosuid/nodev/noexec (I'm paranoid about executable files, and noexec doesn't seem to bother scripts much). I can't set most of the other directory partitions ro or even noexec as Firefox loves to store and execute files all over the place, especially with Adobe Flash installed, but the ones I could lock down, I have, testing each change. I considered SELinux, but the problems I googled up regarding Firefox and Flash turned me off to that.

Thanks again!

----------

## tatterdemalian

 *PaulBredbury wrote:*   

> This sounds ridiculous. If their gmail password were e.g. "fred", Gentoo wouldn't be able to stop their gmail from being hacked - nor could FreeBSD or even OpenBSD.
> 
> Tell them the Ruskies want to infiltrate their PC to spread communist propaganda - maybe they'll get some cold-war protectionism spirit going 

 

They were on the other side in the Cold War. Like most such people, they expect and demand security for themselves, but it's always somebody else that needs to take the responsibility of providing it (and God help you if you have to crimp their lifestyle in any way in the process). Still, they're my parents, so what can I do? At least any hacker that's broken into their Gmail hasn't bothered to deface anything (and may have died of boredom).

----------

## Hypnos

Are they against even using a password manager or a web browser's password-saving facilities?

----------

## PaulBredbury

 *tatterdemalian wrote:*   

> Still, they're my parents, so what can I do?

 

Hack their email yourself (because better you than the real hackers), insert nasty links, then every time you see them, ask them if their email is OK, and tell them you know exactly how to get rid of such nasty links.

I would assume that eventually they'll listen, or stop using the Internet - either way, mission accomplished  :Smile: 

----------

## tatterdemalian

 *Hypnos wrote:*   

> Are they against even using a password manager or a web browser's password-saving facilities?

 

No, they're biased toward more convenience, not less. Thus the "passwords must be simple words of such profound spiritual significance to myself that they must never be changed in any way" business. I'm just trying to keep them from wrecking their computer (again) while providing as simple a path to what they want as possible. As I may have mentioned before, just trying to keep them off the internet is impossible, as they are invincibly determined to stay online, and quite willing to spend all their money, all the government's money (which they are masters of extracting through dramatic and tragic stories they share with any media outlet on their speed dial), and probably all my own money at gunpoint if it comes to that, to do so.

Come to think of it, why am I sharing all this info? I guess the apple didn't fall far from the tree when it comes to telling stories.

----------

## avx

Had a similar problem with my dad here, that's how I "fixed" it:

a) get a yubikey or similar for every user (http://yubico.com)

b) setup the keys to print a long and static password on short-press of the button

c) use this password for the logins on the local machine

d) give them some password-managing software, which can authenticate the user on a webpage automatically, set it to launch on login

e) use the yubikey's password as masterkey for this software

f) setup the software to create strong passwords for the accounts needed (webmail, amazon, ...)

Setup SSH for yourself, but block every other user.

Of course, this isn't perfect, but it's quite easy to do and imho as secure as it gets without much userinteraction - once it's setup that is.

Edit, don't personally know if there is a good pwd-manager on linux, since I'm not using any and setup the above on a Mac with 1Password.

----------

## Hypnos

As Paul says, it seems like you can protect their computer from them, but not their online identities.  That might still be worthwhile, as it seems that you have taken the responsibility for their computer.

As for their self-destructive financial behavior ... save yourself.

----------

## wcg

Do they use a broadband or dsl modem in the computer, or do they

use an external broadband or dsl router? Many of those small appliances

have a reasonably useful firewall that will block ip spoofing, detect

port scans, etc and block those. You can take the step of blocking

tcp connect attempts from the internet (breaks ftp, but no big deal).

Then nobody is going to be able to ssh in to the box, etc.

Block everything udp and make exceptions for what you need to let through.

A good router will proxy dns, so you can just use the router's internal

interface address for a dns server (and then it does not matter whether

the ISP's dns servers change hostnames or ip addresses).

Anything that the router will not handle conveniently you can manage

with iptables.

To block remote X logins, do not open a hole for traffic on port 177 (udp

only, I think, but you might as well block in/out traffic to/from port 177

both udp and tcp, in case that ever changes).

----------

## depontius

I'd go one step farther, on hardening.

One question... servicing...  Are you able to service this box locally, or do you have to do it remotely?  If local, you don't even need to run sshd, and there are so many sshd attacks these days you're probably better off without it.  If you have to use sshd, protect it.  I presume you can arrange it so you'll always be coming in from a specific IP, so configure and filter the input so only that IP can get in.  Configure sshd so only your userid can get in, etc.

Other than maybe sshd, here is no need for ANY listening ports, other than your DHCP client.  If you really need local services, most everything can be bound to either a Unix socket or the loopback, if they must have an inet socket.  In the gdm configuration there's this nifty little line in the [security] section, "DisallowTCP=true", and you've just disabled remote X more effectively than any firewall.  The best "firewall" is no listening ports.

Then add a firewall, for another layer of extra safety.  Oh, and use tcp-wrappers - one more layer.

----------

## wcg

Here is a useful ip tables command that lets in tcp replies to established tcp

sessions initiated by the local host:

```

/sbin/iptables -A INPUT -i eth+ -p tcp \! --syn -d $MY_HOST_IP_ADDRESS -j ACCEPT

/sbin/iptables -A INPUT -i lo -p tcp \! --syn -d $LO -j ACCEPT

```

I use a static association on the router of my mac address with a specific ip address

in the lan subnet, so I do not need dhcp and $MY_HOST_IP_ADDRESS does not

change. Whatever ip address the router gets from the ISP is irrelevant (different

network, different mac address on the router). If I were using dhcp and let

the dhcp server on the router or at the ISP choose a lan subnet ip address

at random to assign, I could probably run some little script at the beginning

of the firewall script that initializes $MY_HOST_IP_ADDRESS with that dhcp-assigned

ip address.

$LO is statically 127.0.0.1 in my firewall script, so no problem with the second

command.

The key is "\! --syn".  This refers to tcp header flags that indicate an attempt

to establish a new tcp connection or not. If a packet is "\! --syn", then either this

packet is part of an established tcp session or the kernel drops the packet simply

because it has no established tcp session to associate it with.

If a tcp packet arrives that iptables identifies as a "--syn" packet, that would be

a request to establish a new tcp connection, and other iptables rules apply

(is the source ip address lan or not-lan, is the source address our own ip address,

did it arrive via ethernet or some other external network hardware or localhost,

is this a connect for a service that we serve to the lan, etc).

Allowing remote hosts not on the lan (or security-challenged windows boxes on

the lan) to initiate new tcp connects to arbitrary local ports is too high a price to pay

for ftp, imho. (Forbidding such tcp session establishment blocks endless crap from

the internet.)

----------

## tatterdemalian

 *wcg wrote:*   

> Do they use a broadband or dsl modem in the computer, or do they
> 
> use an external broadband or dsl router? Many of those small appliances
> 
> have a reasonably useful firewall that will block ip spoofing, detect
> ...

 

They're set up with a router and external cable modem, and I've already configured the firewall to reject any unsolicited connection attempts via TCP or UDP, though I didn't go so far as to cut off UDP entirely. I also added the following to /etc/sysctl.conf:

# client only, not a gateway

net.ipv4.ip_forward = 0

# prevent icmp exploits

net.ipv4.icmp_echo_ignore_all = 1

net.ipv4icmp_echo_ignore_broadcasts = 1

net.ipv4.icmp_ignore_bogus_error_responses = 1

# death to pretenders

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.rp_filter = 1

# pretty sure these shouldn't pass the router, but just in case

net.ipv4.conf.all.accept_redirects = 0

# take them to our leader, earthling (or just email them)

net.ipv4.conf.all.log_martians = 1

 *Quote:*   

> A good router will proxy dns, so you can just use the router's internal
> 
> interface address for a dns server (and then it does not matter whether
> 
> the ISP's dns servers change hostnames or ip addresses).

 

Uh... let me get back to you on the router quality. It's a cheap $50 Best Buy router, and I don't think it has that capability. In fact I'm pretty sure it doesn't, and relies exclusively on the ISP's DNS servers for everything. Do you recommend any good programs for dnscache maintenance or alerts? I'm hoping not to have to check it for poisoning myself more than once a month.

 *Quote:*   

> One question... servicing... Are you able to service this box locally, or do you have to do it remotely? If local, you don't even need to run sshd, and there are so many sshd attacks these days you're probably better off without it. If you have to use sshd, protect it. I presume you can arrange it so you'll always be coming in from a specific IP, so configure and filter the input so only that IP can get in. Configure sshd so only your userid can get in, etc. 
> 
> Other than maybe sshd, here is no need for ANY listening ports, other than your DHCP client. If you really need local services, most everything can be bound to either a Unix socket or the loopback, if they must have an inet socket. In the gdm configuration there's this nifty little line in the [security] section, "DisallowTCP=true", and you've just disabled remote X more effectively than any firewall. The best "firewall" is no listening ports. 

 

I would rather turn off remote logins entirely, and make all accounts locally accessible only. I don't live far from my parents' house, and they frequently call me out to repair their TV, vacuum cleaner, etc. so I can maintain the computer while I'm out there for other reasons anyhow.

----------

## depontius

 *tatterdemalian wrote:*   

> I would rather turn off remote logins entirely, and make all accounts locally accessible only. I don't live far from my parents' house, and they frequently call me out to repair their TV, vacuum cleaner, etc. so I can maintain the computer while I'm out there for other reasons anyhow.

 

At this point, your safest bet is to turn off everything you reasonably can, and anything that must listen, limit it to a Unix socket or the loopback device/address.  If you can do this, you won't need a firewall at all, but it's obviously nice to have for extra safety.  BTW, you have to let at least some UDP in, for DHCP.  (Typically ports 67, 68.)

----------

## wcg

For dns, I have this in /etc/resolv.conf:

```

nameserver [router's ip addess on the internal lan]

domain  [my internal domain]

```

Then I have an iptables command in the firewall script that allows in udp traffic

from source port 53 with the router's internal ip address as source ip address:

```

/sbin/iptables -A INPUT -i eth+ -p udp -s $ROUTER -d $MY_HOST_IP_ADDRESS --sport 53 -j ACCEPT

```

That works.

Try it and see if your parent's router will proxy dns for you from the ISP's

dns servers. It may have that capability and it is simply poorly documented.

There were some notes in /etc/conf.d/wireless.example and /etc/conf.d/net.example

(recently moved to /usr/share/doc/openrc-[version]/ IIRC) on settings that would

overwrite the nameserver address in /etc/resolv.conf that one should probably

consider.

----------

