Sicherheit durch abdrehen von Outgoing Traffic

worel

worel

Well-Known Member
Hallo!

Ich habe bei einem Webserver welcher Mail, Web, FTP udgl. hostet jetzt mal ausgehenden Traffic verboten. D.h. ich kann vom Server weg keine Verbindung ins Internet aufbauen. (wird an der externen Firewall geblockt)

Eingehende Verbindungen (incoming) funktionieren ohne Probleme, da hier ja stateful gearbeitet wird.

Gehe ich damit richtig in der Annahme dass dies ein Gewinn an Sicherheit ist?
Ich meine Netcat oder andere Remote Access Tools können ja so niemals nach Hause telefonieren.
Mir ist zwar nicht klar inwieweit es durch diese Vorgehensweise generell von vornherein unterbunden wird eine root shell oä. zu erlangen. Jedoch find ich es schonmal beruhigend dass nichts raus darf was eine Verbindung vom Server aus initiieren möchte.

Sollte ich Updates oä. brauchen schalte ich manuell die Verbindung nach außen an, mache meine Updates und schließe dann wieder alle ausgehenden Verbindungen.

Wie seht ihr dieses Verfahren? Zeitverschwendung oder durchaus ein Gewinn an Sicherheit?
 
Interessant.

Warum diese Annahme? Jetzt ernsthaft; denn alles was zur Sicherheit eines Servers beiträgt (in diesem Fall Hosting von Services) sollte in Erwägung gezogen werden.
 
Also... ich verstehe es nicht. Du willst verhindern, dass jemand Downloads auf Deinen Server macht? Also fetch/wget etc? Oder dynamisch Inhalte aus anderen Quellen zieht?

Einen FTP-Server als Server-Anwendung wirst Du so nicht verhindern und auch sonst keinen Server, der auf einem bestimmten Port lauscht.
 
Mit Outbound-Filterung kann man es erschweren (aber nicht komplett unmöglich machen), "Hackertools" (Remote Shells etc.) auf den Server zu laden. Die bei Cracker-Kids besonders beliebte Methode, irgendein PHP oder CGI per HTTP Header Injection (meist GET) irgendetwas fieses von einem brasilianischen Server nachzuladen, wird damit recht wirksam unterbunden.

ABER: Um eine nach /tmp heruntergeladene Remote Shell nutzen zu können, reicht das reine Herunterladen ohnehin nicht aus; dazu sind weitere ausnutzbare Lücken erforderlich. Und die ermöglichen es häufig auch, benötigte Tools notfalls auf den Server zu "pushen". Einem Angreifer muss es dazu nur gelingen, eine TCP-Verbindung zweckzuentfremden, die der Server ohnehin akzeptiert (meist HTTP oder FTP).

Kurz, die Sicherheit Deines Servers hängt im wesentlichen an den öffentlich erreichbaren Diensten, und hier v. a. an den installierten Web-Applikationen (diese werden meist nicht so regelmäßig gepatcht wie eigentlich nötig, da sie häufig nicht über Ports o. ä. installiert wurden - von obskuren Eigenentwicklungen ganz zu schweigen).

Einen größeren Beitrag zur Sicherheit würde etwa ein Layer-7-Filter (z. B. mod_security) zumindest für den httpd liefern. Wenn Du die Applikationsschicht aber schon dicht gemacht hast, spricht nichts dagegen, über Outbound als zusätzliche Maßnahme nachzudenken - da musst Du eben abwägen, ob die zusätzlichen Risiken, die ein Paketfilter bringt (vergößerte Codebasis => höhere Wahrscheinlichkeit für Bugs, mögliche Ausfälle durch Konfigurationsfehler) von dem (geringe) Plus an Sicherheit aufgewogen werden. Für den 08/15 Web-/Mail-/FTP-Server würde ich diese Frage eher mit "nein" beantworten.

P. S: in dem Zusammenhang vielleicht interessant: http://www.my-universe.com/linux-und-bsd/rootserver-security/firewalls
 
Zuletzt bearbeitet:
Was man meiner Meinung nach mit dem deny für ausgehende Verbindungen erreicht ist unter anderem, dass die eigene Kiste Basis für Angriffe auf fremde Systeme wird.

Eine Shell wird bei ausnutzen eines Exploits wohl dennoch aufgehen. Nur kann ich damit dann nicht mehr ins Internet raus was initiieren.

Das nachladen von Schadcode wird erschwert, außer es gelingt jemanden über eine Lücke direkt was "reinzuinjecten"...

Mit mod_security habe ich ganz gute Erfahrungen gemacht. Zwar hab ich einige false positives bereinigen müssen, aber das gros der Rules lieferte gute Arbeit. Die gröbsten Fehler in diversen CMS uä. waren dann zwar evtl. noch immer vorhanden, aber die WAF hat diese dann gekonnt entschärft (bis gepatcht wurde)

Im Grunde ist es (outgoing deny) eine weitere Maßnahme die mir in Kombination mit anderen einen weiteren Schritt zur Absicherung des Servers gibt. Natürlich sind die Systeme nach wie vor up-to-date zu halten.

Die Codebasis wird nicht durch einen Paketfilter erweitert, da ich das deny der ausgehenden Verbindungen auf einer externen Firewall (auch der gateway, in dem Fall eine Fortinet) mache (die ist sowieso auch für die eingehenden Verbindungen zuständig)
Hier sehe ich durch logging auch sehr gut welche Verbindungsversuche nach außen hin gemacht bzw. verweigert wurden.

Mir gefällt sie irgendwie, bin zwar kein Profi Hacker, aber denke dass viele gewöhnliche Hacks damit unterbunden werden. Um einem absolutem Profi standzuhalten muss man wohl das Patchkabel ziehen...

Falls es interessiert (ist zwar auf CentOS aber evtl. ganz interessant):
Ich betreib die Services mit CentOS 5.2, SELinux ist aktiv, OSSEC Hids, mod_security, die Kiste mit bastille gehärtet, mein geliebtes "deny outgoing" aktiv, das ganze laufend gepatcht.

Mir fallen noch immer ein paar theoretische Angriffspunkte ein, aber was soll man denn noch alles machen...


@nakal: ich kann jetzt nicht mal sagen ob der put auf den ftp von außen funktioniert hat. get hat auf alle Fälle gefunzt. Nachdems keine Beschwerden gab gehe ich davon aus dass alle Funktionalitäten klappen. Grundsätzlich wurden von den Usern nur die Services genutzt, welche der Server angeboten hat. Keiner hatte eine eigene Shell oä. wo etwas nachgeladen werden konnte. (nur webservices)
(muss ich nochmal selber ausprobieren)
 
Zuletzt bearbeitet:
Ich denke, wenn ich schon einmal eine Shell auf einem Rechner habe, ist das nachladen von irgendwas das geringste Problem. Ein einfaches cat und die Sache ist vom Tisch. Da wäre es dann eher spannend, ob solche Dinge wie mime-decoder und Co. drauf sind.

Das Argument mit DDOS und Spam ist natürlich ein Argument, das muss ich zugeben...
 
PatrickBaer schrieb:
[...]
Das Argument mit DDOS und Spam ist natürlich ein Argument, das muss ich zugeben...
Zum Vergrößern anklicken....

In der Tat. Das habe ich hier auch so vorgegeben bei den Maschinen die potentiell sowas machen könnten (Kundenwebsites die ich nicht alle kontrollieren kann).
Da sieht man die Sicherheit mal aus einem anderen Blickwinkel, nicht die eigenen Sicherheit sondern die der anderen paar Internetteilnehmer. Ist doch auch schön! :D

Grüße
 
Ein externer, vorgeschalteter Paketfilter ist natürlich ein anderer Schnack, da ein Angreifer den auch nicht manipulieren kann, sollte er sich doch irgendwie root-Rechte verschaffen. Ich war davon ausgegangen, dass Du mit pf (oder eben iptables) auf dem Server selbst filtern/blocken willst. Wenn man eh einen dedizierten PF hat, tut outbound nun wirklich nicht weh. Vielleicht hilft's ein bisschen, schaden tut's auf keinen Fall.
 
@Patrick

wie willst du, wenn du eine shell hast, etwas nachladen (per wget oä.) wenn der Rechner von sich aus keine Verbindung ins Internet initiieren kann?

Ok, vielleicht erlaubt es dir eine Lücke direkt etwas auf diverse Webspaces etc zu injecten. Das geht wahrscheinlich nach wie vor. Ist aber was anderes.

Aber der Abruf von Daten aus dem Internet VOM SERVER AUS sollte somit schon mal nicht mehr klappen. Sowie die Angriffe vom Server AUSGEHEND -> ins Leere.

Wie schon gesagt wurde, schütze ich damit wenigstens das Internet vor mir selber ;-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben