There is a big problem in defending systems today. The majority of systems are using the secure configuration as defined by the CIS and NSA as well as others. These configurations are decide upon by a group of system administrators and can take many months or years before they are published and used. There needs to be proactive research in this part of security.
The current field of security research seems to be more about various ways to attack an operating system. There needs to be research in how to defend a system as well. This research needs to be done in a more consistent manner which can be reproduced by others.
I would like to propose a method to make this happen. I keep thinking of the movie "Virtuosity" where a virtual personality was attacked by various other evil personalities until a final personality emerged. I am hoping for more of a string defender to come out in this case.
For the testing platform, I am proposing Software Testing Automation Framework (STAF) which could be used to establish a standard method for security researchers. STAF can be used for testing attacks and defenses of various operating system.
I could see the system being used with three types of system. The attacker system loaded with metasploit so some other attack tools. A system to monitor the communications between the system. A third type which will the victim system.
The victim system would start as a generic version of an operating system or a version that matches the one being used in the environment of the researchers. This system will be attacked by the tools and monitored for changes.
There are two goals for each of these tests. The first is to find a way for the victim system to report that it is being attacked and by what method it is being attacked. The second is to find a mitigation or protection for the system from the attack.
The reporting is very important because the System Administrator and Security need to know that a system is being attacked. Without reporting the attacker can try many different forms of his attack until one works.
The changes need to report and defend against each attack need to be posted to a server where other researchers using the same system can make use of the results.
The plan would be to test all available attack tools against an operating system and have a central website where system defenders could make use of this research to protect their systems.
The first run through of the tests would be the hardest as a method for reporting will need to be found and tested. The next hardest piece will finding the mitigation against the attacks.
Once the first run though has been done, the system could then easy be used to test patches to the operating system and changes in the attack tools to verify if there are any changes needed in the reporting and defense of the operating system. All of this should be reported to a central site where defenders can keep their systems current.
If this research happens and system become less vulnerable, I could see the hackers job becoming a lot harder.
Friday, February 15, 2013
Make production Linux system more like LiveCD
I had a few thoughts about making Linux more secure by way of a few mechanisms already in the operating system.
The filesystem for Linux includes the ability to make a file immutable, a.k.a. can not be changed, only read. It should be possible to make a version of yum or any updater aware of this feature. So in this case, when a system update comes in the, the updater verifies all of the signatures and security of the files, then quickly turns off immutable for the file to be updated, overwrites that file and then turns on immutable again. This would prevent an attacker from changing critical system files with malicious code.
The files in sbin should only be executed by root, so in this case the permissions should be 500 since there is no need to write to any of these files. If a user needs to run this file, they will need to have sudo access to it.
There should be no files in the sbin or buin directory that has world enabled flags and no write flags should be on as well.
Configuration files should also be immutable with a separate program to modify them. This should include a way to verify that the file was only changed by this program; a hash signature tied to a database that can be checked.
Log files should be set with the append only flag and when they are rolled over they should be set with the immutable flag until they are ready to be deleted.
Library files need to be just library files. The system should check to see that when a library file is called, that it really is a library file and not an executable. Executable files need to be labeled and in the bin or sbin directory.
The system would need to have a program that verifies the signatures of the files that are on the system, much like 'rpm -Va' but with additional check to make sure that the files are immutable and that configuration files have only been updated by their configuration programs.
All of the above checks could then be used by a kernel that verifies the signature of a program before allowing it to execute.
All of the pieces to make this happen are in Linux today, they just need to be pulled together.
Ultimately the operating system would need to change to two version, one without these protections that would be for development and the other for production. A development version would be used by the developers and when they are done, the program files will need to be packaged up and signed. This would enable the production system to verify that the codes have meet some form of security before being installed on the system.
The filesystem for Linux includes the ability to make a file immutable, a.k.a. can not be changed, only read. It should be possible to make a version of yum or any updater aware of this feature. So in this case, when a system update comes in the, the updater verifies all of the signatures and security of the files, then quickly turns off immutable for the file to be updated, overwrites that file and then turns on immutable again. This would prevent an attacker from changing critical system files with malicious code.
The files in sbin should only be executed by root, so in this case the permissions should be 500 since there is no need to write to any of these files. If a user needs to run this file, they will need to have sudo access to it.
There should be no files in the sbin or buin directory that has world enabled flags and no write flags should be on as well.
Configuration files should also be immutable with a separate program to modify them. This should include a way to verify that the file was only changed by this program; a hash signature tied to a database that can be checked.
Log files should be set with the append only flag and when they are rolled over they should be set with the immutable flag until they are ready to be deleted.
Library files need to be just library files. The system should check to see that when a library file is called, that it really is a library file and not an executable. Executable files need to be labeled and in the bin or sbin directory.
The system would need to have a program that verifies the signatures of the files that are on the system, much like 'rpm -Va' but with additional check to make sure that the files are immutable and that configuration files have only been updated by their configuration programs.
All of the above checks could then be used by a kernel that verifies the signature of a program before allowing it to execute.
All of the pieces to make this happen are in Linux today, they just need to be pulled together.
Ultimately the operating system would need to change to two version, one without these protections that would be for development and the other for production. A development version would be used by the developers and when they are done, the program files will need to be packaged up and signed. This would enable the production system to verify that the codes have meet some form of security before being installed on the system.
Subscribe to:
Posts (Atom)