Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Secure Account Management Across Production and Development Environments

The majority of machines use regular password authentication, making password cracking an easy means for an attacker to gain access to systems—without using any fancy exploits.


advertisement
or example, a number of financial institutions seem predetermined to use NIS to manage large numbers of accounts across a multitude of systems. So what's the problem with that? Anyone who issues the command ypcat passwd can gain access to the encrypted passwords for all users on the network, including administrators' accounts and possibly the root account itself.

Generally, a quick review of that password file will turn up numerous development accounts. A number will have the username as the password, a large number will have the company's acronym as the password, and—the intruder's favorite—one or two will have no password at all. If the intruder isn't lucky enough to find any accounts without passwords, he or she can always run them through a password cracker. Either John the Ripper, or the old favorite Crack, will crack bad passwords within 15 minutes to an hour, and the larger the user environment, the greater the chance of bad passwords.

Administrators should be using these tools on a regular basis, but none seem to be. Some systems I've come across have OS-level controls for password checking, but they aren't being used, either. Given that the majority of machines use regular password authentication, password cracking is an easy means for an attacker to gain access to systems without using any fancy exploits—or even their infamous scripts.



Reduce Cross-Environment Access
What can be done? Initially, administrators should get rid of NIS. They might be able to use NIS+, but support across a heterogeneous Unix environment is spotty and will require some custom scripting. But in the end, it should prove no more painful.

For this scenario, I discuss how best to split the development and production areas. Administrators must carefully determine who in their environments need (and are given) access to both environments. They should ask themselves the following:

  • Do they have separate administrator groups for development and production systems?
  • If so, do any of them need access across environments?
  • Do any other users need access to either environment?
In a clear-cut case, no developers should have access to production systems, and very few administrators should be allowed to work between the two environments. Production systems should consist of only applications and software that have been tried and tested in the development or staging environment. (Administrators whose environments actually work this way are a rarity in my experience.) The challenge is to devise a way to work close to this ideal, while allowing for the exceptions that most environments require. Step one is having the administrator answer the questions above. In general, fewer users should require access to systems in the development environment than systems in the production environment. The number of people who require administrator access should be smaller too. If your administrative group is large enough, responsibilities can be divided among smaller groups that administer each machine type.

Developer Pushback
As security conscious as it may be, developers generally aren't thrilled with a policy that denies them access to production boxes. They often will push back, claiming tight security will make their jobs near impossible or will increase development time. It may make development difficult at first, but developers eventually will get used to it; with any new aspect to a system, a learning curve can be expected. The most important thing is that systems ultimately will be much less susceptible to exploitation.

Setting the security expectation early is the smoothest way to get developers on board, particularly at a startup. Bringing up the security concept late in the development process generally means delays. Since no one really has been thinking about security ramifications, the processes in place will need to be retrofitted. Trying to retrofit a solution becomes very costly in terms of both time and money. Also, most solutions should be able to grow as the environment grows. For both startups and established entities, the introduction of security concepts prior to the first (or yearly) security audit will make the audit much less painful.

Next, administrators will need to download a couple of tools: SSH Secure Shell and Sudo (superuser do). Administrators who aren't familiar with SSH had better become familiar with it very quickly. I've yet to find it in an environment I've reviewed, but SSH should eventually replace Telnet for communication between all Unix boxes, as well as routers. The closest I have seen to such an environment is one where SSH was installed and used by the administrators but Telnet also was enabled and used (often by non-administrators).



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap