Montag, 3. Mai 2010
Nichts anderes als SSH offen
Von einem Root-Server-Neukunden:
Ich frage mich gerade, was "andere" so an Diensten nach einer Installation offen haben?
prima, im Auslieferungszustand nichts anderes als SSH offen, so soll es sein!
Ich frage mich gerade, was "andere" so an Diensten nach einer Installation offen haben?
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
LAMP (wieso auch immer jemand der das nicht selbst installieren kann einen Rootserver mietet.. sowas fördert nur die potentiellen Spamschleudern) oder direkt ein Confixx/Plesk-versuchtes System...
Sehr toll ist da z.B. Debian, welches jedes installierte Paket mit eigenem rc-script auch sofort starten muss.
Wär ja auch zu viel verlangt, dass ich meine Dienste erstmal konfigurieren kann, bevor die auf einer public IP auf allen interfaces gestartet werden. :-/
Wär ja auch zu viel verlangt, dass ich meine Dienste erstmal konfigurieren kann, bevor die auf einer public IP auf allen interfaces gestartet werden. :-/
Na da lob ich mir doch Gentoo..
Startet Debian nicht sogar Dienste nach einem Update automatisch neu obwohl man evtl etwas in der Config ändern sollte (benutze schon lange kein Debian mehr, also keine Ahnung ob das noch so ist)?
Startet Debian nicht sogar Dienste nach einem Update automatisch neu obwohl man evtl etwas in der Config ändern sollte (benutze schon lange kein Debian mehr, also keine Ahnung ob das noch so ist)?
Ist das nicht eher Pseudo-Kritik? Ich will hier keine Distributionsschlacht auslösen, aber ein paar Dinge sollte man schon richtig stellen:
Grundsätzlich gilt:
Ein Paket sollte sichere Grundeinstellungen mitbringen. Anders gesagt: Wenn die Anwendung startet, sollte sie das System nicht gefährden. Genau das ist bspw. bei einer Apache-Paketinstallation der Fall: Sie gefährdet das System *nicht*.
Dann muss man auch wissen, dass kritische Anwendungen bspw. mit einem eingebauten Stopper in der Konfiguration daher kommen. Erst wenn der Anwender diesen Stopper manuell aus der Konfiguration entfernt hat, startet die Anwendung.
Auch sollte man wissen, dass sehr viele Pakete debconf triggern. D.h. die Installation bittet den Anwender gleich den Dienst zu konfigurieren.
@ Adrian & Py:
Habt ihr wirklich Ahnung von Debian, oder habt ihr Debian irgendwann einmal "nur benutzt"? Wer eine stabile Debian-Version nutzt, wird nie nach einem Update irgendein Paket neu konfigurieren müssen. Gerade deswegen fließen lediglich Fehlerkorrekturen in den Stable-Zweig ein.
Diese Politik führte u.a. dazu, dass ClamAV zu etch-Zeiten Millionen von Debian-Rechnern lahm gelegt hat, OT:
Der ClamAV Hersteller hatte die Update-Routine geändert und die Nutzer aufgefordert zu aktualisieren. Hierzu gewährte man eine Frist.
Die Debian Paketpolitik lies dieses Update aber nicht nicht in die damalige Stable-Version einfließen, da eben nicht nur Fehler korrigiert wurden. Irgendwann war die Frist Seitens ClamAV dann abgelaufen und man verteilte das "Todes-Signatur-Update". Das führte dazu, dass ClamAV auf den Debian-Kisten die CPU gefressen hat. Letzteres hätte übrigens nicht passieren sollen.
In der Folge lief dann aber für knapp 1.5j ClamAV nicht Out-of-the-Box auf einem stabilen Debian, weil die Version nicht mehr mit den ClamAV-Servern kommunizieren konnte
Also bitte:
Wenn Kritik, dann bitte inhaltlich bitte auch korrekt. Wer also behauptet, dass von einem Debian Paket-Update in irgendeiner Form Gefahr ausgeht, sei es, weil man Dienste neu konfigurieren müsste ect., zeigt pures Unwissen.
Grundsätzlich gilt:
Ein Paket sollte sichere Grundeinstellungen mitbringen. Anders gesagt: Wenn die Anwendung startet, sollte sie das System nicht gefährden. Genau das ist bspw. bei einer Apache-Paketinstallation der Fall: Sie gefährdet das System *nicht*.
Dann muss man auch wissen, dass kritische Anwendungen bspw. mit einem eingebauten Stopper in der Konfiguration daher kommen. Erst wenn der Anwender diesen Stopper manuell aus der Konfiguration entfernt hat, startet die Anwendung.
Auch sollte man wissen, dass sehr viele Pakete debconf triggern. D.h. die Installation bittet den Anwender gleich den Dienst zu konfigurieren.
@ Adrian & Py:
Habt ihr wirklich Ahnung von Debian, oder habt ihr Debian irgendwann einmal "nur benutzt"? Wer eine stabile Debian-Version nutzt, wird nie nach einem Update irgendein Paket neu konfigurieren müssen. Gerade deswegen fließen lediglich Fehlerkorrekturen in den Stable-Zweig ein.
Diese Politik führte u.a. dazu, dass ClamAV zu etch-Zeiten Millionen von Debian-Rechnern lahm gelegt hat, OT:
Der ClamAV Hersteller hatte die Update-Routine geändert und die Nutzer aufgefordert zu aktualisieren. Hierzu gewährte man eine Frist.
Die Debian Paketpolitik lies dieses Update aber nicht nicht in die damalige Stable-Version einfließen, da eben nicht nur Fehler korrigiert wurden. Irgendwann war die Frist Seitens ClamAV dann abgelaufen und man verteilte das "Todes-Signatur-Update". Das führte dazu, dass ClamAV auf den Debian-Kisten die CPU gefressen hat. Letzteres hätte übrigens nicht passieren sollen.
In der Folge lief dann aber für knapp 1.5j ClamAV nicht Out-of-the-Box auf einem stabilen Debian, weil die Version nicht mehr mit den ClamAV-Servern kommunizieren konnte
Also bitte:
Wenn Kritik, dann bitte inhaltlich bitte auch korrekt. Wer also behauptet, dass von einem Debian Paket-Update in irgendeiner Form Gefahr ausgeht, sei es, weil man Dienste neu konfigurieren müsste ect., zeigt pures Unwissen.
Das ein Update zu Problemen führt, habe ich nicht behauptet. Aber mich stört schon alleine das benannte Apache verhalten oder auch bei der Installation eines E-Mail-Servers, das Ding soll einfach nicht starten, bevor ich es sage.
Aber das ist meine Meinung und man kann sicherlich darüber Diskutieren.
Aber das ist meine Meinung und man kann sicherlich darüber Diskutieren.
Nach der Grundinstallation gar nichts (Arch Linux ist da ja zum Glück sehr sparsam!). Und auch nach der Installation von entsprechenden Programmen nichts (gut, auf dem Rootserver ist das anders, weil da ja leider kein Arch Linux läuft, sondern Debian).
Nach der vollständigen Installation sieht es so aus:
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
443/tcp open https
465/tcp open smtps
993/tcp open imaps
5222/tcp open unknown
5269/tcp open unknown
5280/tcp open unknown
Due unbekannten Ports kommen von ejabberd.
Nach der vollständigen Installation sieht es so aus:
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
443/tcp open https
465/tcp open smtps
993/tcp open imaps
5222/tcp open unknown
5269/tcp open unknown
5280/tcp open unknown
Due unbekannten Ports kommen von ejabberd.
Hast du mal versucht, Arch Linux auf einem Manitu-Server zu installieren? Ich habe momentan noch einen DS3000 mit Arch laufen, würde aber gerne irgendwann zum "Root-Server M" von Manitu wechseln.
Ja, aber irgendwas ging da nicht, und da extra Geld für bezahlen, um die Online-Konsole zu bekommen, um den Startvorgang zu beobachten, das wollte ich dann doch nicht
Verbesserungsvorschlag: SSH auf einem anderen Port als 22... seitdem habe ich da keine Angriffsstürme mehr. Dass die Standardinstallation bei 22 ist, finde ich sinnvoll, das gehört aber zu den ersten Dingen, die ich auf einer neuen Maschine anfasse.
Ich finde es übrigens vollkommen in Ordnung, dass Apache auf Debian nach der Installation startet: Es kann ja nichts schlimmes passieren, die Vorkonfiguration ist ordentlich. Bei kritischeren Dingen, bspw. dhcpd, zwingt mich Debian (oft per Variable in /etc/defaults/irgendwas) zur Konfiguration, bevor irgend etwas am Netz hängt.
Ich finde es übrigens vollkommen in Ordnung, dass Apache auf Debian nach der Installation startet: Es kann ja nichts schlimmes passieren, die Vorkonfiguration ist ordentlich. Bei kritischeren Dingen, bspw. dhcpd, zwingt mich Debian (oft per Variable in /etc/defaults/irgendwas) zur Konfiguration, bevor irgend etwas am Netz hängt.
Ein Apache ist genauso ein angreifbarer Dienst wie alles andere.. und wenn er nicht laufen muss (bzw vor einem Update gelaufen ist), soll er auch nicht automatisch gestartet werden.
SSH auf einen anderen Port legen ist auch nur marginal sinnvoll... man erspart sich vielleicht die Log-Eintraege der diversen shell-suchenden Scriptkiddies, aber wenn jemand wirklich reinwill, wird er deinen Port finden.
SSH auf einen anderen Port legen ist auch nur marginal sinnvoll... man erspart sich vielleicht die Log-Eintraege der diversen shell-suchenden Scriptkiddies, aber wenn jemand wirklich reinwill, wird er deinen Port finden.
Wenn Apache nicht laufen soll, dann sollte es entweder nicht installiert sein oder der Start blockiert sein (Bei machen Programmen gibt es in /etc/default/programmname einen Eintrag START=yes, der sich schnell ändern lässt - beim Apache anscheinend nicht). Man kann Startscripts einem runlevel zuordnen - ich weiss allerdings nicht, ob der Updater das beachtet, wenn der Daemon im aktuellen Runlevel nicht gestartet werden soll (den Bedarf hatte ich bisher nicht). Wenn der Daemon zwar installiert ist, aber für einige Zeit nicht laufen soll, bietet es sich ja schon aus grundsätzlichen Erwägungen an, das zu konfigurieren, damit bei einem Server-Neustart, der ja auch mal unerwartet kommen kann, nicht das Chaos ausbricht.
Ganz primitiv, aber wirkungsvoll ist der Eintrag von "exit 0" als zweite Zeile im Apache-Initscript
Bezüglich SSH-Port: So sieht man eben nur die Login-Versuche von denen, die es ernst meinen. Ich habe gerade mal recherchiert: Bei mehreren meiner Server kein einziger echter Angriffsversuch, nur zwei Einträge, als ich mich mal beim Passwort vertippt hatte. Das finde ich beruhigend, aber natürlich ist das Geschmackssache, und als einziger Zugangsschutz zu einem Server auch nicht empfehlenswert. Ich bin ein Gegner von security-by-obscurity, solange das der einzige (ernstzunehmende) Schutz ist.
Gruß
Debe
Ganz primitiv, aber wirkungsvoll ist der Eintrag von "exit 0" als zweite Zeile im Apache-Initscript
Bezüglich SSH-Port: So sieht man eben nur die Login-Versuche von denen, die es ernst meinen. Ich habe gerade mal recherchiert: Bei mehreren meiner Server kein einziger echter Angriffsversuch, nur zwei Einträge, als ich mich mal beim Passwort vertippt hatte. Das finde ich beruhigend, aber natürlich ist das Geschmackssache, und als einziger Zugangsschutz zu einem Server auch nicht empfehlenswert. Ich bin ein Gegner von security-by-obscurity, solange das der einzige (ernstzunehmende) Schutz ist.
Gruß
Debe
Das ist ja der Punkt, nach der Installation wird er automatisch gestartet.
unter http://utcc.utoronto.ca/~cks/space/blog/linux/PackagingStartupScripts?showcomments gibt es grad eine Diskussion zu dem Thema unter Debian.
Anscheinend hilft es bei Debian die S* links unter /etc/rc?.d/ zu löschen (aber nicht die K* links), um sicher zu stellen, dass diese beim update nicht neu angelegt werden. (update-rc.d erstellt/löscht S und K links und ist anscheinend nicht dazu gedacht von admins/usern benutzt zu werden).
Anscheinend hilft es bei Debian die S* links unter /etc/rc?.d/ zu löschen (aber nicht die K* links), um sicher zu stellen, dass diese beim update nicht neu angelegt werden. (update-rc.d erstellt/löscht S und K links und ist anscheinend nicht dazu gedacht von admins/usern benutzt zu werden).
Ich möchte mich auch gegen Debian aussprechen. Die Package-Maintainer wollen dem Admin zuviel abnehmen (das klappt leider nicht immer) und Upstream wird leider häufig sehr stark verbogen.
Für Leute die ihr System langfristig wirklich selber im Griff haben möchten empfehle ich stets Gentoo
Für Leute die ihr System langfristig wirklich selber im Griff haben möchten empfehle ich stets Gentoo
IPv4 vs. IPv6
Du bist hier via
Suche
Ökostrom
Kalender
Kommentare
zu Daxig
So, 12.02.2012 00:53
Wie hast du denn die Bestellun
g erwartet? Würde mich wirklic
h mal interessieren - ich find
e das jetzt nicht ungewö [...]
zu Daxig
Sa, 11.02.2012 22:05
das ist gängige Praxis... Wenn
ich etwas haben will, was (au
ch) per Webformular zu haben i
st muss ich die Bestellu [...]
Sa, 11.02.2012 17:42
das glaubst du doch selber nic
ht
zu .my.cnf
Sa, 11.02.2012 11:48
Chuck Norris gibt den Daten ei
nen Roundhouse-Kick, dann komp
rimieren die sich selber.
Sa, 11.02.2012 10:54
Gibts da schon einen Verhandlu
ngstermin? Wenn ich in der Näh
e bin, würd ich mir das glatt
noch ansehen kommen.
Fr, 10.02.2012 23:05
... ja wieso eigentlich nicht?
Bei Kunden mit Neuanschluss w
ird in der Regel eher selten e
in DSL-Modem daheim ruml [...]
Fr, 10.02.2012 20:54
Ist schon klar^^ nur ich hab s
chon lustige Erfahrungen mit Ö
sterreichern gemacht, grade mi
t Technik (wobei man das [...]
Fr, 10.02.2012 20:46
Finde ich auch.
Der Anwalt hä
tte auf das Angebot eingehen s
ollen, aber wer nicht hören wi
ll....
Fr, 10.02.2012 19:23
Na, da nehmt die doch in euer
Programm auf. Dann gibt es bal
d alles, außer eben der Leitun
g - und die dummen Kunde [...]
Fr, 10.02.2012 19:20
...und ist doch auch in Manuel
s Interesse: Künftige Stiebitz
er lesen dann im Blog nach, da
ss die Drohung der geric [...]
