Immer mehr Schadcode hat das Ziel das befallene System als Bot zu nutzen und es aus der Ferne zu steuern. Dabei wird es dem Botnetzbetreiber all zu oft sehr leicht gemacht die Kommunikation zur Steuerung aufzubauen und durch ein niedriges Sicherheitsniveau den Schadcode zur Ausführung zur bringen.
Ein befallenes System nutzt die vorhandene Infrastruktur aus, um mit dem Steuerungsserver des Botnetzbetreibers über das Internet in Kontakt zu treten. Ist dieser Kontakt hergestellt, arbeitet das System fortan für den Botnetzbetreiber. Für diese Kommunikation werden häufig Verbindungen verwendet, wie sie auch Instant-Messaging oder Peer-to-Peer Anwendungen nutzen oder werden als http- oder https-Verbindungen getarnt. Einfache Gateway oder Firewall-Router sind daher nicht in der Lage diese unerwünschte Kommunikation zu erkennen. Auch werden die neusten Varianten den Schadcode immer schneller verteilen, so dass den Herstellern von Schutzsoftware kaum Zeit bleibt die Muster in ihre Pattern-Files einzubauen und zu verteilen. Daher kam es in jüngster Vergangenheit immer öfter vor, dass ein System infiziert wurde.
Um sich auch hier Schützen zu können ist es um so wichtiger die Kommunikation und deren Inhalte komplett zu kontrollieren. Die oft benutzte Regel von kleinen Firewall-Gateways mit any allow nach extern ist nicht nur potentiell Gefährlich sondern im hohen Maße auch fahrlässig. Dies gilt selbst auch für Hosts innerhalb eines Netzwerks, selbst wenn es als „sicher“ eingestuft ist.
Da man sich nur noch bedingt auf die oft unzureichende Aktualität eines Pattern-Files verlassen kann, bleibt nur der Weg die Kommunikation umfassend zu beschränken. Dies ist auch dringend nötig um sich nicht auf einen Schutzmechanismus verlassen zu müssen, der, wenn es auf Minuten ankommt, einfach zu träge ist. Es muss ein Umdenken stattfinden und der nur oft aus Bequemlichkeit beschrittene Weg einfach alles oder vieles von intern aus zu erlauben grundlegend überdacht werden.
Bei diesen Überlegungen müssen auch die Strukturen von intern=sicher und extern=unsicher kritisch hinterfragt werden. Intern bedeutet schon lange nicht mehr automatisch sicher. Besonders durch Schadcode der die Schwachstellen im Betriebssystem oder Anwendungen sofort im großen Umfang ausnutzt sind schnell alle Systeme betroffen. Durch die sehr hohe Latenzzeit bis schlussendlich das Pattern-File beim Client ist, liegen alle Vorteile beim Schadcode. Besonders dann, wenn es um Minuten geht.
Viele Betriebssysteme bieten eine ganze Reihe von Sicherheitsmechanismen an, deren Einsatz ein wichtiger Schritt zur mehr Sicherheit ist. Im besonderen gegen den Schadcode der nicht durch die Schutzsoftware erkannt wird. Microsoft wurde oft vorgeworfen nicht genug für die Sicherheit ihrer Betriebssysteme zu tun. Jetzt stehen aber bei den aktuellen Betriebssystemen und gerade im Serverbereich wirkungsvolle Schutzmechanismen zur Verfügung. Diese müssen aber auch genutzt werden, wie sollten sie sonst auch das System schützen können.
Was hier für die Betriebssysteme von Microsoft gilt, ist auch ohne weiteres für die OpenSource Systeme gültig. Der Einsatz aller zur Verfügung stehenden Schutzmechanismen ist daher dringend zu überdenken und deren Verwendung ernsthaft in Erwägung zu ziehen. Seien es Firewall-Regeln, Sicherheitsfunktionen innerhalb von Applikationen oder Funktionen wie Apparmor oder SElinux.
Die Regel any allow ist schon lange keine Option mehr, sei es bei Gateways kleiner Netze oder bei den Systemen selbst. Solche Regeln leisten nur dem Missbrauch Vorschub und helfen schon gar nicht dem Betreiber einer Infrastruktur. Die Frage des Aufwand ist schnell beantwortet. Eine Infrastruktur von Schadcode zu befreien kostet um ein vielfaches an Aufwand gegenüber dem durch die Administration aller Schutzmaßnahmen zusammen.