Die meisten restriktiven Security Policies haben inzwischen ein Alter von drei bis fünf Jahren erreicht. Damals hat man das als Policy niedergelegt, was im gerade führenden Fachbuch stand, und somit auch schon einige Jahre auf dem Buckel hatte. Auf solch einer alten Policy aufgesetzte Sicherheitsmaßnahmen, die typischerweise das böse Internet mit einer (!) Firewall von dem einen (!) internen Netz abtrennen und bestenfalls eine kleine Handvoll Servicenetze (vulgo "DMZ", wobei "mehr als ein Servicenetz" immer noch mit "Respekt! Das ist aber gut durchdacht!" kommentiert wird) beinhalten, sind in der heutigen Welt kaum mehr zeitgemäß; es ist Zeit, hier anzusetzen.
You can’t clean a compromised system by patching it. Patching only removes the vulnerability. Upon getting into your system, the attacker probably ensured that there were several other ways to get back in.
You can’t clean a compromised system by removing the back doors. You can never guarantee that you found all the back doors the attacker put in. The fact that you can’t find any more may only mean you don’t know where to look, or that the system is so compromised that what you are seeing is not actually what is there.
You can’t clean a compromised system by using some “vulnerability remover.” Let’s say you had a system hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn’t. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn’t think so.
You can’t clean a compromised system by using a virus scanner. To tell you the truth, a fully compromised system can’t be trusted. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm and you know that this virus has no back doors associated with it, and the vulnerability used by the virus was not available remotely, then a virus scanner can be used to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action, then you can’t guarantee that the worm was the only thing that used that vulnerability. It is entirely possible that something else used the same vulnerability. In this case, you can’t just patch the system.
You can’t clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have put back doors in non-operating system components.
You can’t trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
You can’t trust the event logs on a compromised system. Upon gaining full access to a system, it is simple for an attacker to modify the event logs on that system to cover any tracks. If you rely on the event logs to tell you what has been done to your system, you may just be reading what the attacker wants you to read.
You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
The only way to clean a compromised system is to flatten and rebuild. That’s right. If you have a system that has been completely compromised, the only thing you can do is to flatten the system (reformat the system disk) and rebuild it from scratch (reinstall Windows and your applications). Alternatively, you could of course work on your resume instead, but I don’t want to see you doing that.
Ein weiser Mann. Ich wünsche mir, dass einige Manager in Zukunft auf diesen weisen Mann hören.
Gefunden hab ich das übrigens bei Dirk, und der hat's von El Loco.
Die Artikelreihe zum Thema "Trennung von Webanwendungen untereinander", die mit fastcgi,suphp und zwei Artikeln über das klassischesuexec begann, findet heute ihren vorläufigen Abschluss mit dem Setup, für das ich mich letztendlich entschieden habe.
Da auf dem von mir angepeilten Zielsystem nur eine Handvoll Präsenzen mit ähnlich wenigen verschiedenen Webanwendungen ins Hosting kommen wird, könnte ich mich für eine Lösung entscheiden, deren Skalierungsverhalten sie für "richtiges" Hosting uninteressant macht. Jede Webapplikation bekommt einen eigenen apache, der gleich unter einer nicht priviligierten uid gestartet wird und auf einem hohen Port von 127.0.0.1 Verbindungen annimmt. Das Mapping auf die "offizielle" IP und Port 80 übernimmt ein zentraler "normaler" apache als reverse proxy.
Dieser Artikel entstand ursprünglich im Jahr 2006. Fünf Jahre später hat auch Debian es geschafft, mehrere apache-Instanzen "ordentlich" zu unterstützen, und ganz ohne gepatchte Scripts. Diese überarbeitete Version dieses Artikels beschreibt die Vorgehensweise unter dem in 2011 aktuellen Debian squeeze.
Seit Jahren schon unke ich darüber, dass Virtualisierung a la vmware, Xen und Co zwar sehr kostensenkend und vereinfachend sein kann, aber mit einer Reduktion des Sicherheitsniveaus einhergeht. Und auch seit Jahren werde ich dafür belächelt und die virtuelle Umgebung trotzdem weiter ausgerollt.
