Firewall per Plesk administrieren?

delta544

Member
Hallo,

ich habe einen vServer Ubuntu 12.04 mit PLESK bei Webtropia. Diesen sichere ich derzeit mit Fail2Ban gegen Fehlerhafte Loginversuche ab.

Das funktioniert derzeit eigentlich auch sehr gut. Aber ich möchte ein wenig mehr tun. Ich nutze diesen Linux Server primär um mich selbst fit in der Administration von Linux Servern zu machen.

Momentan würde ich gerne die Firwallregeln ein wenig verbessern.
Leider weiss ich nicht ob ich dafür PLESK oder das ZKM oder die Console dafür verwenden soll.

Darf ich die Firewall überhaupt über die Konsole verwalten? Oder könnte das Stress mit PLESK geben?

MfG,
delta544
 
Mit Konsole wirst Du vermutlich iptables meinen? Die fallen in diesem Fall aus, da es keine KVM Virtualisierung, sondern ein Container ist.
Du kannst die Regeln direkt über das Webinterface von Webtropia festlegen oder über Plesk, bzw. über das Admininterface des Containers.
 
Mit Konsole wirst Du vermutlich iptables meinen? Die fallen in diesem Fall aus, da es keine KVM Virtualisierung, sondern ein Container ist.
Du kannst die Regeln direkt über das Webinterface von Webtropia festlegen oder über Plesk, bzw. über das Admininterface des Containers.

Hallo Marentis,

mit Konsole meinte ich eine Kommando Shell (bash). Die Firewall ist, wie du schon korrekt erkannt hast, iptables.

Am liebsten wäre es mir wenn ich erstmal alle Verbindungen verbieten könnte und nur noch die benötigten Dienste (SSH, Mail, Web etc.) zulassen könnte.
Ausserdem würde ich gerne bestimmte IP-Addressen sperren können. Derzeit versucht zum Beispiel ein Server von Strato ständig eine SSH Verbindung aufzubauen und wird nach 3 Versuchen von Fail2Ban geblockt. Das ist ein wenig nervig, weil es das Log zumüllt.

gruss,
delta544
 
Sollte an sich keine Probleme mit Plesk aber:

du kannst auch einfach das Modul Firewall in Plesk installieren (über den Autoinstaller) und dort deine Einstellungen vornehmen. Plesk legt dann iptables Regeln entsprechend an.

Daher sollte es keine Probleme geben
 
Mit Konsole wirst Du vermutlich iptables meinen? Die fallen in diesem Fall aus, da es keine KVM Virtualisierung, sondern ein Container ist.
Du kannst die Regeln direkt über das Webinterface von Webtropia festlegen oder über Plesk, bzw. über das Admininterface des Containers.

Das ist so nicht korrekt, OpenVZ kann sehr wohl mit iptables umgehen.
 
Sollte an sich keine Probleme mit Plesk aber:

du kannst auch einfach das Modul Firewall in Plesk installieren (über den Autoinstaller) und dort deine Einstellungen vornehmen. Plesk legt dann iptables Regeln entsprechend an.

Daher sollte es keine Probleme geben

Hallo JaEgErmEistEr

Ja, seht ihr,da geht es schon los. Ich habe via das Kundeninterface von Webtropia die Firewall aktiviert.

Jetzt guck ich gerade in bei PLESK auf die Weboberfläche und PLESK 'weiss' nur das die Firewall an ist, sieht aber keine Regeln. Ein 'iptables -L' auf der Konsole zeigt aber sehr wohl Regeln.

Über das Kundeninterface (also nicht PLESK) kann man aber leider keine Deny Regeln definieren.

Ich werd mal sehen ob ich die Firwall erst mal wieder per Kundeninterface abschalte und dann via PLESK wieder anschalte. Hoffentlich kriegen die sich nicht in die Haare.

gruss,
delta544
 
Das ist so nicht korrekt, OpenVZ kann sehr wohl mit iptables umgehen.

Seit wann das? Ich dachte immer, dass dafür Skripte von Seiten des Hosters notwendig sind, respektive Kernelmodule erst geladen werden müssen? Aber gut, wieder was gelernt. Danke Dir.
 
Last edited by a moderator:
Seit wann das? Ich dachte immer, dass dafür Skripte von Seiten des Hosters notwendig sind, respektive Kernelmodule erst geladen werden müssen? Aber gut, wieder was gelernt. Danke Dir.

Per default kann OpenVZ Iptables, eventuell gibt es ja Provider welche die Kernel Module hierfür deaktivieren.

Linux vServer z.B. kann kein Iptables, was hingegen aber auch wieder ähnlich jails totaler Mist ist.
 
Am liebsten wäre es mir wenn ich erstmal alle Verbindungen verbieten könnte und nur noch die benötigten Dienste (SSH, Mail, Web etc.) zulassen könnte.
Zu einem Port, auf dem kein Dienst lauscht, kann auch keine Verbindung hergestellt werden. Es macht also auch keinen Sinn, den Port zu sperren.

Mach alle nicht benötigten Dienste aus. Damit behandelst du die Ursachen und nicht die Symptome.

Ausserdem würde ich gerne bestimmte IP-Addressen sperren können. Derzeit versucht zum Beispiel ein Server von Strato ständig eine SSH Verbindung aufzubauen und wird nach 3 Versuchen von Fail2Ban geblockt.
Wozu dann noch einen Paketfilter? Der Angreifer wird doch bereits gesperrt?
 
Hallo SvenR und Pappabaer,

vielen Dank für eure Kommentare. Wie bereits erwähnt versuche ich gerade im 'Selbstversuch' zu lernen wie man einen Linux Server 'richtig' administriert.

Wie SvenR schon geschrieben hat, versuche ich gerade das Fail2Ban log übersichtilich zu halten und diese permanenten Versuche gleich von vornherein zu unterbinden. Denn Fail2Ban setzt ja keine dauerhaften iptable Regeln, sondern löscht diese nach einem vorher bestimmten Zeitraum.

Der Einwand von Pappabaer ist in sofern schon berechtigt und wenn der 'Angreifer' es nur ein paar mal probiert hätte, wäre ich mit dem temporären Blocken ja auch zufrieden, aber wenn ein und der selbe 'Angreifer' es 50~60 mal probiert, dann ist irgendwann ja auch mal Schluss mit Lustig.

Ach so, nach meiner Ansicht laufen nur die wirklich benötigten Dienste, ich dachte nur es wäre besser von vornherein alles zu blocken und nur das frei zu geben was gebraucht wird, so kann man auch nichts vergessen, oder?

Ich habe mittlerweile die Firewall Administration 'direkt' an PLESK übergeben (also über meine Plesk Weboberfläche), da das Kundeninterface von Webtropia einfach keine Möglichkeit bot IP´s direkt zu blocken.

Ich schätze ich werde mich noch intensiver mit iptables auseinander setzen müssen.

An alle anderen Mitschreiber, vielen dank für eure Antworten, ist immer gut den ein oder anderen Gedanken von jemand andern zu hören um neue Impulse zu bekommen, ich denke auch die 'Mitleser' konnten dieser Diskussion etwas abgewinnen.

MfG,
delta544
 
Last edited by a moderator:
Halte dir im Hinterkopf, dass du mit egal welcher Administrationsoberfläche niemals den vollen Umfang einer Software ausnutzen kannst. Es macht daher in jedem Fall Sinn, wie du selber schon erkannt hast, dich mit iptables intensiver zu beschäftigen.
 
Ich glaube Dein Ansatz, delta544, mit permanenten Block von IP-Adressen geht in der Praxis fehl, mal ganz abgesehen vom manuellen Aufwand. Ich zeige Dir mal ein Beispiel warum. Im folgenden siehst du einen block-Report, wie er von lfd automatisch generiert wurde. lfd tut in etwa ähnliches wie Fail2Ban.

lfd on ksXXXXXX.k​imsufi.com​: 95.91.xxx.xxx (DE/German​y/95-91-xxx​-xxx-dynip​.superkabe​l.de) blocked for port scanning

Time: Wed Feb 13 15:17:02 2013 +0100
IP: 95.91.xxx.xxx (DE/Germany/95-91-xxx-xxx-dynip.superkabel.de)
Hits: 11
Blocked: Temporary Block

Sample of block hits:
Feb 13 15:15:49 ksXXXXXX kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:1c:c0:65:1a:24:00:0a:b7:f3:22:01:08:00 SRC=95.91.xxx.xxx DST=91.121.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=40865 PROTO=TCP SPT=60385 DPT=41144 WINDOW=65535 RES=0x00 SYN URGP=0
Die Problematik hier ist, dass es offensichtlich ein dynamischer Internet-Zugang ist (hier zwar KDG - könnte aber auch Telekom whatever sein). Bei den Telcos werden die IP-Adressen dynamisch vergeben. Also kann jederzeit ein ganz anderer PC hinter der IP sein. Oder Du sperrst den Proxy eines Mobilfunk-Providers für immer - auch nicht gerade smart.

Wenn du jetzt anfängst IP-Adressen zunehmend permanent auszuschließen, wächst a) der Datenberg an und damit der Verwaltungsaufwand und irgendwann wird auch bei zu vielen Rules die Netzwerkperformance beeinträchtigt und b) du blockiert u.U. "unschuldige" Besucher - nicht so clever und c) kannst Du davon ausgehen, dass Du mehrmals am Tag von diversen Bots "besucht" wirst.

Wie willst Du das vom Aufwand her händeln? Es hat also seinen Grund, warum man primär nur temporäre Blocks einsetzt. Harte Regeln sind eher was für den worst case also massiver direkter Angriff, die man zurücknimmt, wenn das Drama wieder abflaut.

Es macht keinen Sinn, das log "sauber" halten zu wollen, weil dann verlierst Du ja gerade eben wichtige Informationen, ob es jemand dauerhaft auf Deinen Server abgesehen hat. F2B, lfd und Konsorten sind ein zweischneidiges Schwert und keinesfalls ein Allheilmittel. Ein Brute-force-Versuch auf SSH oder FTP usw., der zig Verbindungen gleichzeitig öffnet, kann für kleine Maschinen ein Problem sein, obwohl wenn sicher konfiguriert eigentlich kein Risiko besteht, kommt es dann oft zu einem deutlichen Performanceeinbruch, da die Dienste die Anfragen dennoch abwickeln müssen.

F2B, lfd und Co. unterbrechen sowas bezeiten. Soweit so gut. Allerdings sollte man deren Verhalten gut beobachten und vorsichtig mit den Einstellungen sein. Im worst case haben diese Tools "großartiges" Backfire-Potential, d.h. die Maschine sperrt sich selber aus.
 
Last edited by a moderator:
b) du blockiert u.U. "unschuldige" Besucher - nicht so clever

Man sollte auch die Möglichkeit, beim sperren von solchen dynamischen IPs, dass man sich selbst sperrt nicht ausser Acht lassen. :)
Wer weiß schon ob man nicht eine solche "Spammer"-Adresse mal selbst zugewiesen bekommt.
 
Hallo TerraX und karaktaka,

vielen Dank für eure Denkanstösse die mit Sicherheit berechtigt sind. Da ich euch den Zweck meines kleinen vServers nicht näher erklärt habe sind eure Einwendungen natürlich nachvollziehbar.

Um mal ein wenig Licht ins Dunkle zu bringen:
Der Server wird ausschließlich von mir verwendet und soll aussließlich als 'Exchange' Ersatz laufen. Deshalb ist nur Zarafa darauf installiert, sonst nichts. Es ist also nicht weiter tragisch, wenn andere den Server nicht mehr erreichen :-D

Der Plan ist: Ich will dort Zentral meinen Mailverkehr, Termine und Kontakte verwalten.

Deshalb sperre ich in aller Regel komplette Netzwerke, sofern sie aus dem Ausland sind. Die Chance das ich aus China oder Russland oder Afrika mal auf meinen Server zugreife ist relativ gering, deswegen ist der Verwaltungsaufwand eher vernachlässigbar. Und ich mache das nur dann, wenn der Angreifer einfach keine Ruhe gibt.

Wenn das nur ein, zwei mal passiert interessiert es mich nicht, wenn das allerdings 20~30 mal passiert, dann mach ich das schon und richte eine dauerhafte 'Reject' Regel in iptables für dieses Netzwerk ein.

gruss,
delta544
 
...Der Server wird ausschließlich von mir verwendet und soll aussließlich als 'Exchange' Ersatz laufen. Deshalb ist nur Zarafa darauf installiert, sonst nichts.
Warum schießt Du eigentlich mit Kanonen auf Spatzen? Nimm Dir doch gleich ein Exchange Hosting? Ist für einen überchaubaren Betrag zu haben und sicherlich günstiger sowie erheblich stressfreier. Es gibt diverse Anbieter am Markt, Microsoft eingeschlossen (http://www.microsoft.com/exchange/en-us/exchange-online-hosted-email.aspx).
 
Warum schießt Du eigentlich mit Kanonen auf Spatzen? Nimm Dir doch gleich ein Exchange Hosting? Ist für einen überchaubaren Betrag zu haben und sicherlich günstiger sowie erheblich stressfreier. Es gibt diverse Anbieter am Markt, Microsoft eingeschlossen (http://www.microsoft.com/exchange/en-us/exchange-online-hosted-email.aspx).

Hallo Terrax,

ich schiesse mit Kanonen auf Spatzen weil ich gerne Kontrolle über meine Daten habe. Und 9€ sind akzeptabel für ein vServer.

Ich weiss ich könnte mir bei einigen Hostern etwas (relativ) günstiges mieten, aber der Sinn und Zweck dieser Übung ist ja auch zu lernen wie man ein Linux Server richtig administriert. Das geht dann wahrscheinlich auch Stressfreier beim Hoster, aber ich weiss dann nur das es funktioniert, aber nicht wieso oder warum gerade etwas passiert / nicht passiert.

Ich bin MCSE und habe die LPI1 aber gerade im Linux Bereich, der mich besonders reizt, hab ich immer nur am Rande zu tun und sich ein System auf eine Virtuelle Maschine zu packen ist etwas anderes als es 'draussen' stehen zu haben.

Hol ich mir dabei 'Blaue Flecken'? Ja, klar, aber solange ich mir ein Verständniss dafür aneignen kann was gerade passiert und wie ich das 'richtig' in den Griff bekomme, ist das auch vollkommen in Ordnung. Und 'richtige Probleme' entstehen nun mal im richtigen Leben und nicht auf ner VM.

gruss,
delta544
 
Hol ich mir dabei 'Blaue Flecken'? Ja, klar, aber solange ich mir ein Verständniss dafür aneignen kann was gerade passiert und wie ich das 'richtig' in den Griff bekomme, ist das auch vollkommen in Ordnung. Und 'richtige Probleme' entstehen nun mal im richtigen Leben und nicht auf ner VM.

Richtige Probleme kannst du auch in einer VM haben, bzw die dort sogar simulieren. Wenn du bspw. einen Webserver in einer VM hochziehst, der dir zu Hause gecachte Inhalte deiner Lieblingswebseiten anzeigt oder du dort deinen lokalen Mailserver für zu Hause betreibst. Es gibt einiges an Möglichkeiten, wie man zu Hause weit ab vom "großen" Internet den Umgang mit Linux erlernen kann.
 
Ah oki - die Motivation dahinter war bisher so nicht klar zu erkennen. Also ich fasse zusammen a) Datenschutz und -kontrolle sowie b) Hobby und Herausforderung. Soweit richtig?

Lass mich einen Vorschlag machen:

So wie ich das sehe, ist die Situation (berücksichtigt man die Infos aus den diversen Threads) atm bei Dir etwas zerfahren. Nichts läuft so richtig wie gewünscht.

Zweitens - der aktuelle vServer von Dir scheint mir persönlich ungeeignet, das mit dem RAM ist nicht kalkulierbar. Wenn Du richtig was zum spielen haben möchtest, nimm einen richtigen dedicated Server. Kein unberechenbares Flexi-RAM und keine Zaungäste, die evtl. Performance klauen sowie Freiheit in jeder Beziehung. Z.B. da gibt es Angebote für kleines Geld (http://www.ovh.de/server/dedicated/value/). Wie auch immer, steig auf einen Server um, wo alle Ressourcen fix garantiert sind.

Und damit kommen wir zum Vorschlag:

Du machst Tabula-rasa und wir machen gemeinsam hier im Forum eine Art "Tagebuch-Projekt" á la "Mein erster Server". Du definierst das Ziel (also Betrieb Exchange Ersatz) und wir unterstützen Dich dabei, wie Du das System aus einer Minimalinstallation heraus aufbaust inkl. der Erörterung möglicher Optionen und ohne Plesk-Geraffel. Nicht falsch verstehen, wir schreiben Dir kein How-to, dafür gibt es schon genügend, wir erleichtern Dir nur die links-oder-rechts-Entscheidung sowie die Abfolge wichtiger Schlüsselpunkte.

Ich glaube so wird das eher was, als das punktuelle Rumgemurkse ;) Und für Dich ist der Vorteil, Du verstehst das System dann, weil Du es selbst aufgebaut hast.
 
Last edited by a moderator:
Back
Top