Posted: February 21st, 2011 | Author: rthomson | Filed under: Sysadmin | Tags: campus, remote access, security, users, vpn | No Comments »
Yes! We’ve implemented what I think is the best compromise for our remote access problem that I outlined earlier.
Three major things happened that made it possible to compromise:
1. I received an OK from the higher-ups that indeed it would be ok to mandate that users who want remote access to our system have all their Internet traffic routed via the VPN.
2. The VPN configuration that was proposed is not that of a private group but the generic campus-wide VPN solution with ACLs to allow VPN clients to access our resources.
3. The generic campus-wide VPN service does *not* implement any outgoing restrictions, unlike the private VPN groups do. This makes it possible for VPN users to do whatever they want when connected, with the stipulation that it’s akin to bringing your personal computer to campus in terms of privacy.
This really is the best of both worlds (security, ease of use). The campus VPN service is super-simple to use and we restrict access to our services to VPN users instead of the whole Internet. While we don’t control who gets access to the VPN, the pool of users is MUCH smaller and at least semi-trusted by the organization. Thus the risk is greatly reduced.
I’m happy.
Posted: October 2nd, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: cfengine, linux, policy, script, security, server, software, sudo | 3 Comments »
It’s been a while since I’ve really had time to delve too much further into cfengine 3 since my previous post on the subject way back in May but I do have another simple example to share. This time it’s about managing your sudo policy via the sudoers file.
The example is that of a very, very basic sudoers policy but the principles are easily extended to create much more complex policy. The general idea here is that we want cfengine to ensure that specific rules are always in place. Instructed properly, cfengine accomplishes this very well.
Warning: I don’t know anything. I’m just someone learning cfengine 3 and posting about it. If I’m wrong about something, let me know! If you find this at all useful, be my guest. That is all.
[ Read More ]»
Posted: May 18th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: cfengine, code, denyhosts, linux, security, server, snippet, software | No Comments »
I’ve recently begun looking into configuration management with cfengine 3. I’ve ignored this growing sub-field of system administration for too long and I just can’t ignore it anymore. After spending quite some time researching the philosophies, methods and different tools out there, I settled on starting out with cfengine 3. There’s no special reason that I chose cfengine instead of puppet, bcfg2, chef or AutomateIT. I haven’t used any of these tools and thus I cannot pass judgement on them or their methods. All these projects seem to have intelligent and highly motivated people behind them. I simply gravitated towards cfengine because of its strong academic background and the fact that version 3 now represents the most recent and modern research in the field by Mark Burgess et. al.
As part of my learning experience with cfengine, I’ve decided to start posting some of the code that I’ve begun developing in the hopes that by writing about it, I can learn better, faster and maybe even receive some helpful comments from readers along the way. Beware, I’m a cfengine newbie and so what I post here should NOT be copy and pasted into your environment unless you’re ok with the potential of wildly breaking things!
The first snippet of code I want to discuss is related to managing our DenyHosts configuration. As part of our “security policy”, I would like to ensure that every RedHat/CentOS system is running a properly configured DenyHosts instance. Here is what I’ve come up with so far.
[ Read More ]»
Posted: May 7th, 2010 | Author: rthomson | Filed under: Sysadmin | Tags: code, linux, security, server, software, vendor | No Comments »
I recently decided that it’s about time to setup consistent, explicit and tight firewall policy across our Linux (mostly RHEL/CentOS) servers. One of the initial issues I faced was NFS. NFS implementations are very well known to make use of the portmapper and dynamically assigned port for rpc.mountd and because of this dynamic assignment, firewalling NFS can be challenging.
Luckily, RedHat’s /etc/sysconfig/nfs configuration file read by various “nfs”, “nfslock” and RPC services init scripts provides an easy means of locking down specific ports for all the NFS-related services so that one doesn’t have to work around the dynamic port assignment problem when it comes to firewalling.
[ Read More ]»
