[HaBo]

gelöscht

Anzeige

Hallo,

ich bin am überlegen was ich noch so alles für einen Linux Webserver für ein Intranet alles bedenken / installieren / konfigurieren soll.

Grundlage:
Die Grundlage ist ein "nacktes" Linux Derivat - Debian 5.2.0a Lenny -, also ohne großen Schnick Schnack, wie GUI, etc.

Installierte Programme:
- Apache2 Webserver
- PHP 5.2
- MySQL 5.1
- OpenSSH
- vsFTP
- eAccelerator
- MRTG
- clamAV
- konfigurierte iptables
- zu Testzwecken Joomla

Konfigurationen:
Es sind die meisten Programme so angepasst, dass die Sicherheit gegen Injections, URL-Manipulation, etc. gewährleistet ist. Ein chroot - Verzeichnis existiert ebenso, wie Zugriffsverhinderungen auf administrative Bereiche bzgl. Joomla und MRTG. Genauso sind per FTP nur Zugriffberechtigungen auf das vorgegebene Verzeichnis für das Intranet gesetzt. SSH ist konfiguriert gegen Brute Force Angriffe etc. Compiler sind nach einrichten des gesamten Systems deinstalliert worden, sowie CGI etc. wurden auch deaktiviert.

Was wäre noch möglich?
Das Frage ich euch, was denkt Ihr, was sollte ich noch mit einsetzen um die Sicherheit, Hochverfügbarkeit etc. zu gewährleisten? 100%ige Sicherheit existiert nicht, dass ist mir durchaus bewußt.

Ich dachte, ich setze noch snort ein, oder ist das Modul mod_security als IDS ausreichend?

Das Intranet wird hauptsächlich aus dem inneren Netz genutzt, soll aber zukunftsfähig sein, d.h. auch von aussen soll der Zugriff in naher Zukunft möglich sein.

Meine Frage richtet sich hauptsächlich an Habo'ler die im Web-Hosting-Bereich tätig sind oder auf Arbeit selbst Intranets, bzw. Webserver mit Apache im Einsatz haben.

Ich möchte bitte keine Tipps, Hinweise oder ähnliches von Habo'lern die sich nur privat damit auseinandersetzen. Das soll nicht als Abgrenzung oder "Privatleute haben keine Ahnung" wirken, aber es geht mir hier hauptsächlich um den kommerziellen Bereich.

Vielen Dank für das Verständnis.

Grüße

Zephyros

.doc

mod_security hilft dir z.b. bei Angriffen gegen deinen FTP-Server nicht viel, daher ist ein IDS wie Snort oder auch Prelude oder OSSEC Pflicht. Regelmäßige rkhunter-Runden könntest du hier ebenfalls einplanen. Für erweiterte Sicherheit könntest du dir auch überlegen, SELinux, GRSec oder ähnliche Systeme zu nutzen. Dann müsstest du auch GCC und Co. nicht deinstallieren
Ich kenne deine Konfigurationen und deine Bedürfnisse nicht, daher kann man nicht viel sagen, ausser eben die allgemeinen Dinge: Zugriffsschutz per IPTables für kritische Bereiche, Dienste, die nur local benötigt werden auch local nur lauschen lassen - ein typischer Fehler ist hier z.b. PMA per Webserver zu betreiben und somit von Aussen angreifbar zu machen. Dadurch lauscht der mysqld praktisch auch nach aussen, was man ja einfach verhindern könnte. SSH-Auth nur mit PubKey-Verfahren, usw bla bla bla.. Eben die typischen Dinge.
Da das ganze ein Intranet ist und du somit gegen MitM-Attacken verwundbar bist, ist natürlich die Konfiguration des Routers auch sehr wichtig. Das bezieht auch ein, dass Integrität und Verschlüsselung gegeben sein muss, gerade auch wenn du ein ringförmiges Netz vor dir hast.
Ich sehe keinelei Email-Services, macht dann clamAV überhaupt Sinn? Letztendlich ist das sonst nämlich nur ein weiteres Tor, welches meines Wissens auch schon erfolgreich für einen Angriff verwendet wurde.

Hochverfügbarkeit würde mind. 2 weitere Server implizieren, besser wären natürlich >2, sodass die Daten auch immer aktuell gehalten werden können.

gelöscht

Danke für deine Antwort.

Mod-Security hilft mir aber bei der Sicherheit für Apache2, dass es den FTP nicht mit einbezieht ist mir bewusst. Aber danke für die Info.

SSH läuft auch auf einen anderen Port, unnötige Dienste sind schon abgeschaltet, ein eigenes Runlevel existiert ebenso.

Des Weiteren sollte vllt. erwähnt sein, dass ich eine Quellcodedistribution verwende und keine Binärdistribution.

SSH-Auth wird nur per Public-Key Verfahren gemacht, zudem istSSH so eingestellt das deny from all und allow from xxx gesetzt ist.

Zudem habe ich noch DenyHosts im Einsatz Vergessen zu erwähnen.

Die typischen Dinge habe ich soweit beachtet und auch eingesetzt bzw. Konfiguriert, wollte eben wissen ob es noch mehr gibt. Die BSI - Checkliste ISi-Check konnte ich bisher noch nicht durcharbeiten (keine Zeit).

Den Katalog von BSI habe ich auch, konnte diesen aber bisher auch noch nicht durcharbeiten Wollte soweit erstmal alles selbst machen, bevor ich mir Hilfe zur Rate ziehe.

Weitere Server kann ich nicht einsetzen, der Webserver selbst hat ein Hardware-RAID-System, welche natürlich keine 100%ige Hochverfügbarkeit gewährleistet.

clamAV ist im Einsatz, weil 1. das eine Vorgabe ist und 2. das Intranet durch Redakteure etc. die Möglichkeit zum Hochladen von Dokumenten und Bildern bietet.

Ein Email-Service wird hier nicht verwendet und auch nicht benötigt.

Sorry, aber rkhunter-Runden sagt mir nun gar nichts. Ach, einmal Google und schon hat man es Rootkit Hunter Project ^^

Danke noch mal.

Grüße

Zephyros

.doc

Damit "schützt" du trotzdem nur einen Dienst von vielen, die auf deinem Server nach aussen angeboten werden. IDS-Systeme haben da weitaus mehr Möglichkeiten, auch loakle Infektionen zu entdecken.

SSH auf einem anderen Port halte ich persönlich für unnötig, denn dafür sind nunmal Standardports da. Was ein eigenes Runlevel soll, verstehe ich persönlich nicht. Unnötige Dienste gibt es auf einem Debian-System ersteinmal nicht, sofern du nicht Ubuntu oder ähnlche Derivate verwendest..

Das bedeutet nur Mehrarbeit für dich, denn du musst nun eigenständig für jedes Paket die Sicherheitsupdates überwachen und bei Bedarf entweder auf einem anderen Server die Pakete bauen, oder für jeden Build gcc neu installieren. Debian bietet da schon ein ganz gutes System, was man auch durchaus übernehmen kann. Eine Einspeißung der Source-Pakete macht lediglich bei speziellen Umgebungen (z.b. mit diversen Optimierungen in Bezug auf Sicherheit und Performance) Sinn, auf einem einfachen Webserver sehe ich dafür kein Bedarf.

Das hat allerdings nun nichts mehr mit Hochverfügbarkeit zu tun, das ist einfach nur Spiegelung der Daten, sodass die Daten nicht verloren gehen können. Fällt der Strom aus oder schmort ein Prozessor durch ist der Server trotzdem ersteinmal weg.

Was mir noch einfällt wäre eine physische Sicherheit: Käfige, Zugangskontrollen, ...

gelöscht

Was nun dabei unverständlich oder nicht nötig ist, spielt erstmal weniger eine Rolle, sondern eben umgekehrt, was nötig ist Denn noch danke ich für deine Hinweise, Ideen und Tipps. Also nicht böse verstehen

Vllt. als kleine Hintergrundinformation: Ich mache dabei auch vieles für mich und meine Fähigkeiten bzw. Kenntnisse, das soll heißen das ich alles besser verstehen möchte und auch mehr Einblick in die Tiefgründe von allem haben möchte, deshalb ziehe ich es als Quellcodedistribution auf und nicht als Binärdistribution.

Zudem sei gesagt, dass ich sehr gerne mit der Konsole arbeite und auch gerne viel Tippe und ausprobiere (auch wenn das ungewöhnlich klingt).

Das mit dem IDS habe ich verstanden, ich tendiere auch mehr zu einem "richtigen" IDS-System.

Wie schon erwähnt, verwende ich für den Webserver ausschließlich Debian, viele Dienste konnte ich nicht deaktivieren, weil die entweder nicht existierten oder schon deaktiviert waren. Bei Apache sind auch schon viele Module deaktiviert die i.d.R. unnötig sind, die die noch aktiviert waren wurde von deaktiviert (also die, die nicht benötigt werden, wie mod_autoindex, mod_cgi etc.).

Die physische Sicherheit ist schon gewährleistet, Server-Rack-Schrank welcher abgeschlossen ist, sowie auch der Raum selbst. Zugangskontrollen können leider nicht gewährleistet werden, zu teuer und auch in der Art des Unternehmens nicht gerade "wichtig". Das es normalerweise wichtig ist, weiß ich

Grüße

Zephyros

.doc

Oje, das ist ein großer Fehler. Damit bist nämlich du der größte Knackpunkt an der Sache und nicht die Software selbst.
Installier dir lieber eine VM, spiel damit ersteinmal rum und wenn du meinst, dass es sicher ist, dann spiel die Konfiguration auf den Produktivserver. Aber erst dann. Direkt am Produktivserver "herumzuspielen" und auszuprobieren ist grob fahrlässig!

gelöscht

Am Produktivserver spiele ich auch nicht rum, es existiert auch kein Produktivserver. Der Webserver wird erst noch eingeführt. Deshalb läuft der Webserver momentan auf einem Testsystem. Hätte ich auch erwähnen sollen.

Was du ansprichst sind grundlegende Dinge, die ich kenne, immerhin bin ich kurz vorm Abschluss zum FiSi.

bitmuncher

Sorg dafür, dass die Kiste wirklich nur im internen Netz erreichbar ist und schon kannst du deinen ganzen Security-Unsinn um einiges runterschrauben. Zwar kommen viele Angriffe von innen, sind aber auch entsprechend leicht nachweisbar und zurückverfolgbar auf eine spezifische Person. Dinge wie IDS, Flood/DoS-Schutz u.ä. werden damit unnötig. Wenn es keine Zugangskontrollen gibt, ist es sogar ziemlich unsinnig da solche Sicherheitsmaßstäbe anzusetzen. Sollte die Kiste in Zukunft von externen Mitarbeitern genutzt werden müssen, dann sollen diese gefälligst einen VPN-Zugang in eurer internes Netz nutzen und fertig ist. Dafür ist es schliesslich ein _Intra_net. Die Unterteilung zwischen Internet und Intranet gibt es bei Admins nicht umsonst, denn u.a. werden daran auch die notwendigen Sicherheitsvorkehrungen gemessen.

__________________

.doc

Das Problem hierbei sehe ich z.b. in firmeninternen WLAN-Netzen. Jeder kann rein, wenn z.b. aus Kompatibilitätsgründen (ich habe schon Netze gesehen, die WEP hatten, weil die Blackberrys damit keine Probleme hatten...) eine schlechte oder garkeine Verschlüsselung existiert. VPN schafft hier sicherlich Abhilfe, das Problem hierbei ist allerdings, dass ein komplettes Netz umkonfiguriert werden muss, was schon eine ganz schöne Aufgabe ist, wenn nicht bereits diese Art der Zugriffskontolle vorhanden ist. Ebenfalls ist hierbei die Rücksprache mit dem Verantwortlichen von Nöten, welcher sich bei Veränderungen am Netzerk dieser Größe oft queer stellt (aus gutem Grund...).

bitmuncher

Einen VPN-Router in's Netz zu stellen, halte ich nicht unbedingt für eine größere Umstrukturierung. Aber Recht hast du. Es kommt natürlich auf das Netzwerk an, ob dies umsetzbar ist, aber ein ordentlich aufgebautes Intranet sollte von aussen prinzipiell nur über entsprechend sichere Zugänge erreichbar sein. Gerade bei grossen Firmen spielt Wirtschaftsspionage noch eine gewisse Rolle und die meisten Intranets enthalten da durchaus Daten, die interessant sein könnten. Das Intranet daher an's Netz zu hängen ohne VPN o.ä. vorzuschalten ist da schon fast fahrlässig. Niemand kann vorhersagen, ob in der verwendeten Server-Software nicht morgen bereits eine Lücke entdeckt wird, die dann für einen Angriff genutzt werden könnte. Patches haben schliesslich auch eine gewisse "Reaktionszeit" und die "organisierte"/professionelle Datenkriminalität reagiert erfahrungsgemäß etwas schneller als die Entwickler der löchrigen Programme. Selbst für Apache brauchen Patches im Durchschnitt 24 Stunden. 24 Stunden, die ein Angreifer mit ernsthaftem Interesse an den Daten der Firma bequem nutzen kann um sich Zugang zu verschaffen.

__________________

gelöscht

Das der ganze Sicherheitskram unnötig sein kann, mag sein. Nur muss ich mich an Vorgaben halten und wenn Chef das haben will, kann ich mit Argumenten um mich schmeißen wie ich es will. Bringen wird es allerdings nichts.

Das Intranet soll zukunftssicher sein, die externen Mitarbeiter werden nur über VPN darauf zugreifen, solch ein virtuelles Netz existiert auch schon. Von daher wird keine Umstrukturierung etc. von Nöten sein.

Die Updates für Apache etc. sind als Cronjob konfiguriert.

Denn noch danke ich für eure konstruktive Kritik, Hinweise und auch Tipps. Ihr habt mir schon geholfen damit.

Grüße

Zephyros

bitmuncher

Von Updates via Cronjob rate ich aus eigener Erfahrung dringend ab. Sonst kommst du eines Tages zur Arbeit und nichts geht mehr, weil irgendwas beim Update schiefgegangen ist, was du nicht mitbekommen hast und die Fehlersuche kann dann sehr langwierig sein. Integriere Updates in deinen Tagesablauf aber niemals in die Crons.

__________________

.doc

Dem kann man nur zustimmen!

gelöscht

Ok, stimmt. Klingt plausibel. Danke für den Hinweis. Argh, eigtl. könnte ich mich ärgern. Bei den Windows Servern sind die autom. Updates auch aus und werden erstmal auf einem Testsystem eingespielt und getestet bevor es in die Produktivserver implementiert werden, nur warum mache ich das gerade bei einem Linuxserver nicht ?( *kopfschüttel*

Lieber 2x nachdenken

Grüße

Zephyros