• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Richtiges absichern eines Webservers

A

alex01

Guten Abend

Dies ist mein erster Beitrag hier, und ich hoffe es ist nicht der einzige... :)

Ausserdem hoffe ich, dass ihr mir hier helfen koennt.

Folgende Probleme habe ich im moment:

Angefangen hat alles das nach mehr als 16 Monaten mein rootserver (1und1) vom Netz genommen wurde, da er anscheinend DoS-Attacken getaetigt hatte. Nun da ich ziemlich viele Projekte auf den Server hatte (und aufgrund meiner Unerfahrenheit) konnte ich nicht herrausfinden wie und wodurch diese stattgefunden haben. Nun eine Neuinitialisierung des Servers dachte ich, dass ich wieder auf der sicheren Seite bin. Nein das war nicht der Fall, denn 12 Stunden spaeter war er wieder vom Netz wegen DoS-Attacken.

So jetzt ist der Server im repair-modus, und ich weiss nicht weiter....

Natuerlich habe ich jetzt einige Fragen...
Wie kann ich die Logfiles finden, um herrauszufinden wodurch der "Angreifer" auf meinen Server gekommen ist?

Wie sichere ich meinen Server am besten ab?
(ich habe den Wiki gelesen, da steht aber keine einzige Anleitung wie ich etwas machen kann...)

Mein Wissensstand bezueglich Serverlinux beschraenkt sich mit herunterladen von Paketen, installieren von Paketen, bearbeiten der php.ini (vi),... also alles eher als Webmaster, statt als Administrator.
Kennt jemand eine Webseite oder HowTo wo ich nicht per google ewig lange ein Grundwissen erlernen kann?


Ich hoffe jemand erbahmt sich meiner und hilft ein klein wenig. (und sagt nicht das ich die Finger davor lassen soll)

mfg
alex01

PS:habe einen openSUSE 10.3 mit Plesk 9 (64 Bit) - Server
 
panamajo

panamajo

alex01 schrieb:
Mein Wissensstand bezueglich Serverlinux beschraenkt sich mit herunterladen von Paketen, installieren von Paketen, bearbeiten der php.ini (vi),... also alles eher als Webmaster, statt als Administrator.
Zum Vergrößern anklicken....
Keine guten Voraussetzungen.

Die erste Frage die zu klären wäre ist ob der Misbrauch des Servers auf Anwendungsebene (etwa durch das Einschleusen von PHP Skripten über unsichere Skripte) oder auf Systemebene geschieht. Wenn letzteres der Fall ist könnte es möglich sein dass der ganze Server korrumpiert ist und dann darf man den Logfiles keinen Glauben schenken.

Mir scheint der andere Fall wahrscheinlicher, da der Server wohl komplett neu aufgesetzt wurde (und hoffentlich alle Upodates vorm Start des Apache eingespielt wurden).
Dann könnte eine Analyse "Welches Programm agiert auf welchem Port" schnell Aufschluss geben.
Code: 
lsof -i
 
OP
A

alex01

Guten Morgen

Habe jetzt folgende "Sicherheitsmasnahmen" ergriffen:

Updates eingespielt
per Plesk ssh-Zugang fuer nur eine IP erlauben
ein Passwort gewaehlt welches aus 10 Zeichen besteht (mit Sonderzeichen und Gross/kleinschreibung)
alle Ports sind dicht (ausser die wichtigsten, die offen sein sollten)

ist das "genug" oder sollte ich noch mehr machen? Wenn ja was koennte ich noch machen?

mfg
alex01
 
S

spoensche

alex01 schrieb:
Guten Morgen
Habe jetzt folgende "Sicherheitsmasnahmen" ergriffen:
Updates eingespielt
per Plesk ssh-Zugang fuer nur eine IP erlauben
ein Passwort gewaehlt welches aus 10 Zeichen besteht (mit Sonderzeichen und Gross/kleinschreibung)
alle Ports sind dicht (ausser die wichtigsten, die offen sein sollten)

ist das "genug" oder sollte ich noch mehr machen? Wenn ja was koennte ich noch machen?
Zum Vergrößern anklicken....

Das ist noch nicht mal eine Grundsicherung.


Poste mal die Ausgabe des Befehls, den Panamajo dir an die Hand gegeben hat.

Root Login per SSH verbieten, stattdessen per SSH als mit einem anderen User einloggen und mit su bzw. sudo als root arbeiten.
Den erlaubten SSH- Zugriff zeitlich beschränken, also z.B. nur in der Zeit von 17.00 Uhr bist 18.00 Uhr erlauben.

Sind alle unnötigen Dienste deaktiviert?
Welche Ports hast du offen?
Woher weisst du, dass alle nicht benötigten Ports geschlossen sind?
Hast du Synflooding- und IP Spoofing Protection aktiviert?
Hast du die Filterregeln für IP Tables so festgelegt: Alles was nicht explizit erlaub ist, ist verboten? (Also alle Pakete per default verwerfen)
Werden unerwünschte Pakete und Anfragen, die dem Angreifer nötige Informationen liefern (OS Detection etc.) verworfen und geloggt?
Werden ausgehende Verbindungen nur nach etablierten Verbindungen (Connection Tracking) und nur von dem Port, den der jeweilige Serverdienst verwendet gestattet und alle anderen neu initierten ausgehende Verbindungen verboten? DNS- Client ist eine Ausnahme.
Laufen die Serverdienste mit eigenem Benutzernamen und Gruppe?
Sind die laufenden Serverdienste richtig konfiguriert?
Sind die Limits(z.B. für die verwendeten Resourcen) eines Nutzer begrenzt?
Wird ein IDS (Intrusion Detection System) für die Intrusion Detection und Prevention eingesezt?



PS:
Warum betreibst du ohne jegliche Grundlagen der System- und Serversicherheit (Absichern des Systems und der Serverdienste , Backupstrategie, wie geht ein Angreifer vor, Sicherheitsmaßnahmen testen, etc.) Rootserver? :???:
 
OP
A

alex01

Guten Morgen

Warum betreibst du ohne jegliche Grundlagen der System- und Serversicherheit (Absichern des Systems und der Serverdienste , Backupstrategie, wie geht ein Angreifer vor, Sicherheitsmaßnahmen testen, etc.) Rootserver?
Zum Vergrößern anklicken....

Nun auch wenn es sich bloed liesst, aber ich lebe seit 20 Jahren mit der Devise "learning by doing" und bin bis jetzt damit recht gut zurechtgekommen.
Leider fehlt mir als Familienvater schlicht die Zeit einen Hochschulabschluss als Administrator zu machen. Ausserdem solange es Foren gibt die immer in die richtige Richtung stupsen funktioniert es relativ gut.

So zurueck zum Topic:
Code: 
lsof -i
Sagt:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd2-pr 4049 root 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 4049 root 4u IPv4 2371994968 TCP *:https (LISTEN)
httpd2-pr 7212 wwwrun 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 7212 wwwrun 4u IPv4 2371994968 TCP *:https (LISTEN)
named 7825 named 20u IPv4 2371747507 UDP s15224167.onlinehome-ser ver.info:domain
named 7825 named 21u IPv4 2371747508 TCP s15224167.onlinehome-ser ver.info:domain (LISTEN)
named 7825 named 22u IPv4 2371747509 UDP s15224167.onlinehome-ser ver.info:domain
named 7825 named 23u IPv4 2371747510 TCP s15224167.onlinehome-ser ver.info:domain (LISTEN)
named 7825 named 24u IPv4 2371747511 UDP *:59876
named 7825 named 25u IPv4 2371747512 TCP s15224167.onlinehome-ser ver.info:953 (LISTEN)
httpsd 8014 root 16u IPv4 2371747843 TCP *:cddbp-alt (LISTEN)
httpsd 8014 root 17u IPv4 2371747844 TCP *:pcsync-https (LISTEN)
httpd2-pr 13612 wwwrun 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 13612 wwwrun 4u IPv4 2371994968 TCP *:https (LISTEN)
sshd 19778 root 3u IPv4 2376418121 TCP s15224167.onlinehome-ser ver.info:ssh->85.124.128.37:csms (ESTABLISHED)
sshd 19791 tina 3u IPv4 2376418121 TCP s15224167.onlinehome-ser ver.info:ssh->85.124.128.37:csms (ESTABLISHED)
sshd 25805 root 3u IPv4 2376388266 TCP *:ssh (LISTEN)
xinetd 26240 root 5u IPv4 2371971371 TCP *:ftp (LISTEN)
xinetd 26240 root 8u IPv4 2371971372 TCP *:poppassd (LISTEN)
xinetd 26240 root 9u IPv4 2371971373 TCP *:smtp (LISTEN)
xinetd 26240 root 10u IPv4 2371971374 TCP *:smtps (LISTEN)
couriertc 26277 root 5u IPv4 2371971419 TCP *:imap (LISTEN)
couriertc 26288 root 5u IPv4 2371971432 TCP *:imaps (LISTEN)
couriertc 26297 root 5u IPv4 2371971445 TCP *:pop3 (LISTEN)
couriertc 26307 root 5u IPv4 2371971458 TCP *:pop3s (LISTEN)
httpsd 28048 psaadm 16u IPv4 2371747843 TCP *:cddbp-alt (LISTEN)
httpsd 28048 psaadm 17u IPv4 2371747844 TCP *:pcsync-https (LISTEN)
httpsd 28050 psaadm 16u IPv4 2371747843 TCP *:cddbp-alt (LISTEN)
httpsd 28050 psaadm 17u IPv4 2371747844 TCP *:pcsync-https (LISTEN)
httpsd 28075 psaadm 16u IPv4 2371747843 TCP *:cddbp-alt (LISTEN)
httpsd 28075 psaadm 17u IPv4 2371747844 TCP *:pcsync-https (LISTEN)
wdcollect 28193 root 7u IPv4 2371974568 TCP s15224167.onlinehome-ser ver.info:epicon (LISTEN)
monit 28201 root 4u IPv4 2371974588 TCP s15224167.onlinehome-ser ver.info:blockade (LISTEN)
httpd2-pr 30228 wwwrun 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 30228 wwwrun 4u IPv4 2371994968 TCP *:https (LISTEN)
httpd2-pr 32298 wwwrun 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 32298 wwwrun 4u IPv4 2371994968 TCP *:https (LISTEN)
httpd2-pr 32704 wwwrun 3u IPv4 2371994966 TCP *:http (LISTEN)
httpd2-pr 32704 wwwrun 4u IPv4 2371994968 TCP *:https (LISTEN)
Zum Vergrößern anklicken....

Und ja ich brauch Plesk, hab zwar schon ispconfig versucht(trotz gelungener Installation hat es ohne Fehlermeldung nicht funktioniert)
SSH hab ich jetzt so gesichert das man nur mit einer IP als normaler Benutzer rein kommt. Ausserdem:
Code: 
MaxStartups 3:30:10
zu iptables find ich bis jetzt keine richtige Hilfestellung (eine Seite wo alles darueber steht) und ueber google sich alles zusammenzusuchen ist nicht nur unbequem sondern unefektiv(jede Seite schwoert ihre Regeln sind die besten) (ohne zu erklaeren was diese Regeln wirklich machen)

Sind die anderen Punkte noch die Grundsicherung, oder scon das "Hardcore"-Linux?

schoenen Tag noch
alex01
 
revealed

revealed

Hallo!

Deine Fragen zu IPTABLES werden hier mit Sicherheit zu deiner Zufriedenheit beantwortet:
http://www.netfilter.org/

Ich hoffe der Link nützt dir etwas. Zur absicherung kann ich dir noch ein Stichwörtchen für deine Suchmaschinen Studien mitgeben.

"hardening".

Gruß,

R

PS.: Kleiner Tipp... lies deine Logfile Ausgabe! Und sichere deinen SSH Zugang!

Womit ich noch gute erfahrungen gesammelt habe: (Möchte ich mit auf den Weg geben... )
- php disable functions
- denyhosts (Schutz vor Dictionary attacks)
- limitipconn mod_ip_count security2 ModSecurity (Apache)
Das für (gegen) DoS attacken und injection usw..

Denyhosts beispielsweise ist insbesondere beispielsweise für SSH interessant. Aber damit kann man sich auch selber aussperren. Damit ist also Vorsicht geboten. Dazu möchtest du dich sicherlich auch über TCP wrapper informieren.

Und du möchtest generell schauen, dass auf deinem ganzen Server alle Dateisystemberechtigungen möglichst "sticky" sind. Also nur die Berechtigungen haben, die Ordner und Dateien Prozesse (Dienste) auch wirklich benötigen.
 
S

spoensche

Ein Root- Server für Learning by Doing ist der falsche Weg. Dafür ist das private Risiko viel zu hoch. Im schlimmsten Fall kein dein Root- Server für weit aus schlimmere Angriffe als DDOS Atacken verwendet werden.
Ich würde dir empfehlen zu hause einen Server aufzusetzen und den für Lernzwecke zu verwenden.
 
K

K4m1K4tz3

Ich weiß nicht in wie weit das hier hinein passt, aber mich würde doch mal interessieren, ob Ihr eine Firewall auf einem Server für angebracht haltet. Schließlich muss man doch keine Ports sperren, hinter denen eh kein Programm lauscht.
 
S

spoensche

K4m1K4tz3 schrieb:
Ich weiß nicht in wie weit das hier hinein passt, aber mich würde doch mal interessieren, ob Ihr eine Firewall auf einem Server für angebracht haltet. Schließlich muss man doch keine Ports sperren, hinter denen eh kein Programm lauscht.
Zum Vergrößern anklicken....

Keine Firewall auf einem Server zu verwenden ist mehr als nur grob fahrlässig, nämlich unverantwortlich.
 
K

K4m1K4tz3

Schön, dass du dazu eine Meinung hast, aber auf mein Argument bist du nicht eingegangen. Würde mich freuen, wenn du das nachholen könntest. Würde mich echt interessieren. ;)
 
S

spoensche

K4m1K4tz3 schrieb:
Schön, dass du dazu eine Meinung hast, aber auf mein Argument bist du nicht eingegangen. Würde mich freuen, wenn du das nachholen könntest. Würde mich echt interessieren.
Zum Vergrößern anklicken....

Gerne doch. :)

Mit den IP- Tables Filterregeln, filterst du z.B. gespoofte Pakete heraus, sorgst dafür, dass unerwünschte initierte Verbindungen (eingehende Verbindungen zu den Ports, wo kein Service aufn Anfragen wartet) erst nicht erarbeitet werden, weil dies unnötige Resourcen verbraucht und somit auch der Verbindungsaufbau zu evtl. vorhandenen Rootkits etc. verhindert wird. Weiterhin wird bei vernünftigen definierten Regeln Angriffsversuche wie z.B. halboffene Verbindungen (TCP) und weitere protokollbasierende Angriffe (ICMP etc.) unterbunden. Durch loggen unerwünschter Verbindungsanfrage und Statefullinspection (inkl. loggen) können Schwachstellen und Angriffe entdeckt werden, die du ohne die Filterreggeln nicht erkennen kannst. Dadurch ist es dir möglich entsprechende Gegenmaßnahmen zu ergreifen und anhand der IP bzw. des IP- Adressbereiches den ISP darauf aufmerksam machen, dass diese zu Angriffen verwendet werden. Weiterhin können und werden die ermittelten Daten zur rechtlichen Verfolgung eingesetzt. Weiterhin können die ermittelten Daten dazu verwendet werden IP- Adressbereiche, die Angriffe durchführen und für ähnliches (Botnetz etc) verwendet werden komplett zu sperren.
Weiterhin wird mit den Filterregeln nicht erwünschter ausgehender Verkehr (z.B. Anfragen von Trojanern, Rootkits an Botnetzserver) unterbunden, was ohne eine Firewall nicht möglich ist.

Das ist nur ein Auszug, der dir zeigt und begründet, weshalb eine Firewall und weitere entsprechenden Maßnahmen zur Absicherung unerlässlich sind.

PS:

Für die Grundsicherung ist auch ein IDS (Intrusion Detection System: Angriffserkennung bzw. Einbruchserkennung) unerlässlich.
 
framp

framp

Moderator
Teammitglied
Spoensche hat sehr gut beschrieben warum immer eine FW aktiv sein muss. Ein weiteres Argument ist, dass es mit iptables möglich ist gehäufte VerbindungsRequests automatisch zu blocken. Eine nicht zu verachtendes Feature :roll:
 
revealed

revealed

Hallo!

Der Beitrag auf dieser Webseite:
http://www.petefreitag.com/item/505.cfm
Geht nochmal mehr auf Apache selber ein.

Dann wollte ich nochmal ein anderes Licht anleuchten:
- Bei Verwendung von PHP sollte dies beispielsweise auch gesichert werden.
Dazu hier auch noch ein interessanter link:
http://aymanh.com/checklist-for-securing-php-configuration

Ich nutze außerdem noch sogenannte Disable Functions. In dem Fall:
(php.ini) disable_functions =
Diese hier habe ich mir beispielsweise im Internet gefunden, seien sinnvoll:
show_source system shell_exec passthru exec popen proc_open

Dann noch bezüglich error reporting. Dieses sollte man auch weitestgehen deaktivieren. Anhand bestimmter Fehlermeldungen könnte ein Nutzer erahnen, wie der Server aufgebaut ist.

Worauf sollte man denn noch so achten? Es wurde ja schon einiges angesprochen...

Gruß,

R
 
Rainer Juhser

Rainer Juhser

Moderator
Teammitglied
Hallo Leute,

Ist ja schön, dass ihr in dem Thread noch so aktiv seid und gute Ratschläge gebt. Ich fürchte nur, das ganze verpufft im luftleeren Raum! Der TE hat nämlich am 11.08.2009, 11:35 zum letzten Mal hier hereingeschaut. :roll:
 
panamajo

panamajo

Rainer Juhser schrieb:
Ist ja schön, dass ihr in dem Thread noch so aktiv seid und gute Ratschläge gebt. Ich fürchte nur, das ganze verpufft im luftleeren Raum! Der TE hat nämlich am 11.08.2009, 11:35 zum letzten Mal hier hereingeschaut. :roll:
Zum Vergrößern anklicken....
Das mag sein, aber trotzdem dürfte das Thema oft genug aufkommen und somit ist die Existenz des Threads durch die IMO qualifizierte Beiträge gerechtfertigt.
Wenn die Beiträge des Forums vom OP nicht rezipiert werden ist das eher dessen Problem, aber idealerweise lesen ja andere mit...
 
S

spacy

Hallo Leute,
bitte füllt dieses Thema weiter mit "leben" und wenn möglich mit Links zu Schritt-für-Schritt-Anleitungen. :D danke euch schon mal
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben