Hallo. Zu Testzwecken habe ich mir mal einen Server (debian) in einem Rechenzentrum gemietet und folgende Dienste installiert: Apache SMPTd Asterisk Bei "Angriffen" auf diesen schreibe ich die IP in eine Datei und via iptables ein DROP. Im Moment kommen gute 10 Stück jeden Tag dazu. Das Ganze läuft jetzt seit 2 Wochen. Bei Apache schaue ich nach 404 Aufrufen (also Skripten die zB nach verwundbaren php Skripten suchen) Bei SMPTd alle Verbdindungsversuche (meist mit AUTH) - der Sever hat keinen MX bzw DNS Eintrag - Angriffe nur via IP. Bei Asterisk wird meist nach Accounts gescannt usw. Ich hätte gedacht die IPs kommen aus den "üblichen verdächtigen" Ländern aber sind bunt gemischt. Man erkennt aber immer ganze Subnetze die da Unsinn machen. Ganz interessant sind Angriffe auf smpt seit einigen Tagen. Damit keine Filter zuschlagen, kommen dort die Loginversuche einer nach dem anderen von unterschieldlichen IPs. Da muss wohl ein Botnetz am Werke sein. Wie sind eure Erfahrungen? Martin
Martin schrieb: en. > > Ganz interessant sind Angriffe auf smpt seit einigen Tagen. Damit keine > Filter zuschlagen, kommen dort die Loginversuche einer nach dem anderen > von unterschieldlichen IPs. Da muss wohl ein Botnetz am Werke sein. > > Wie sind eure Erfahrungen? > > Martin Jup ist recht gängig, bei den "Deutschen" IPs schaue ich hin und wieder mal was da hinter ist, von Router bis irgendeine Industrie HW findet man eigentlich alles, scheint Mode geworden seinen Nackten Arsch ins Internet zu hängen. Hab bei mir Fail2Ban laufen nach 5 Login versuchen gibt es nen 12h ban, damit erledigt sich das recht oft gibt nur wenige die es danach nochmal versuchen
Du hast SSH nicht aufgeführt. Darauf wird zumindest nach meiner Erfahrung am meisten gescannt. Sind vielleicht so 10 IPs am Tag die da bei mir deswegen geblockt werden. Gibt wohl leider genug "Admins", die Passwörter wie "qwertz123" oder so ähnlich verwenden und bei denen die dann Erfolg haben.
Hallo. SSH lege ich seit Jahren auf einen anderen Port - damit ist da erstmal Ruhe. Martin
Martin schrieb: > Hallo. > > SSH lege ich seit Jahren auf einen anderen Port - damit ist da erstmal > Ruhe. > > Martin Ist eine Möglichkeit. Wenn's wirklich "sicher" werden soll braucht's aber ein Dreigestirn: - Firewall - IDS - Webserver Und wenn man schon PHP und SQL nehmen will alles einzeln in chroot und noch extra VM, z.B. jail bei BSD.
Anderer Port bringt nicht wirklich mehr Sicherheit aber die automatisierten abfragen kann man damit schon mal verhindern. Man sollte am besten Passwort Login abschalten und direkt auf keyfiles setzen. Das sollte eigentlich immer sicherer sein.
keinehanung schrieb: > Martin schrieb: >> Hallo. >> >> SSH lege ich seit Jahren auf einen anderen Port - damit ist da erstmal >> Ruhe. >> >> Martin > > Ist eine Möglichkeit. > Wenn's wirklich "sicher" werden soll braucht's aber ein Dreigestirn: > - Firewall > - IDS > - Webserver > Und wenn man schon PHP und SQL nehmen will alles einzeln in chroot und > noch extra VM, z.B. jail bei BSD. Ne Firewall brauchts nur wenn Dienste auf offen zugänglichen Interfaces laufen die nicht offen zugänglich sind, sonnst gewinnst du nichts. Nen gescheites IDS hilft viel, ist nur leider nicht trivial einzurichten. Chroot ist nicht für Sicherheit gemacht, das ist nur ne kleine Hürde. Was bringt es die Datenbank für die Webanwendung von der Webanwendung zu trennen?
Dirk D. schrieb: > keinehanung schrieb: >> Martin schrieb: >>> Hallo. >>> >>> SSH lege ich seit Jahren auf einen anderen Port - damit ist da erstmal >>> Ruhe. >>> >>> Martin >> >> Ist eine Möglichkeit. >> Wenn's wirklich "sicher" werden soll braucht's aber ein Dreigestirn: >> - Firewall >> - IDS >> - Webserver >> Und wenn man schon PHP und SQL nehmen will alles einzeln in chroot und >> noch extra VM, z.B. jail bei BSD. > > Ne Firewall brauchts nur wenn Dienste auf offen zugänglichen Interfaces > laufen die nicht offen zugänglich sind, sonnst gewinnst du nichts. > > Nen gescheites IDS hilft viel, ist nur leider nicht trivial > einzurichten. > > Chroot ist nicht für Sicherheit gemacht, das ist nur ne kleine Hürde. > > Was bringt es die Datenbank für die Webanwendung von der Webanwendung zu > trennen? Drei Rechner, einen für Firewall, einen für IDS und einen der das WWW bedient. Chroot bedeutet das wenn z.B. die SQL Datenbank gehimmelt wird man nicht auf den Rechner/OS selber Zugriff bekommt. Und nein auf einem Rechner kann man das so aufsetzen das sich die Datenbank und der Webserver mit PHP sehen und austauschen können, ohne das das von außen erkannt werden kann. Reines HTML ohne CMS/wordpress/&o.ä. ist immer am sichersten, da dann keine Einfallstüren vorhanden sind. Das ein IDS aka Honeypot nicht so einfach sind ist klar. Richtig "sicher" bekommt man's nur via VPN und Rechner als Client der nicht kompromittiert ist. Nur dann sind nur Leute mit dem VPN&Co. sehend ;-)
keinehanung schrieb: > Dirk D. schrieb: >> keinehanung schrieb: >>> Martin schrieb: >>>> Hallo. >>>> >>>> SSH lege ich seit Jahren auf einen anderen Port - damit ist da erstmal >>>> Ruhe. >>>> >>>> Martin >>> >>> Ist eine Möglichkeit. >>> Wenn's wirklich "sicher" werden soll braucht's aber ein Dreigestirn: >>> - Firewall >>> - IDS >>> - Webserver >>> Und wenn man schon PHP und SQL nehmen will alles einzeln in chroot und >>> noch extra VM, z.B. jail bei BSD. >> >> Ne Firewall brauchts nur wenn Dienste auf offen zugänglichen Interfaces >> laufen die nicht offen zugänglich sind, sonnst gewinnst du nichts. >> >> Nen gescheites IDS hilft viel, ist nur leider nicht trivial >> einzurichten. >> >> Chroot ist nicht für Sicherheit gemacht, das ist nur ne kleine Hürde. >> >> Was bringt es die Datenbank für die Webanwendung von der Webanwendung zu >> trennen? > > Drei Rechner, einen für Firewall, einen für IDS und einen der das WWW > bedient. > Chroot bedeutet das wenn z.B. die SQL Datenbank gehimmelt wird man nicht > auf den Rechner/OS selber Zugriff bekommt. > Und nein auf einem Rechner kann man das so aufsetzen das sich die > Datenbank und der Webserver mit PHP sehen und austauschen können, ohne > das das von außen erkannt werden kann. > Reines HTML ohne CMS/wordpress/&o.ä. ist immer am sichersten, da dann > keine Einfallstüren vorhanden sind. > Das ein IDS aka Honeypot nicht so einfach sind ist klar. > Richtig "sicher" bekommt man's nur via VPN und Rechner als Client der > nicht kompromittiert ist. > Nur dann sind nur Leute mit dem VPN&Co. sehend ;-) Ach du willst das tatsächlich physikalisch trennen? das wird aber nen kostspieliges unterfangen für ne kleine hobby-webseite :) Was nen chroot ist weiß ich, und ich weiß auch das ein chroot kein Sicherheits-Feature ist. Nen IDS und nen Honeypot sind aber auch eher unterschiedliche Dinge, Das erstere hilft dir Angriffe auf dein System zu erkennen, sei es ein IDS das nur von aussen den Traffic mitliest, welches dann deine Anwendung als solche verstehen muss, oder ein IDS das auf Dateisystem und oder Datenbank-ebene Arbeitet und einfach Feststellt das sich Dateien die sich nicht ändern sollen Verändert haben, oder Zeilen / Spalten die sich geändert haben, oder keywords enthalten die nicht da sein sollten. Nen Honeypot hingegen dokumentiert mögliche Angriffsszenarien. ... Aber wofür brauch ich beim Klassischen LAMP-Stack, wobei ich eher LNMP bevorzuge, eine Firewall? Auf so einer Kiste habe ich ein ssh-server. Der muss von außen erreichbar sein. Ich habe einen Webserver. Auch der soll von außen erreichbar sein. Ich habe ne Mysql, die bindet per Default nur an nen Unix-Socket oder an nen Loopback-Device. Da hilft mir keine Firewall. Dann hab ich evtl noch nen php-fpm, oder nen fcgi Runner wenn ich nicht Apache mit mod-php verwende. Die bindet man nicht an öffentliche Interfaces. Wo hilft mir jetzt die Firewall? Noch zu der Sache mit dem verschobenen Port für ssh: Das schützt einen vor Scriptkiddies die versuchen sich mit gängigen Passwörtern einzuloggen. Wenn man den Port jetzt verschiebt löst man nicht das Problem das man ein einfaches Passwort hat, oder überhaupt das man sich mit Passwort authentifiziert. Das einzige "Problem" das man lößt sind Einträge in der auth.log. Login nur mit keypar und kein login als root lösen das Problem.
Hallo. Ja neben einem anderen Port für ssh verwendet ich grundsätzlich nur login via key. Aber wie macht ihr es zB bei einem Apache? Bei Asterisk kann ich ja auf eine whiteliste setzen da ich ungefähr weiss woher meine Clients kommen. Aber bei einem Apache der eigentlich von "jedem" (jedenfalls von jedem der zB keinen Scan anstellt) erreichabr sein sollte? Wie machen es da Banken oder zB hier das Forum? Gibt es IP Sperrlisten die man immer einsetzten sollte? Spamhaus DROP nutzen? Martin
Ein Apache oder andere Gänige Webserver muss man nicht als Sicherheitsproblem betrachten, "nur" die aktiven anwendungen die er ausliefert. Du kannst sowas wie Fail2Ban nutzen, angriffsversuche erkennen und denjenigen auf ip-ebene Sperren. Du musst dann nur hoffen das derjenige sich seine ip-adresse nicht mit anderen teilt die du eigentlich nicht aussperren willst. Neue Anschlüsse bei Unitimeda, oder die Meisten Mobilfunk zugänge haben keine eigene öffentliche ip-adresse, da wird beim Provider nat verwendet, du würdest also ggf. tausende "Nachbarn" mit aussperren. Effektiv bleibt dir eigentlich nur dafür zu sorgen das deine Anwendung sicher ist und dafür zu sorgen das, im falle eines Einbruchs durch die Anwendung, möglichst wenig in Mitleidenschaft gezogen wird. Also deine Anwendungen von einander trennen, Passwörter sicher hashen oder ggf. via OAuth die komplett auf Passwörter verzicheten, möglichst wenig Daten über deine Benutzer vorhalten.
Wer mit LAMP ohne explizite Firewall ins Netz geht begeht "Selbstmord". Und es war ja die Frage nach "sicher", da kommt man nicht um eine externe Firewall herum und wenn's ein gestellter Router ist mit z.B. OpenWRT umrüsten. Das wäre dann SoHo-WWW :-P Da er ja einen Rechner gemietet hat stellt sich die Frage ob virtuell oder physikalisch. Der Hoster sollte ja selber mit Firewall und IDS unterwegs sein. Kommt halt auf den Vertrag an. Hatte mal den Fall das sich Kunde wegen dem extrem hohen Traffic beschwerte, der hatte sich einen chroot auf Linux eingefangen wo warez via FTP angeboten wurden. Das hat der Kunde nicht erkannt, woran das wohl gelegen hat ? Wenn alles im chroot läuft kann "nur" die Datenbank oder Webserver alleine gecrackt werden, das System bleibt "versteckt". Außer natürlich User loggt sich via Telnet und 12345qwertz als root ein :-P
Hallo. Es ist ein viruteller Host. Gibt es Anbieter die eine Firewall anbieten? Welche? Gerade im vHost Bereich habe ich noch keinen gesehen. Traffic ist auch so ein Stichwort: zwar hat der Server eine 100MBit Anbindung aber mit was berechnet man diesen "Geistertraffic"? Wie sieht es bei DSL Anschlüssen aus? Oder wird da weniger gescannt wegen der wechselnden IPs? Martin
keinehanung schrieb: > Wer mit LAMP ohne explizite Firewall ins Netz geht begeht "Selbstmord". Wie schützt mich eine wirewall wenn ich ein lamp stack so wie beschrieben konfiguriere? ich habe nur 22, 80 und 443 nach aussen offen, die müssen von der firewall durchgereicht werden. Wo ist der gewinn?
Wenn man sich eine virtuellen Server gemietet hat, muss man sich nicht drum kuemmern. Solange man nur ueber HTTP drauf zugreift ist alles im Gruenen, fuer den Adminzugriff bieten die den Rahmen per Weboberflaeche. Und fuer SSH auch. Dh man muss nur noch beim PHP aufpassen.
Meiner Erfahrung nach ist das alles überflüssig für so einen kleinen Privatserver. Konfigurier' halt deine Services richtig, schalte die ab die du nicht brauchst, erlaube nur Public Key Authentication in ssh und gut ist.
Dirk D. schrieb: > keinehanung schrieb: >> Wer mit LAMP ohne explizite Firewall ins Netz geht begeht "Selbstmord". > > Wie schützt mich eine wirewall wenn ich ein lamp stack so wie > beschrieben konfiguriere? > > ich habe nur 22, 80 und 443 nach aussen offen, die müssen von der > firewall durchgereicht werden. > Wo ist der gewinn? Ja und ? Dein PHP, Deine Datenbank und Dein Apache sind auf dem aktuellsten Stand ? Gibt's da noch offenen Baustellen ? Was ist mit SQL-Insertion usw. usf. ? Daher extra Firewall und IDS die das erkennen können. 100%ige Sicherheit gibt's im WWW nicht, man kann nur die offensichtlichen Schwachstellen überwachen. Und mit den OpenSSL Exploits ist ssh&co. auch nicht mehr wirklich sicher, auch wenn man den Port umsetzt.
keinehanung schrieb: > Und mit den OpenSSL Exploits ist ssh&co. auch nicht mehr wirklich > sicher, auch wenn man den Port umsetzt. Welcher der zuletzt bekannt gravierenden geworden OpenSSL-Exploits betrifft denn OpenSSH?
Sven B. schrieb: > keinehanung schrieb: >> Und mit den OpenSSL Exploits ist ssh&co. auch nicht mehr wirklich >> sicher, auch wenn man den Port umsetzt. > > Welcher der zuletzt bekannt gravierenden geworden OpenSSL-Exploits > betrifft denn OpenSSH? Worauf basiert denn SSH, TLS, HTTPS usw. usf. ? Es wird immer Exploits geben solange man nicht z.B. komplett auf reines Havard umstellt da gibt's dann keinen Overflow oder NOPs die dann Schadcode ausführen lassen. Läuft dann halt kein FPS in HD drauf ;-)
keinehanung schrieb: > Sven B. schrieb: >> keinehanung schrieb: >>> Und mit den OpenSSL Exploits ist ssh&co. auch nicht mehr wirklich >>> sicher, auch wenn man den Port umsetzt. >> >> Welcher der zuletzt bekannt gravierenden geworden OpenSSL-Exploits >> betrifft denn OpenSSH? > > Worauf basiert denn SSH, TLS, HTTPS usw. usf. ? SSH benutzt Teile von OpenSSL. Aber nur einen relativ kleinen Teil. Zum Beispiel nicht das ganze Zertifikat-Zeug. Sowas wie Heartbleed hat mit OpenSSH zum Beispiel nichts zu tun. > Es wird immer Exploits geben Ach ne. > solange man nicht z.B. komplett auf reines > Havard umstellt da gibt's dann keinen Overflow oder NOPs die dann > Schadcode ausführen lassen. Klar, wenn wir $sprache auf $architektur benutzen würden, gäbe es keine Bugs. </fact>
Sven B. schrieb: >> solange man nicht z.B. komplett auf reines >> Havard umstellt da gibt's dann keinen Overflow oder NOPs die dann >> Schadcode ausführen lassen. > Klar, wenn wir $sprache auf $architektur benutzen würden, gäbe es keine > Bugs. </fact> ok, aber ich denke doch etwas anders darüber. ich baue grade einen neuen compiler mit caramba.
kaihnaahnunga schrieb: > Sven B. schrieb: >>> solange man nicht z.B. komplett auf reines >>> Havard umstellt da gibt's dann keinen Overflow oder NOPs die dann >>> Schadcode ausführen lassen. >> Klar, wenn wir $sprache auf $architektur benutzen würden, gäbe es keine >> Bugs. </fact> > > ok, aber ich denke doch etwas anders darüber. > > ich baue grade einen neuen compiler mit caramba. ROFL Havard und VonNeumann sind aber nicht compilerabhängig ;-) Und Käfer zwischen den Drähten sind nicht mehr das Hauptproblem :-P Wer nicht versteht das es weniger wahrscheinlich ist sich einen "Virus" einzufangen wenn der Programmcode vom Datum physikalisch getrennt ist weiß halt nicht was der Unterschied ist. Wenn ich im gleichen Speicher auf den Opcode stoßen kann und z.B. sogar den PC umbiegen ist das weniger sicher ... Ist aber klar das "Virenscanner" 100% unterbinden das sowas passiert, weil ja der Hash genauso aussieht wie xyz.dll ;-)
Naja, wird eh nicht passieren. Der Browser den du benutzt um diese Seite anzuschauen benutzt wahrscheinlich einen JIT, um das Javascript auszuführen. Zack, geht schon nicht mehr mit strikt getrennten Daten und Code.
keinehanung schrieb: > Dirk D. schrieb: >> keinehanung schrieb: >>> Wer mit LAMP ohne explizite Firewall ins Netz geht begeht "Selbstmord". >> >> Wie schützt mich eine wirewall wenn ich ein lamp stack so wie >> beschrieben konfiguriere? >> >> ich habe nur 22, 80 und 443 nach aussen offen, die müssen von der >> firewall durchgereicht werden. >> Wo ist der gewinn? > > Ja und ? > Dein PHP, Deine Datenbank und Dein Apache sind auf dem aktuellsten Stand > ? Mein Apache ist ein nginx, aber ja, alles aktuell. Aber selbst wenn nicht, wo würde mir eine Firewall helfen? > Gibt's da noch offenen Baustellen ? Nicht das ich wüsste, was nicht heist das es sie nicht gibt. > Was ist mit SQL-Insertion usw. usf. ? Ich nehm an du meinst SQL.Injections. Die Software die ich nutze nutzt ausschliesslich prepared Statements. Aber selbst wenn nicht, was würde eine Firewall da für mich tun? > Daher extra Firewall und IDS die das erkennen können. Was würde da eine Firewall tun? ein IDS ERKENNT nur Angriffe, es schützt davor nicht, wie der name schon sagt. Mit so Sachen wie IDS und IPS ist es aber ähnlich wie mit Virenscannern. Sie schützen oder Erkennen ausgewählte Bedrohungen, sind aber selber für solche anfällig. Jedes Stück Software das Daten von aussen annimmt bringt potentielle Probleme mit sich. > 100%ige Sicherheit gibt's im WWW nicht, man kann nur die > offensichtlichen Schwachstellen überwachen. > Und mit den OpenSSL Exploits ist ssh&co. auch nicht mehr wirklich > sicher, auch wenn man den Port umsetzt. Du scheinst da einem gängigen Fehlschluss zu unterliegen: OpenSSL war schon lange unsicher, wahrscheinlich wurde das auch schon lange ausgenutzt. Jetzt wo es bekannt und gefixt ist ist Openssl SICHERER als vorher, nicht unsicherer.
Virenscanner mit IDS und Firewall zu vergleichen ist nicht "intelligent". Es macht einen Unterschied ob man HASH auf Dateien anwendet und damit "Sicherheit" suggeriert oder ob man wirklich die Verbindung analysiert. Aber wie schon gesagt der ISP wird schon beides anbieten, je nach Vertrag oder allgemein ... Und ob Du nun einen anderen Webserver nimmst als in LAMP bleibt sich auch gleich. Wenn z.B. ein DDOS o.ä. auf Deinem Server auftrifft kannst Du via Firewall die IP-Range sperren, dann können alle die von woanders herkommen noch Deine Seite erreichen. IDS zeigt Dir was gerade versucht wird und kann die Firewall anpassen besser Dich informieren was gerade abläuft. Honeypot zieht die Angriffe auf sich selber da weniger "sicher" und kann dann in Kombination mit IDS und Firewall dazu führen das Du den Angriff und die Angreifer erkennen kannst. Ob Bots oder direkt vom "Nachrichtendienstdeinesvertrauens" bleibt sich gleich. Es wird erkannt und im Fall der Fälle kannst Du den Pöppel ziehen, nachsehen was gemacht wurde und nach einer Daten-Sicherung Deine Kiste wieder neu aufsetzen.
keinehanung schrieb: > Virenscanner mit IDS und Firewall zu vergleichen ist nicht > "intelligent". Ich hab eine Firewall nicht mit einem Virenscanner Verglichen, das ist was ganz anderes. Eine Firewall Sperrt Traffic nach simplen regeln aus, macht das Performant und zuverlässig. Solange ich aber kein simpel klassifizierbaren Traffic habe den ich aussperren will hilft mir das Herzlich wenig. > Es macht einen Unterschied ob man HASH auf Dateien anwendet und damit > "Sicherheit" suggeriert oder ob man wirklich die Verbindung analysiert. Also der eine analysiert Dateien nach bekannten Mustern der Andere Analysiert Traffic nach bekannten Mustern, beide Benutzen dafür Heuristiken und bekannte Angriffe, beide haben mäßige Trefferquoten (ein ids versteht ja in den meisten fällen gar nicht wie die Anwendung tickt und wo da das gefahren potential wäre). Nicht das ich sage das ein Typisches ids / ips nichts findet, aber das was die Dinger finden sind Angriffe auf wirklich schlechte Software. das ist so nen Bisschen wie der Türsteher der verhindert das LEute versuchen meine Haustür einfach aufzudrücken in der Hoffnung das sie nicht ganz ins schloss gefallen ist. > Aber wie schon gesagt der ISP wird schon beides anbieten, je nach > Vertrag oder allgemein ... Ich hab bis jetzt noch keinen Hoster gefunden der Unaufgefordert in den Traffic zum Vermieteten Server eingreift. Entweder man mietet das Explizit mit, dann sind wir aber auch nicht mehr in der Preisklasse die man sich als Privatperson leisten will, oder dem Hoster ist es ziemlich egal was da Passiert, solange bis es ans Eingemacht geht, dann schaltet der Hoster einfach ab. > Und ob Du nun einen anderen Webserver nimmst als in LAMP bleibt sich > auch gleich. Da gibts keine aber feine Unterschiede die in Angrifsscenarien eine rolle Spielen, aber im Groben und Ganzen sind es nicht die Webserver selbst di Angegriffen oder ausgenutzt werden, ja. > Wenn z.B. ein DDOS o.ä. auf Deinem Server auftrifft kannst Du via > Firewall die IP-Range sperren, dann können alle die von woanders > herkommen noch Deine Seite erreichen. Das Stimmt, da macht eine Firewall Sinn, aber nicht auf der kiste selbst, oder auf einer Anderen Kiste im selben Rack, sondern direkt im Router der den eingehenden Traffic routet, nur der kann sowas effizient blockieren in dem er seiner gegenstelle erklärt das Traffic aus den Netzen gar nicht zugestellt werden soll. Sollte ich mit meinem Privatem server Jemals in die Verlegen heit kommen einem DOSS ausgesetzt zu sein dem ich nicht über die Filter in der Webserver-Konfiguration Herr werde werd ich mich vieleicht darum Kömmern, vieleicht werd ich das aber auch aussetzen. Als Selbstmord würde ich das aber nicht Bezeichnen wollen. Was ich Tagsüber im Beruf mache sieht da natürlich anders aus, da geht es aber nicht um Privat-kram, sondern Darum Projekte von Kunden zu hosten. Die Kunden sind ggf. Unternehmen die eher Ziel eines Angriffs werden, und sie haben da ggf. auch eher Probleme mit wenn der Dienst im Falle eines Falles nicht verfügbar ist. Privat habe ich kein Problem damit im Zweifel auszufallen, aber genau so ein Problem damit erfolgreich angegriffen zu werden (in form eines "Einbruchs") > IDS zeigt Dir was gerade versucht wird und kann die Firewall anpassen > besser Dich informieren was gerade abläuft. ein IDS zeigt mir Angriffe auf mein Produktivsystem an DIE ES ERKENNT. An der stelle erschließt sich ein IDS mir nicht. Wenn ich know how über mögliche Angriffs-Szenarien habe, warum sollte ich Energie in deren Erkennung stecken statt die Lücke einfach zu schliessen? > Honeypot zieht die Angriffe auf sich selber da weniger "sicher" und kann > dann in Kombination mit IDS und Firewall dazu führen das Du den Angriff > und die Angreifer erkennen kannst. Ich hab jetzt also eine Kiste die für mich "arbeitet" zusätzlich eine die Firewall macht, eine auf der nen IDS und oder nen IPS läuft und eine mit nem Honeypot. das sind 4 statt einer Kiste. und du meinst das BRAUCHT man für ne Privat-Schüssel? > Ob Bots oder direkt vom "Nachrichtendienstdeinesvertrauens" bleibt sich > gleich. > Es wird erkannt und im Fall der Fälle kannst Du den Pöppel ziehen, > nachsehen was gemacht wurde und nach einer Daten-Sicherung Deine Kiste > wieder neu aufsetzen. Na ich werd wohl kaum nachdem in meine Kiste eingebrochen wurde nen backup machen und das wieder einspielen. wenn ich merke das meine Kiste hops gegangen ist stoppe ich alle dienste, analysiere den Einbruch, erarbeite eine Lösung, reiß die Kiste ab und ziehe sie aus einem Backup wieder hoch von dem ich sicher bin das sauber ist. Warum sollte ich die Kiste neu aufsetzen wenn ich danach die Hintertür die mir da eingebracht wurde wieder mit einspiele?
ROFL Sollte nach "deiner alten Datensicherung" heißen ;-) Also BEVOR das Ding in den Brunnen gefallen ist. Und NEIN Router sind nicht die Wahl als Firewall. Selbst wenn es ein virtueller Server ist dürfte der Anbieter selber eine Firewall davor haben, ob IDS und Honeypot ist fraglich. Bei größeren Hostern gibt`s erstmal die Loadbalancer, dann die Firewall(s) wenn sie hinter denen sind. Sonst umgekehrt oder kombiniert. Ändert immer noch nix an der Tatsache das solange keiner weiß was für ein Server und welcher Hoster man da keine weitere Hilfe geben kann. Und im Gegensatz zu Virenscannern macht eine IDS direkte Analyse, also keine HASHs und Heuristik, die kann man zupacken muß man aber nicht. Ein z.B. ICMP DDOS wird erkannt, Spoofing&Co. muß man passend konfigurieren da hast Du recht. Und der Honeypot wird vor allem BOTS aus dem Verkehr ziehen können.
Okay, dann sind wir uns bei der Datensicherung ja einig :) Na beim DOSS, wenns nicht eine angreifbare Anwendung ist, ist ja das Problem das die Zuleitung einfach überflutet wird. Wenn ich das jetzt mit der Firewall auf meinem Server verwerfe ist die Zuleitung ZU meinem server immer noch zu. Wenn ich jetzt mit selber Anbindung eine Extra ksite als Firewall da hin stelle habe ich das Selbe Problem. Ein DOSS muss man da bekämpfen wo es keinem Wehtut, im Zweifel beim Peering-Partner. Was hilft mir für meinen Einzelnen server ein Load-Balancer? zwischen welchem und meinem Server soll der den Balancen? Ja, genau, nen IDS kann ihm bekannte Angriffe erkennen. Wenn mit angriffe bekannt sind, warum sollte ich meine Anwendung für diese Angreifbar lassen, das erschließt sich mir nicht, da magst du mir anscheinend aber auch keine Auskunft drauf geben :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.