LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 08-30-2014, 09:04 AM   #1
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
Tip: "Security through Configuration Management"


WikiPedia defines "Configuration Management," somewhat stuffily, in this way:
Quote:
Originally Posted by WikiPedia:
Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life.
So, what does this have to do with the "security" of a production web server? Everything!

Your purpose in deploying a web server is both to see to it that the server securely does its appointed job, but especially to see that it stays that way. Unfortunately, we do live in a world in which there are people who deliberately try to disrupt what you are doing. Not, apparently, to steal information ... just to disrupt what you are doing, and maybe twist your system into doing things (like spam-mailing) for them.

Inject into this situation, now, a very common (albeit very lazy) practice: simply "logging on" to the server, and "doing things" when requested, and "that's it." As though no one else could log in ... as though no one else would try. Well, eventually it happens: someone does break in, and what they do is to start changing a bunch of scripts, and, and, you don't know what "the correct state" of that server is.

Hence, configuration management.

Every production server must be thoroughly "hardened" so that it exposes as little of itself to the outside world, and it must also constantly monitor the state of its own files. But these are only defenses, and defenses are only half the battle. Defenses only strive to keep people out. They are not enough by themselves to allow you to quickly and accurately restore a system that has fallen out of its "correct state" for whatever reason (including your own staff's inevitable mistakes).

A key part of effective configuration management is change control, which these days can be very-easily accomplished with free tools like git. Changes are not made directly to the production servers, but to development systems that are not directly connected to them nor directly accessible from them. And the changes are never made directly: they are always tracked using change-control.

As you probably know, a change-control system maintains a complete and detailed line-by-line file-by-file history of every change that is made "under its watch." Changes are grouped into logical commits, and organized into branches. Specific change points (such as the current-state for Server XYZ) are tagged. Any state of the files (including present-state) can be compared with 100% accuracy to any other state, and the files can be restored, without thought, to any state.

The git system is particularly robust because every so-called "repository" is simply a directory, and there is no "single master authority." Therefore, repositories can (and should) be distributed, including archival copies kept in offline locations, so that it is literally impossible for an accurate record of the server's known-good state to be destroyed.

Most distros have the capability to build an installer-DVD that will "image" a system to a known state, and you should build one of these for each production system, keeping these discs securely on- and off-line. The configuration of all systems should be exactly the same. Restoring a system from an unknown state (no matter how or why it got to be that way) should be a matter of restoring the system from the image-DVD and doing a git checkout of the current designated branch and tag.

And you and your staff should practice this, frequently. Grab a system, take it down, and restore it fully or partially from scratch. Think of it as a fire-drill.
 
Old 08-31-2014, 07:38 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,409
Blog Entries: 55

Rep: Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582
Interestingly you seem to be describing what would be a small part of the ITSM Release Management procedures. As I've been promoting use of staging areas for some time on LQ so that's nice to read. My only remarks would be that 0) when using a formal DTAP cycle one would develop solely on development systems, then release to a testing environment, then acceptance and then production and 1) I should make perfectly clear that the ability to "quickly and accurately restore a system" should never be mistaken for an easy way to "fix" a breach of security without proper investigation.
 
Old 08-31-2014, 09:19 AM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,078

Original Poster
Blog Entries: 4

Rep: Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177Reputation: 3177
Excellent points to add ... thank you.

No, I don't pretend that my points are in any way "new." They're not. But they are often overlooked.

Having a known-good (and untouchable) copy of a system is no replacement for finding out how a breach occurred, but it is a tremendous help in determining exactly what the breach was ... at least relative to this particular system, which of course is only a small part of the total picture. It's also vital in getting the system back to a usable state without having to (at that instant) reconstruct the crime.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Friendly tip: how to put "certifications" in a proper career context . . . sundialsvcs Linux - Certification 5 12-11-2012 12:30 PM
Tip: use 'shorewall' rules to limit a server's usefulness as a "zombie" sundialsvcs Linux - Security 4 04-02-2012 04:32 PM
Tip: Why Linux security avoids "viruses" sundialsvcs Linux - Newbie 16 06-07-2007 12:17 AM
"mythtv-setup" giving "Session management error: Authentication Rejected" Mitchua Ubuntu 0 10-09-2005 05:32 PM
"Other ports" not available in Security Level configuration tool CUNextTime Red Hat 3 03-11-2004 12:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 08:18 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration