# Securing my Gentoo box

## LIsLinuxIsSogood

Recently I was hacked and as a result I am busy securing my box at the moment. I'm now going through and wondering about some things in the Security Handbook...right now, I'm at a section that describes rules for access control, using the PAM software and a configuring of the file access.conf.  

There's not a lot of info about the subject there (or in the installation handbook) but something that does overlap is the use of a domain that may help to secure the machine's access to any outsiders.

So my question is why be going about it the way the security handbook says and is that an improvement to the more general options for how PAM works, in which case, maybe I just write my own access.conf file. The way it is mentioned in the security handbook, suggests just two minimal rules (of which an important one is there to restrict access to users not part of the wheel group).  That part of it I sort of get and agree with totally.  But the second rule that is there is  sort of confusing to me, which restricts access further to those within the wheel group for access outside of a computer with domain ending with gentoo.org.

Here's the portion of the file...

```
-:ALL EXCEPT wheel sync:console

-:wheel:ALL EXCEPT LOCAL .gentoo.org

```

There's also a disclaimer along with it. 

 *Quote:*   

> 
> 
> This will setup login access so members of the wheel group can login locally or from the gentoo.org domain. Maybe too paranoid, but better to be safe than sorry.

 

Could someone please help me to understand what action I may take to further secure logins, and whether or not having my host be associated with a domain is helpful at all, both in terms of the access control and for any other purposes in general?  My previous understanding of the subject of domains has only to do with things like active directory or some other workgroup (set of computers).  But I understand the language of networking very well.  So please feel free to explain the use of the domain in however much depth.  I'm still just not sure what does the  "gentoo.org" domain matter?  And how it changes the security or of my keeping a couple of devices on a network that should be able to do just the very basic stuff that is available to local networks like SSH or telnet etc.  

Thanks for the help in advance.

----------

## krinn

Well, you should put the url of your source of information if you want anyone to check it, else, we must trust how you interpret what is wrote there.

From what i understand myself, it's a protection against a non root user to get root rights using su while the user is allow to use su because that user is in wheel group.

The protection doesn't comes from the domain itself, the protection comes from the "LOCAL" keyword.

To endup with the rule: only user in wheel group can do su, and only local user can do that.

This way, if someone ssh "a_wheel_user" and try to su using it, it will fail.

You must check what really "LOCAL" mean in PAM context, but i had always seen it as "LOCAL" meaning a local IP address range (192, 10...)

And the idea there is that, only someone with a local network IP can use it.

The domain itself has no meaning, except to simplify the syntax because LOCAL can be restrict even more ; ie: LOCAL 192.168.0.* (allow 192.168.0.4 or 192.168.0.6 to use it, but reject 192.168.10.4 to use it). And using gentoo.org domain ease the writing (you allow any local IP that use gentoo.org domain ; and user just need to set its local domain to gentoo.org to allow then anyone from this computer to use wheel).

Note the difference between "LOCAL gentoo.org" and "gentoo.org" : one allow only local user from gentoo.org domain and the other would allow anyone from gentoo.org (so someone with gentoo.org domain would be able to use wheel user and su ; LOL hacked by gentoo)

All in all, it's a weak protection, because it imply someone has get access to a user that is in wheel group.

First it mean you allow a user with weak password in your system ; and second (and worst) you not only allow that, but you also put your trust in him by granting him rights to use su (as you have add him in wheel group).

If you allow stupid users to use wheel, or just allow user to use weak password, then nothing can protect you against your own failure.

Anyway, from what you wrote if you only have use of local network, just don't put any computers in DMZ and cover everyone behind NAT.

You don't need any local complex rules to prevent external attack, just don't expose a computer to external interaction if it have no need to do any.

been outside DMZ doesn't prevent your computer from ssh to another host in internet, but it will prevent another host in internet to ssh to it.

----------

## LIsLinuxIsSogood

Thank you krinn for your getting back on this.

As suspected, this is a question that I will want to look into more with the general options for PAM.  But I appreciate your help to be pointing to the more obvious concern of the access from internet to my local machines in general.  That is something that I will be certain to follow going forward, at least until I can properly setup a firewall from within the LAN to be able to expose those PC's to further traffic from the internet.  I wonder by the way, how do the software vpn type of connections get around this issue like LogMeIn and those things, which I'm guessing are just anything but secure.  Although possibly through a third party server?

----------

## NeddySeagoon

LIsLinuxIsSogood,

There are several VPN tools for Linux.  They all do similar things. Listen on a port for connections, establish the identity of the connector using a challenge/response and if all is well, set up an encrypted tunnel over the untrusted network. The tunnel is rekeyed on a regular basis too.

Its not a lot different to key based ssh.  You don't find random attackers trying to break into VPN because there is no possibility of guessing passwords.

Feel free to add a VPN server to your collection.  If you use any public WiFi at all, you should either use VPN or tunnel everything over ssh.

----------

