Server im Internet

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.

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?

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.

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.

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.

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?

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>

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.

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?

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 :)