Results 1 to 6 of 6
Hello: I'm working with a small org that is moving their servers to linux. They have 2 developers that will cover their development dba, and deployment issues and now in ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 04-08-2010 #1
- Join Date
- Feb 2006
Implementing security in small org
I'm working with a small org that is moving their servers to linux. They have 2 developers that will cover their development dba, and deployment issues and now in addition, they will perform some of the sysAdmin responsiblities.
Mgt. wants separate userids setup for each role. A user would sign on to the system with the appropriate userid for the task to be performed.
The problem with this approach is that with only a couple of people involved, both
people will end up assigned with the sysadmin role or the backup sysadmin role.
SysAdmins have root access and thus can do anything they want to do. So, what's the value of separate userids for each role?
My questions: How have other small organizations managed this problem? What other techniques could be used to manage this problem? For example, could the server log all activity so there would be an audit trail of who did what? How would you suggest we do this? Any other ideas?
- 04-08-2010 #2
set up groups for both sysadmins and dbas
Design log, dump,... directories, so that group dba can access it
Every user has to login via his/her userid.
Sysadmins can then escalate to root with their user password and sudo.
Because more or less anything they do needs root and they should know what they are doing.
For the DBAs, you can define in sudo config, which commands they are allowed to execute with higher permissions.
What and how many commands is up to you and your organization
- restart of the db process (mysql/postgres/etc) might be ok.
- restart of the machine not.You must always face the curtain with a bow.
- 04-09-2010 #3
- Join Date
- Mar 2007
1.Place the server under a firewall.There are several FREE ones like CSF,APF,FIRESTARTER and many more.
2.Deny direct root login
3.Se a password expiration policy
And there are many more. Just that those mentioned above suddenly came to mind
- 04-09-2010 #4
Irithori gives good advice. Be aware, though, that if anyone is permitted to sudo a shell or a program (like vi) with a shell escape capability, they can circumvent sudo logging. It's hard to make it both bulletproof and useful for sysadmins, but with strong management policy ("If we catch you intentionally bypassing logging, disciplinary action will be taken") and honest sysadmins, it's workable.
Last edited by Mudgen; 04-09-2010 at 01:23 AM. Reason: Add missing word
- 04-10-2010 #5
- Join Date
- Dec 2008
I am reading The Official Red Hat Linux Security Guide and this guide is a comprehensive book on Linux security: (unable to post url, please google)
For example the issue you mention of providing different roles is explained because there are many different ways to prevent user access to different resources other then just file permissions. For your small orginization, making different roles for two or three users may not be on point. The real crux of security is preventing malicious users access not trusted users. I suggest you take a look at the RH guide and really try to understand what your real security goals are.
- 04-12-2010 #6
- Join Date
- Dec 2009
Virtual Machine + OpenVPN + Configuration Repository
Management is looking for traceability and this is key for not only the development process but for the integrity of the system.
Before you follow Irithori's excellent SUDO advice, let's setup a little bit of an infrastructure first.
Use a virtualization platform like Vserver in conjunction with OpenVPN to develop a stable network environment(for a small business)
Change Management is only effective if you have a known configuration to start with, and a systematic register of changes. For development there are common tools like CVS that help you automate some of these changes. And a simple spreadsheet register of planned changes and some approval forms will go a long way. The objective is traceability in relation to change. If a service goes down, pull up the changelog first! (Sanity is surprisingly illusive when you don't know that you're crazy.)
You're developing an infrastructure and I realize that you have a small organization(starting with likely a somewhat unrealistic budget), However all will be for naught if you don't get this right.
COMPONENT 1 - CoreOS
This is a standardized OS Build that you use to seed a virtual environment. Pick a platform to develop a CoreOS. Whatever you're comfortable with, but something that is relatively higher on the stability curve like CentOS or Debian. Use it to setup a very essential base configuration that you can easily copy or automate the build from. Your CoreOS should include the VM host and basic access to the network devices and file systems. Using either a VPN or separate VLAN's you can setup your CoreOS to provide services ONLY to the Guest VM's and then create NAT rules(iptables) to provision access to the services running on the Guest. You provision all your keys and SUDO access rights very conservatively on the CoreOS for your developers on a private SERVICE network(see below). Create a manual update script that you can run securely from the CoreOS to update these local rights(separate from the main build)
COMPONENT 2 - VPN / VLAN Setup
I use OpenVPN because I like the central routing and static DHCP capabilities. It's not necessary to encrypt all the traffic on the LAN, but it is necessary to segment your network into 2-3 Zones i.e. STORAGE, PRIVATE, SERVICE. The key here is that combining Virtualization with a managed network layer can give you "god" power when it comes to things like allowing SUDO access. Everything in a VM Guest can be logged by the host. Check out VSERVER.org for tips on securing a guest OS.
COMPONENT 3 - Central repository for libraries and configuration
This is where you have to get organized. Use a CVS like subversion to capture active development.(The developers will tell you what they want, but don't let them camp out on their own boxes). You should keep a central repository for your OS build and another one for your configuration build scripts. Research git and "git good" at automating the installation scripts. What this gives you is known configuration state, a controlled build process, and an ability to progress forward without having to throw the baby out with the bath water!
NOTE: Vserver for example can support pretty much any flavour of Linux as a Guest, so for Ubuntu or Redhat junkies you don't have to dispute the merits of one or the other!
COMPONENT 4 - Common sense
Don't get sucked into more than what you need. For example you may need a VPN and it would be excellent for remote deployment etc.., but it may be too much of a learning curve to start with. On the other hand if your management is policy driven and is hyper concerned about security your on the right track. If it ain't broke don't fix it, just virtualize it!
NOTE: I don't recommend VM environment for databases. The issues that I have found both with Linux/Windows is that the I/O is too intensive for VMware/Vserver. In this case, just provision the CoreOS and skip the VM server for databases. OR install the database on the CoreOS and setup iptables to provision access to applications hosted in the guest OS.
Hope that helps bring some perspective to the situation,
Mainstream Networks Ltd.
Maple Ridge, BC