Hack: Massen Anmelde-versuche unter SSH verhindern?

[amiga1200]

ich habe mir eben mal meine Message Log angeschaut:

Nov 13 14:32:18 suse102 sshd[25740]: Invalid user james from 88.80.221.158
Nov 13 14:32:18 suse102 sshd[25742]: Invalid user austin from 88.80.221.158
Nov 13 14:32:19 suse102 sshd[25744]: Invalid user jackson from 88.80.221.158
Nov 13 14:32:19 suse102 sshd[25746]: Invalid user justin from 88.80.221.158
Nov 13 14:32:19 suse102 sshd[25748]: Invalid user brandon from 88.80.221.158
Nov 13 14:32:20 suse102 sshd[25750]: Invalid user john from 88.80.221.158
(Nur ein Ausschnitt)

Da hat einer wohl zu viel Zeit und Energie.
Kann man SSH so einstellen, das es bei 3 Fehlversuche 5 Minuten nichts mehr annimt?
oder was für Möglichkeiten gibt es?
evtl. SSH nur unter ein bestimmten IP zulassen? (ich melde mich immer über die gleichen IPs an)

(Suse10.2) Webserver mit fester IP

[Joe User]

Lediglich die:
AllowUsers

Das haben sie wohl vergessen.

Dafür gibt es die Manpage.

[phor]

Also den Port verlegen bringt schon mal viel gegen die Scriptkiddiemassen.

Falls iptables möglich sind ist auch fail2ban empfehlenswert. Das bannt die IPs nach einer festgelegten Anzahl von Versuchen für eine festgelegte Anzahl von Sekunden. Falls der Port verlegt wird, muss der auch in der Konfigurationsdatei von fail2ban angepasst werden. (Alles festlegbar in der jail.conf.)

[f4rr3ll]

Eine weitere Alternative wäre knockd,
man kann dort den ssh komplett im IPTABLES sperren,
oder auch alternativ den kompletten sshd ausschalten und via knockt starten lassen.
Gruß Sven

[Joe User]

Falls iptables möglich sind ist auch fail2ban empfehlenswert.

Schon mal über Proxys (AOL) nachgedacht? Schon mal selbst ausgesperrt? Schon mal was von SelfDoS gehört?

[phor]

Schon mal über Proxys (AOL) nachgedacht? Schon mal selbst ausgesperrt? Schon mal was von SelfDoS gehört?

Ne, ne, ne.

Angenommen ich werde selbst gebannt, weil ich grad zu blöd bin, mich an meine Passwörter zu erinnern, dann wähle ich mich einfach neu ein und erhalte eine neue IP unter der ich es dann noch einmal versuchen kann - oder ich geh über nen anderen Server. So Bruteforceattacken gehen ja meistens von infizierten Systemen aus und da hilft ein IP Ban eigentlich schon ganz passabel.

Aber du kannst mir gerne näher erläutern, was du meinst ...

[phor]

Okay, klingt auch irgendwo plausibel und ihr kennt euch da mit Sicherheit wesentlich besser aus als ich - deshalb glaub ich euch das einfach mal ;-)

Ehrlich gesagt habe ich auf den wenigsten meiner vServer fail2ban laufen, weil ich denke, dass die anderen Maßnahmen, die du aufgezählt hast ausreichen müssen.

Amiga wollte die lästigen Logeinträge los werden - und dafür eignet sich nunmal fail2ban in der Tat sehr gut. Wie sinnvoll das ist, diese skriptgesteuerten Bruteforceversuche, die zum Alltag gehören, zu unterbinden, sei mal dahin gestellt. Dass so ein Tool auch Nachteile mit sich bringt sollte auch klar sein. Nicht nur in der IT gilt: Keine Wirkung ohne Nebenwirkung.

[anyware]

Was Joe Use meint, weiss ich nicht. Aber ich halte von solchem Zeug gar nichts. Warum?

Du benötigst z.B. fail2ban und iptables, welche Du bei einem gut abgesicherten System nicht benötigst.
JFreund hat Ihr mal einen schönen Artikel eingestellt, der iptables als potentielles Sicherheitsloch entarnt hat.

Damit laufen 2 Stück mehr software auf dem Rechner, welche eine Schwachstelle besitzen können. Dass es welche gegeben hat, wurde sowohl bei heise als auch anderen renomierten Magazinen oft genug berichtet.

In der IT ist es ganz simpel gesagt so:
Einfallslöcher so klein wie möglich zu halten und die restlichen potentiellen und vor allem, bekannten sowie einschätzbaren Gefahren im Auge zu behalten.

Also, ssh abdichten Anmeldung per Schlüssel und allowuser auf das minimum reduzieren, kein rootlogin, kein Passwort Anmeldung.
Wenn Dir das mit dem Log zu viel wird meinetwegen den Port verlegen oder das Loglevel entsprechend anpassen.

"Ich finde aber fail2ban immer noch Klasse und Deine Argumente ziehen bei mir nicht."

Ich spoofe meine IP Adresse, regional Die IP Ranges Deiner potentiellen Provider einzugrenzen kein Problem.
Somit floode Ich eifach Deinen ssh, etc Dämon und wenn ich es nicht zu einer DOs Attacke schaffe, dann wenigstens dazu, dass Du so lange Ich das will nicht mehr per ssh auf Deinen Rechner kommst.
Es wäre auch denkbar einen Deiner Kunden dank fail2ban Regional nicht erreichbar zu machen.

Und ohne den blödsinnigen Ballast von meinetwegen fail2ban und iptables, wird Dein System deutlich geringer belastet und performt bei einer DOS deutlich besser und steckt angriffe leichter weg.

Sorry, jetzt muß ich aber echt mal einen Rundumschlag verteilen. Was man hier rund um Sicherheit teilweise so liest tut schon mächtig weh. Hier werden so oft Dinge aus dem Kontext gerissen und Äpfel mit Birnen verglichen. Ich weiß nicht woher hier mache Statemenst kommen, aber offenbar muß man manche Dinge nur oft genug wiederholen und irgendwann glaubt man selbst daran. Es ist Fakt, dass die absolute Mehrheit an Rootservern bei den Massenhostern in einem katastrophalen Zustand sind. Es existieren dort so viele Webapplikationen, die noch aus dem letzten Jahrhundert stammen und mehr Sicherheitslücken haben als Kundschaft. Es gibt dort Spamschleudern noch und nöcher. Vom Patchstand des Betriebssystems möchte ich gar nicht erst reden...

Glaubt ihr ernsthaft daran, dass es ein Sicherheitsproblem ist, wenn in irgendeinem iptables-Modul irgendwann mal eine Lücke war, die es evtl. ermöglicht hätte mit einem lokal vorhandenem Konto unter bestimmsten Umständen durch einen Bufferoverflow Rootrechte zu erlangen? Kommt mal runter! Hier wird soviel gejammert und gewimmert, dass man gerade "geDOSt" wird oder ein "Massenhack" (nichts gegen den Threadersteller, als Anfänger kann man es nicht wissen) stattfindet, dass man sich ernsthaft fragen muß auf welchem Planeten die Opfer leben. Das ganze Netz ist voll von von infizierten Clients und massenhaft infizierten Rootservern. Da werden täglich Milliarden unkontrollierte Anfragen in jede Richtung abgschossen. Nicht EINE davon gezielt (und wenn doch, dann fühlt euch geehrt; dann betreut ihr offenbar ein wichtiges oder gehasstes Projekt). Das was hier immer als Angriffe bezeichnet wird ist das leider inzwischen völlig normale Grundrauschen im Netz. Es bleiben zwar selbstvertändlich Angriffe, aber auf einem so automatisierten und erbärlich tiefem Niveau, dass ein auch nur halbwegs brauchbar administrierter Server dem locker standhält. Besonders diese irrsinnig "bösen SSH Massenangriffe" sind einfach ein Witz. Wer einen Account namens "james" mit dem Passwort "bond" hat oder "apache" mit "xxxxx" der darf auch ruhig "gehackt" werden; der hats nämlich echt nicht anders verdient. SSH und auch iptables gehören zu den wenigen Komponenten, die selbst besch..... eingesetzt fast noch das kleinste Risiko bilden.

Natürlich kann eine problembehaftete Version von iptables ein Einfallstor sein, aber ihr müsst mal die Verhältnismäßigkeit sehen. Wozu einen elaboriten Hack für Profis versuchen, wenn ich über ein nicht korrekt validiertest Eingabeformular in einer PHP-Applikation mit einem völlig automatisierten Angriff zum Ziel komme? Ein dreckiger Scheinwerfer am Auto ist auch ein Sicherheitsproblem, aber bevor ich den sauber mache, sollte man sich vielleicht erst um die drei platten Reifen und den fehelnden Stoßdämpfer und gerissenen Sicherheitsgurt kümmern. Hier wird teilweise mit Kanonen auf Spatzen geschossen und an anderer Stelle geht alles unter. Rein statistisch gesehen hat vermutlich mindestens jeder zweite Benutzer hier irgendwo in den Tiefen der Confixx/Plesk Webs ein Kontaktformular, welches man absolut problemlos zum Spammen verwenden kann. Vermutlich bekommt man darüber sogar einige Millionen Mails durch die Maschine, bevor es irgendwer merkt. Oder anders gesagt: Irgendwer verdient einige Tausend $ damit während sich der Admin sicher fühlt, weil er ne krasse Kombination auf fail2ban (aka selfdos), Portknocker und Portverschiebung des SSH-Daemons gemacht hat.

Irgendwie wird besonders in diesem Forum auch noch immer das Märchen erzählt, dass man keine Firewall braucht weil ja eh nur die Ports gesperrt werden auf denen sowieso nix läuft. Es hat offenbar immer noch kaum einer verstanden, dass 99% der üblichen Angriffe in irgendeiner Form einen Weg "nach Hause" brauchen. Genau für diese Fälle ist eine Firewall Gold wert. Es hat auch scheinbar immernoch niemand verstanden, dass man über einen Dreizeiler in PHP quasi belibige Ports auf der Maschine öffnen und nahezu die gesamte Festplatte leerlutschen kann. Über schlechte Uploadmechanismen oder ein worldwritable Verzeichnis damit die User ihre Avatare fürs Forum hochladen können ist sowas bei schlechter Software leider ratz fatz erledigt.

Ich stelle leider immer wieder fest, dass manche Leute virtuellen Stacheldraht ziehen und Selbstschussanlagen installieren, aber final jeden Tag den Tag der offenen Tür feiern.

Wenn nur ein paar mehr Leute einige grundlegende Tipps beherzigen würden, dann hätten wir alle ein deutlich einfacheres Leben.

[oxygen]

Irgendwie wird besonders in diesem Forum auch noch immer das Märchen erzählt, dass man keine Firewall braucht weil ja eh nur die Ports gesperrt werden auf denen sowieso nix läuft. Es hat offenbar immer noch kaum einer verstanden, dass 99% der üblichen Angriffe in irgendeiner Form einen Weg "nach Hause" brauchen. Genau für diese Fälle ist eine Firewall Gold wert. Es hat auch scheinbar immernoch niemand verstanden, dass man über einen Dreizeiler in PHP quasi belibige Ports auf der Maschine öffnen und nahezu die gesamte Festplatte leerlutschen kann.

Ebenso könnte ich eine callback shell starten. Wie hilft hier eine Firewall? Eben, gar nicht. Eine Firewall hat nur gegen wenig versierte Angreifer einen Nutzen. Die haben aber schon durch andere Maßnahmen keine Chance.

[anyware]

Ebenso könnte ich eine callback shell starten. Wie hilft hier eine Firewall? Eben, gar nicht. Eine Firewall hat nur gegen wenig versierte Angreifer einen Nutzen. Die haben aber schon durch andere Maßnahmen keine Chance.

Ganz im Gegenteil. Genau für das "nach Hause telefonieren" brauchst du doch die Firewall.

Und den ausgehende n Traffic hast Du noch nie reglementiert warum?
Richtig weils keinen Sinn macht. Den rest bitte, leses es im Forum nach dürfte sicherlich schon an 1-2 MB sein, was da an Diskussionen angefallen ist.

Wie gesagt, ganz im Gegenteil. Ich habe auch im gesamten Forum noch nicht einen guten Grund gegen die Filterung gelesen. GENAU das meine ich. Einige Gerüchte halten sich hier leider verdammt hartnäckig. Und nur weil es über Jahre hinweg von mehreren wiederholt wird, wird es nicht automatisch wahr.

[oxygen]

Ebenso könnte ich eine callback shell starten. Wie hilft hier eine Firewall? Eben, gar nicht. Eine Firewall hat nur gegen wenig versierte Angreifer einen Nutzen. Die haben aber schon durch andere Maßnahmen keine Chance.

Ganz im Gegenteil. Genau für das "nach Hause telefonieren" brauchst du doch die Firewall.

Du scheinst leider nur über Halbwissen zu verfügen. Eine Callback (=Rückruf) Shell verbindet sich von sich aus mit dem Angreifer. z.B. auf Port 21,53,80 oder einem high port. Wie soll das eine Firewall verhindern? Könntest natürlich alle ausgehenden Verbindungen blocken. Sonderlich produktiv ist das System dann aber wohl kaum noch.
Im übrigen ist das nur eine Möglichkeit. Spontan fallen mir noch 3 andere ein. Glaub mir, mich könntest du mit iptables nicht aufhalten, nur behindern. Dabei ist Security nicht mal mein Steckenpferd.

[daemotron]

*seufz* auch wenn das jetzt die einundrölfzigste Diskussion zu dem Thema ist, will ich als oben zitierter noch mal kurz meinen Senf zu dem Thema zusammenfassen.

Ja, Outbound-Filterung kann bestimmte, inkompetent geführte Angriffe (die meisten sind das zum Glück) verhindern, die aber allesamt voraussetzen, dass $Angreifer schon einen Zugang zum Server gefunden hat. Um es mit Deinen Worten zu sagen: Mit Outbound-Filterung hast Du zwar die Scheinwerfer geputzt, aber die drei Platten Reifen, die fehlenden Stoßdämpfer und der zerrissene Sicherheitsgurt wurden geflissentlich übergangen (die kaputte Applikation oder der ungeschützte Account, über den $Angreifer seinen ersten Zug gemacht hat). Mit meinen Worten: Outbound ist eine Maßnahme zur Schadensbegrenzung (reaktiv), nicht zur Verhütung (präventiv) und kann daher immer nur den letzten Verteidigungsring darstellen.

Mit der Grundfrage des OP hat das aber tatsächlich wenig zu tun: OpenSSH ist ein durchweg sicherer Dienst; die letzten Lücken, die gefixt wurden, bezogen sich (Debian's Malheur mal außen vor) auf exotische Szenarien wie X11-Forwarding, die auf einem Rootserver eigentlich nicht vorkommen (und wenn doch, weiß $Admin eigentlich auch, was er tut...). Mit dem häufig empfohlenen Fail2Ban kann man diese Sicherheit nicht erhöhen, denn ein Depp, der BruteForce auf einen ordentlich konfigurierten (pubkey-auth) OpenSSHd versucht, ist sowieso nicht ganz bei Trost und von vornherein zum scheitern verurteilt. Wen das volllaufende Log stört, kann ja den Port verlegen oder eben etwas häufiger rotieren. Ein Vollblut-Hacker, der tatsächlich weiß, wie er sshd überlisten kann, lässt sich auch von Fail2Ban nicht aufhalten.

Mit der Kombination Anfänger (der Ausdruck sei mir verziehen, aber "unerfahrener Admin" ist so lang zu tippen) + Fail2Ban / DenyHosts & Co. habe ich bislang nur schlechte Erfahrungen gemacht, eben weil sich $Anfänger dank schlechter Regeln oder schlicht Unachtsamkeit mal selbst aussperrt (ok, die meisten haben es nach der ersten schmerzhaften Erfahrung kapiert), sich viel zu sicher fühlt (als müsste man SSH knacken, um einen Server zu kapern :roll: ) oder von den krassen H4x0rs der Gamerclan-Konkurrenz geDoSt wird (auch dazu muss man nicht sonderlich clever sein - wer kannte nicht das legendäre WinNuke? )

Zusammenfassend bedeutet das für mich: Paketfilter können sinnvoll sein, aber nur, wenn sie von Leuten mit dem entsprechenden Fachwissen gehandhabt werden, die erstens wissen wie man so ein Ding richtig konfiguriert, zweitens eine genaue Vorstellung davon haben, worin der Nutzen besteht und drittens keinerlei Illusionen bezüglich der Tatsache haben, wovor so ein Filter nicht schützt. Ich habe auf meinen Systemen i. d. R. auch Paketfilter drauf, schon allein um NAT/MASQ für meine Jails zu managen. Outbound (block in all / block out all) nehme ich nebenher so mit, würde dafür aber wahrscheinlich nicht extra pf aufsetzen, wenn das der einzige Grund wäre.

[noobiesoft]

Hallo erstmal (mein erster Post hier :))!

Ich finde eure verschiedenen Meinungen zu Firewalls sehr interessant!

Du benötigst z.B. fail2ban und iptables, welche Du bei einem gut abgesicherten System nicht benötigst.
[...]
Damit laufen 2 Stück mehr software auf dem Rechner, welche eine Schwachstelle besitzen können. Dass es welche gegeben hat, wurde sowohl bei heise als auch anderen renomierten Magazinen oft genug berichtet.

In der IT ist es ganz simpel gesagt so:
Einfallslöcher so klein wie möglich zu halten und die restlichen potentiellen und vor allem, bekannten sowie einschätzbaren Gefahren im Auge zu behalten.[...]

Und ohne den blödsinnigen Ballast von meinetwegen fail2ban und iptables, wird Dein System deutlich geringer belastet und performt bei einer DOS deutlich besser und steckt angriffe leichter weg.

Im Großen und Ganzen kann ich dir zustimmen, je weniger Dienste auf einem Server laufen desto besser!
ABER, du unterschätzt die Gefahren die von den unteren ISO/OSI-Schichten ausgehen.

Was tut dein System bei einem einfachen ping -s 65000 ? (Falls du ein Trafficlimit oder eine geringe Bandbreite wird es teuer und/oder langsam) Dies ist natürlich einer der trivialsten "Angriffe", aber durchaus wirksam ;) Ich frage mich ob dieser Angriff überhaupt auf deinem System nachvollziehbar ist (denn paranoides logging ist zwar immer hilfreich um einen Angriff nachzuvollziehen, aber geht meist deftig auf die performance)

Außerdem muss man es dem Angreifer ja nicht einfacher machen als nötig, durch geschickte IP-tables-Konfiguration und geschickten Netzaufbau können erstaunlich viele Angriffe abgewehrt oder wenigstens ausreichend protokolliert werden! (z.B. wenn eine IP-Adresse "auffällig" geworden ist (durch z.B. einen Portscan) werden alle Pakete in einer gesonderten LOG-File mitprotokolliert oder z.B. auf ein Honigtöpfchen weitergeleitet [...] )

Natürlich schütz IP-Tables nicht vor Angriffen auf Applikationsebene, aber es ermöglicht schon eine sehr groben Schutz. Deshalb ist es meiner Meinung nach nicht schlecht IP-Tables einzurichten, allerdings sollte man dadurch NICHT erwarten, dass die Applikationen dadurch sicherer werden.

Dann nimm Deine Firewall Blocke Deine Ports [...]
Einen SQL Inject erkennt fail2ban auch nicht ohne weiteres iptables so oder so nicht und verhindert das auch nicht.
Und loggen Deine Webanwendungen so vernünftig, zuverlässig und sicher, dass fail2ban einen Einbruch erkennen könnte und den Angreifer kurzfristig blocken könnte?

Eine Firewall ist im allgemeinen nicht nur zum blockieren von Ports/IP-Adressen da (Vergleiche Wikipedia oder what ever). Das fail2ban&iptables SQL-Injetions nicht entdecken können ist richtig, das sollen diese auch garnicht. Aber es gibt Firewalls die solche Angriffe entdecken können.

Die Problematik "Angriffsmöglichkeiten auf Webapplikationen und Abwehrtechniken" wird übrigens relativ gut in diesem frei verfügbaren iX-Extra beleuchtet: http://www.heise.de/ix/extra/2007/ie0711.pdf

[hr oder wie auch immer hier ein Trennstich gemacht wird ;) ]
Kurz und bündig:
Ich denke, dass es möglich ist auch für hohe Sicherheitsbedürfnisse eine Firewall mit IP-tables einzurichten um den groben Unfug aus der DMZ zu halten oder Unregelmäßigkeiten auf unterer Ebene zu protokollieren. Allerdings ist dieses immer nur ein Teil des Sicherheitskonzeptes und ist KEIN SCHUTZ gegen jede Art von Angriffen, allerdings ein excellentes Tool welches groben Unfug verhindern kann (z.B. Verarbeitung von fehlerhaften Paketen, das Antworten auf riesen große PINGs, das durchlassen/beantworten von traceroutes...). Ich finde die Idee hinter fail2ban eigentlich garnicht schlecht und hoffe das damit mein Mail.log endlich kürzer wird :)

[noobiesoft]

Im Großen und Ganzen kann ich dir zustimmen, je weniger Dienste auf einem Server laufen desto besser!
ABER, du unterschätzt die Gefahren die von den unteren ISO/OSI-Schichten ausgehen.

Was tut dein System bei einem einfachen ping -s 65000 ? (Falls du ein Trafficlimit oder eine geringe Bandbreite wird es teuer und/oder langsam) Dies ist natürlich einer der trivialsten "Angriffe", aber durchaus wirksam ;) Ich frage mich ob dieser Angriff überhaupt auf deinem System nachvollziehbar ist (denn paranoides logging ist zwar immer hilfreich um einen Angriff nachzuvollziehen, aber geht meist deftig auf die performance)

1. Denkfehler.
Einen solchen "Angriff" fängt die HW Firewall im Vorfeld ab bzw. sollte es tun.
Allerdings der IP Filter auf dem Rootserver vermindert den Traffic deshalb nicht.
Die Pakete kommen trotzdem auf dem Host an, auch wenn sie dort gedroppt werden.
Und wenn das Pingen nicht erlaubt sein sollte, weils der Provider schon im Netz filtert, finden sich sicherlich auch andere Dienste die man mit Datenpaketen lästig werden kann.
Also IP Tables hilft Dir dabei nicht.

Zumindestens kann ich dadurch die Antworten verhindern und durch die LOG-Einträge kann ich dank Monitoring Gegenmaßnahmen ergreifen :) (ist mir lieber als mich darauf zu verlassen das mein Provider das wegfiltert.....)

Schau dir die Grafik bitte genau an.
Dort wird ein deziiertes Stück Blech als Firewall eingesetzt.
Wenn wir hier meckern, dann geht es immer um IP Tables auf dem Rootserver.
Ich bin auch für eine Firewall mit Contentfilter.
-> Das gibt aber die übliche Infrastruktur von Rootservern nicht her.
Wenige Anbieter ausgenommen, die wenigstens einen vorgelagerten Paketfiltr anbieten.

Ich setze auf meinem root-sever xen ein und einer der Instanzen übernimmt bei mir die Aufgaben der "Blech-Firewall" mit ip-tables.
Sonst handhabe ich es so, dass ich möglichst eine Instanz für einen Dienst erstelle, damit falls ein Dienst(z.B. der Apache) gekapert wird der Schaden begrenzt werden kann... Natürlich könnte ein Angreifer die komplette Struktur übernehmen wenn er Zugriff auf Dom0 bekommt, allerdings habe ich versucht den Zugriff auf diese so schwer wie möglich zu machen......
Bislang fand ich das vorgehen eigentlich recht gut, (für Contentfilter reicht die Leistung leider nicht aus um den gewünschten Durchsatz zu fahren ;) )

Aber vielleicht hast du ja Verbesserungsvorschläge :)

[Joe User]

Es gab durchaus auch schon Bugs, wo man aus einer V Umgebung ausbrechen konnte.

Es gibt momentan keine sichere VM-Lösung, man kann aus jeder ausbrechen, wenn man weiss wie (neben einigen RootKits nutzt auch so manche vermeintlich harmlose Software entsprechende Tricks; nutzt hier jemand Elster?)...

[noobiesoft]

Das ist ja schön und gut. Ändert aber immer noch nichts an der Problematik.

Security by obscurity war noch nie das wirklich gute Ding.
Es gab durchaus auch schon Bugs, wo man aus einer V Umgebung ausbrechen konnte.
Was Du mir an Diener Idee verschweigst, wovor schützt dich die Firewall nun und welchen Vorteil hat Dein vorgehen?
Ich sehe bisher noch keinen.

Aber kürzen wir es doch einfach mal ab:
http://www.rootforum.org/forum/viewforum.php?f=77

die wichtigen Themen wären was für Dich.

Durch das vorgehen habe ich den Vorteil, dass die Firewall (eigene IP) transparent für den Nutzer alle Dienste (DB,HTTP,...-Server) bereitstellt. Der Paketfilter übernimmt die Verteilung an die verschiedenen Instanzen und verschleiert die Pakete, sodass es nicht direkt sichtbar ist, das die Firewall nicht der eigentliche Server ist. (btw: die (virtuellen-)Server nehmen (fast) nur Pakete von der Firewall an...).

Die Firewall "schützt" mich also nicht direkt (nur durch logging) sondern übernimmt die Verteilung sowie die "Verschleierung".

Der Vorteil von vielen virtuellen Instanzen ist vorallem, dass ich regelmäßige Backups von den kompletten Instanzen mache und im Fehlerfall (oder auch Einbruchsfall) die Instanz deaktiviere und ein Backup der Instanz starte und mir die Fehlerhafte zur näheren Analyse in eine geschütze Umgebung (sprich @home ohne Netzwerk) kopieren kann.

Durch das einspielen vom Backup gehen mir also max. die aktuellen Daten von einem Dienst verloren (also z.B. irgendein php-script auf einem Apache wird zum SPAM-versand genutzt oder "geDOSt" dann bekomme ich von der Dom0 die Nachricht, dass eine Instanz viel mehr Leistung benötigt als "normal"...

Dann schau ich mir das treiben an und bislang konnte ich dank der Trennung in die vielen Instanzen viel schneller feststellen wo genau das Problem liegt... und Gegenmaßnahmen treffen also Patch einspielen oder auch einfach den Zugriff auf DIE EINE Instanz einschränken... oder wie schon beschrieben ein Backup starten und mir das Problem genauer anschauen...

Bislang hat das Konzept übrigens hervorragend funktioniert, aber ich bin für Verbesserungsvorschläge immer offen :)

[Joe User]

Offen gestenden sind mir die Möglichkeiten bei den VMS nicht bekannt.

Blaue Pillen gibt es nicht nur für Windows und was in eine Richtung geht, geht in der IT bekanntlich auch immer umgekehrt...

[noobiesoft]

das Verteilen klappt auch prima über einen Proxy z.B., der dann noch den Vorteil halt Auslieferungen zu beschleunigen.

Das wäre mal ein interessantes Projekt, allerdings befürchte ich das ip-tables in diesem Fall "einfacher"&"sicherer" zu konfigurieren ist... (sicherer meint, das ein Proxy um Größenordnungen komplexer ist und dadurch die Wahrscheinlichkeit steigt das Fehler (auch in meiner Konfiguration!) zu Tage kommen.)

Zielsystem es geschaft habe ein Loch erfolgreich aus zu nutzen, dann ist es eine Leichtigkeit heraus zu finden ob es eine XEN etc. Umgebung ist. Wie wir Joe_user entnehmen dann nur noch eine Fleissaufgabe daraus aus zu brechen und die firewall ab zu schalten.

Eben, es ist eine Fleissaufgabe und meiner Meinung nach besser als keine Aufgabe. There is always a way in... aber man kann es versuchen so schwer wie möglich zu machen.
Bei meinem Sicherheitskonzept habe ich mich damals an einem Konzept von einem Bekannten gehalten der das ganze mit BSD und "Jails"?¿ umgesetzt hat, nachdem er mir gezeigt hat wie schnell er auf meinem Server einbrechen und meinen ssh-key auskommentieren konnte -.-
Das letzte mal als bei mir ein penetration-test gemacht wurde habe ich nach nur 2 min eine Mail im Kasten gehabt die mir Unregelmäßigkeiten gemeldet hat... (btw: sooo viele Falschmeldungen bekomme ich garnicht und ja... das kann man umgehen wenn man weiß welche Systeme was analysieren und bei welchen schwellen diese Systeme Meldung machen... aber das muss man als Angreifer immerhin als Vorwissen mitbringen................... (jaja Sec. by. Obs. aber irgendwie kommt man ja immer an dem Punkt an ;)))

um aber auf das Original Posting zurück zu kommen. fail2ban ist zwar eine gute Idee, aber nach einem kleinen Test gestern Nacht hat es sich als sinnfrei erwiesen, da nachdem die IP von dem einen gebannt war nach ca. 2 min. eine andere IP (Hostname (fast)gleich nur andere Nr. hinten) weiter rumprobiert hat... Also wird die LOG Datei dadurch auch nur bedingt leerer und man kauft sich damit auch noch ein paar Gefahren ein... Falls nicht demnächst KI in die Software/Server eingebaut wird muss man sich auf mit vollen LOGs abfinden ;)

[noobiesoft]

-> Eine grosse Hürde auf zu bauen, bietet keinen Mehrwert an Sicherheit!
Wenn ein Angreifer rein will, kommt er rein. Nutz lieber die Zeit und Energie die Du im Aufbau der Hürde aufwendest dahingehend eine entsprechende forensische Nachuntersuchung, damit Du einen Einbruch beweisen und erkennen kannst. Denn ein Einbruch ist nur eine Frage der Zeit. Und Sicherheit ein stetiger Prozess. Eine "Hürde" auf zu bauen, wobei ein Virtualisierter Rechner nun auch keine hürde mehr ist, und sich mit IP Tables sicher zu fühlen, ein fataler Trugschluss.

Gruss Matthias

mmm... da ist schon was dran...
Aber ich sehe eine höhere Hürde als gutes Mittel um höhere %-Sätze von Leuten scheitern zu lassen... natürlich ist 100% Wunschdenken ;)

OT: Ich wollte meine Energie jetzt eh lieber in das Thema Hochverfügbarkeit und Loadbalancing stecken, aber ich komme noch nicht so richtig auf einen grünen Zweig (bzw. Ich bekomme nicht beides unter einen Hut)... in welches (Sub-)Forum gehören solche Fragen eigentlich?

[Joe User]

Nachtrag: http://www.heise.de/newsticker/meldung/121296

[harv]

Du scheinst leider nur über Halbwissen zu verfügen. Eine Callback (=Rückruf) Shell verbindet sich von sich aus mit dem Angreifer. z.B. auf Port 21,53,80 oder einem high port. Wie soll das eine Firewall verhindern? Könntest natürlich alle ausgehenden Verbindungen blocken. Sonderlich produktiv ist das System dann aber wohl kaum noch.

Hast du schonmal über die Zeile nachgedacht:

Code: Select all

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Ausgehend wird nur erlaubt wenn von außen auf einen erlaubten Port zu einem erlaubten Prozess eine Verbindung besteht, den Rest blockst du und wenn du dir über http deine Patches siehst legst du dir hier noch einen Benutzer an und erlaubst nur dem das aufbauen einer Verbindung von innen:

Code: Select all

-A OUTPUT -p tcp -m tcp -m owner -m state --dport 80 --uid-owner downloaduser --state NEW -j ACCEPT

das gleiche machst du für deinen Nameserver und sorgst dafür das der nur zu von dir ausgesuchten Systemen kontakt aufnimmt (der Rest wird geblockt) und das alle Dienste die DNS brauchen nur deinen internen Nameserver ansprechen.

Wenn du dazu deinem Server noch ein MAC (SELinux, Apparmor und Konsorten) spendierst und das entsprechend dicht machst wird das ganze noch um einiges komplizierter zu knacken.

Ich geb dir recht Firewalls sind kein 100% Schnutz wenn die aber richtig konfigueriert sind, in der Kombination mit einem MAC, dem aktuellen Patchstand deines Systems und den anderen kleinigkeiten wie gute Passwörter usw. wird es um einiges schwerer für den Angreifer und warum sollte ich dem das nicht so schwer wie irgend möglich machen?

Diese Grundsätzliche Diskusion über Firewall ja/nein ist doch bescheuert wenn einige der Meinung sind sie bräuchten das nicht dann lasst sie doch und anders rum genauso. Das ist so als wenn ein Radikalerislamist und der Papst sich um die Glaubensfrage streiten. Fast in jedem Threat den ich hier gelesen habe in dem es um Firewall geht wird die Diskusion von neuem angefangen und das eigendliche Thema damit meistens atakta gelegt.