Diskussionsthread zur Konfiguration von sarge-amd64

Was die ganze Administration angeht, würde ich folgendes vorschlagen.

Nach außen offen ist nur das, was wirklich offen sein muss (sprich http, mail).
Dazu läuft eine VPN-Lösung, entweder über ipsec oder openvpn, um sich in ein internes Netz einzuklinken.
Alles, was administrativ genutzt werden soll, ist nur über dieses interne Netz zu erreichen (mit Ausnahme von ssh vielleicht, damit man sich nicht aus Versehen selber aussperrt).
Darüber kann man dann auch ftp usw. ohne Bedenken nutzen. openvpn und ipsec sind auch unter windows gut unterstützt, so dass die Admins mit Windows da keine Probleme haben sollten.
X509-Zertifikate für alle zu erstellen, die in das lokale Netz reindürfen, ist kein Problem. Und selbst wenn man dann in dem Netz drin ist braucht man ja immer noch die login-Daten, um sich auf dem Server einzuloggen.

Wenn es gewünscht ist kann ich da auch mal eine konkretere Lösung skizzieren und hier posten.
 
Wie bitte? "Sehr sicheres ssh" ? Erstens ist imho sehr sicherheitsrelevant und imho ist es nicht verkehrt zu treffen und drittens ein beliebtes "Angriffsziel".

Ja - mit Webmin hast du natürlich Recht - aber nochmal - es geht ja AUCH darum, das System schnellstmöglich in den Griff zu bekommen.
Und ssh ist halt praktisch unverzichtbar - also geht's ja darum dies so sicher wie möglich zu bewerkstelligen.
Also du empfiehlst ssh durch Portknocking zu schützen und willst gleichzeitig Webmin einsetzen. *buck*
Webmin ist eine der größten Sicherheitslücken überhaupt. Außerdem will ich doch gerne selbst wissen welche Einträge in welcher config gemacht werden.

Anstatt Portknocking reicht es imho aus einen root-Login via ssh zu unterbinden, (denn der ist default erlaubt, PermitRootLogin auf no) und den Login via Username: Password abzuschalten (UsePAM auf no setzen) und nur noch Logins mit ssh-keys (rsa oder dsa) zu gestatten. Somit laufen sämtliche Passwortattacken, die ich täglich dutzendfach auf den ssh Login habe ins Leere.

cu(lix)
 
Anstatt Portknocking reicht es imho aus einen root-Login via ssh zu unterbinden, (denn der ist default erlaubt,
...unter jedem BSD per default verboten.
Das Portknocking ist genauso toll wie, auf ICMP nicht anworten, gefaehrdet im Grunde nur wichtige Funktionalitaet und bringt nichts weiter als Verschleierung, weniger Sicherheit.
PermitRootLogin auf no) und den Login via Username: Password abzuschalten (UsePAM auf no setzen) und nur noch Logins mit ssh-keys (rsa oder dsa) zu gestatten. Somit laufen sämtliche Passwortattacken, die ich täglich dutzendfach auf den ssh Login habe ins Leere.
Etwas anderes waere IMHO nicht besonders klug. Generell wird RSA empfohlen, weil die Sicherheit von DSA stark von der Implementation, genauer dem Zufallsgenerator, abhaengt.
Ein anderer Vorteil ist, dass man IP Adressen von denen Loginversuche mit Passwort kommen, da gibt es ja viele Bots und Zombiehosts, sofort aussperren kann, hab da mal so kleines Tool geschrieben.
 
Jetzt erstmal Spaß beiseite und zu wichtigeren Themen.
Wie gesagt, BSD gibt es nicht, ich hätte auch lieber ein gentoo gesehen, aber solche Gespräche gehen jetzt daran vorbei. Mit Linux kennen sich einfach mehr aus und es ist auch von der Geschwindigkeit mindestens genausogut, wenn nicht noch schneller (habe letztens mal einen Vergleich von fefe gesehen, da ist linux 2.6 fast überall die Nr. 1 gewesen, war aber schon etwas älter, der Vergleich)

Man sollte erstmal top-down vorgehen:
Anforderungen anschauen, welche Programme erfüllen das wie gut, welche Versionen der Programme, allgemeine Konzepte usw.

Diese Details sollte man dann vielleicht später aufsplitten in Betriebssystem-Konfiguration (inkl. Sicherheit), http-Server-Konfiguration, datenbank-Konfiguration usw.

Vielleicht baut da mal jemand ein Basiskonzept auf und das kann dann diskutiert und verfeinert werden (und da soll nicht rein, welche Version von vim oder emacs da drauf soll ;) )

(btw: Portknocking würde ich auch nicht empfehlen - das täuscht nur falsche Sicherheit vor - ich bevorzuge einen VPN-Ansatz)
 
Zu Webmin sage ich nichts mehr - ich habe bereits selbst erwähnt, dass ich es, wenn überhaupt schützen würde. Wenn es geschützt ist (und zwar mehrfach - durch Konfiguration von Webmin selbst und durch entsprechende Einstellungen im apache und eben durch Portknocking), dann sind die risiken nicht so gross, wie hier behauptet wird - Aber egal...

@Tom24: Du hast recht - in erster Linie ist Portknocking eine Art Verschleierung (oder eben "Obscurity" ). Und natürlich - auch das habe ich mehrfach geschrieben - ersetzt es nicht die sonst üblichen Vorkehrungen zu treffen, entsprechende Daemons zu schützen. Die Diskussion wird mir langsam zu mühsam, denn (ich wiederhole mich) - niemand würde sein Haus nicht mehr abschliessen, nur weil er eine Alarmanlage hat. Aber umgekehrt: Jemand der sein Haus immer abschliesst, dem bringt eine Alarmanlage möglicherweise zusätzliche Sicherheit. Im Falle von Portknocking hält es eben beispielsweise zusätzliche Diebe ab, die auf einen "schnellen Bruch" aus sind.

Aber was rede ich da ... über dieses Thema diskutieren ganz andere Leute als wir hier sind. Und natürlich gibt's da mehrere Meinungen - Lest den Artikel von Bastille-Linux (speziell Tom24 ;) )
"The most misunderstood statement in the computer security field has got to be "security through obscurity is bad." As security professionals, many of us try to teach a few simple lessons to help system administrators become more security-conscious. Unfortunately, the simplicity of our lessons has backfired. In this article, I'll talk about how obscurity can aid security -- hopefully, I can clear up some of this confusion." .... [mehr]

Was Portknocking betrifft - bin ich der Meinung, dass es eine Technik ist, die einen hervorragenden zusätzlichen Schutz bietet und zudem in ca. 5 Minuten implementiert ist. Weshalb also darauf zu verzichten? Wer würde eine einfach installierende und kostenlose Alarmanlage zu Hause ausschlagen, wenn sie keinesfalls zusätzliche Risiken birgt und auf einer anderen Ebene als die üblichen Vorkehrungsweisen aber zusätzlichen Schutz birgt? Oder wer glaubt, dass man im Auto auf Gurten verzichten kann, nur weil man einen Airbag hat??? Die Diskussion scheint mir ehrlich gesagt auf dieselbe Art und Weise widersinnig und weltfremd, wie das Argument auf Portknocking zu verzichten, weil es Sicherheit vortäusche - natürlich reicht das alleine nicht aus... aber wer hat das denn behauptet?

PS:; noch was: Selbstverständlich ist ein permitRootLogin auch bei jedem Debian-System per default verboten. Wobei egal wie euer ssh geschützt wird - euer Schutz setzt immer voraus, dass er nicht bereits im daemon selbst durch Ausnützen einer Lücke ausgehebelt werden kann. Somit täuscht imho das eher falsche Sicherheit vor, egal wieviele Passwörter rsa-Schlüssel, Zertifikate etc. ihr aufstellt. Und da ist eben ein zusätzliches Portknocking überlegen, weil der Schutz auf einer völlig unabhängigen Ebene läuft. In Kombination beider Möglichkeiten wird die Sicherheit maximiert. Das betrifft auch VPN - Die Kombination auf verschiedenen Ebenen ist nicht zu übertreffen. Vgl. Sicherheit im Auto: Gute Bremsen und Airbag einerseits - aber umsichtiges Fahren und anschnallen andererseits...
 
Zuletzt bearbeitet:
Es wäre mit Sicherheit auch interessant, wenn ihr auf dem Server mal

rrdtool

einsetzen würdet, um die Belastung des Systems (CPU, RAM, HDD, Temps, User u. Prozesse, ...) grafisch zu ermessen.

Lasse auf meinem kleinen Serverchen auch diverse Graphen zeichnen, die mir u.A. auch schon mal verraten haben, dass ich vergessen habe ein NFS-Verzeichnis zu unmounten (ca. 10% mehr Load, da er versucht hat die Verbindung wieder herzustellen).

Die meissten Graphen lasse ich alle 3 Minuten aktualisieren - das erzeugt schätzungsweise 1-5 % (max.) CPU-Last auf die Dauer gesehen, zumindest auf meinem System, was allerdings ein recht altes ist. Denke mal, die zusätzliche Last ist vorerst zu vernachlässigen.

Die Ergebnisse kann man schön als PNG-File ausgeben und in eine HTML-Seite einarbeiten - sicherlich auch für die User hier interessant.

Wenn ihr Konfigurationshilfen benötigt, kann ich euch auch gerne mal meine Konfigurationsscripts geben (Die Farben lassen sich auch schön im P3D-Style anpassen ;D )

Gruß,
MFR2000
 
Zuletzt bearbeitet:
Hey feelx,

hast ja ne Menge geschrieben, verstehe dich auch, jedoch hab ich da noch ein paar Sachen im Hinterkopf die es zu beachten gilt, wenn man mit etablierten Verfahren experimentiert. Ich merke allerdings auch, dass wir uns hier im Kreis drehen, ich versuch mal ein bischen forsch zu sein. ;D

...here it goes.
Zu Webmin sage ich nichts mehr - ich habe bereits selbst erwähnt, dass ich es, wenn überhaupt schützen würde. Wenn es geschützt ist (und zwar mehrfach - durch Konfiguration von Webmin selbst und durch entsprechende Einstellungen im apache und eben durch Portknocking), dann sind die risiken nicht so gross, wie hier behauptet wird - Aber egal...
Webmin ist schon ein heisses Eisen und ich wuerde es schon als besonders gefaehrlich einstufen, weil alle Prozesse von webmin als root laufen, jedoch neige ich dazu es hin und wieder bereitzustellen, sofern der webmin-webserver ausschlieslich auf dem loopback Interface lauscht und man daher nur ueber einen ssh-Tunnel Zugang bekommt und ueber kein anderes Interface.
Zusaetzlich sollte man dort jede Aendernung der Konfiguration mitloggen.

Thema Portknocking

Ich hab deinen verlinkten Text gelesen und moechte ein paar Einwaende zum Portknocking einwerfen.
Sofern ich das richtig verstanden hab, laeuft der TCP Handshake bei Portknocking nichtmehr wie in RFC793 ab (syn, syn ack, syn) sondern syn, ack. Ganz spontan kommen mir da ein paar die ueblichen Bedenken, wenn man mit etablierten Standards rumspielt, in den Kopf.
  1. Man bricht einen Standard, ueber die Konsequenzen muss man sich bewusst sein, das gilt insbesondere fuer die Clients (welche kann ich jetzt noch benutzen? usw.)
  2. Wie finden das die Router dazwischen wenn dort staendig Verbindungen etabliert werden, die nicht vernuenftig ausgehandelt wurden? Sind unterwegs Geraete anzutreffen die das nicht so leicht nehmen? IMHO ein unkontrollierbar hohes Risiko.
  3. Stateful Inspection Firewalls werden bei sowas aufmerksam, und wenn man Pech hat, muss man Firewallregeln anpassen und spaet. dort hoert der Spass auf, weil exaktes Matching nichtmehr stattfinden kann.
Solche Sachen sind IMHO kein Spass, ich empfehle da auch eine Lektuere wenn du (ihr) moegt. :) Sie widmet sich einem ganz aehnlichen Thema.

Ist ein Paper von Richard van den Berg und Phil Dibowitz - Proceedings of LISA ’02 (Usenix).

Titel: Over-Zealous Security Administrators Are Breaking the Internet

http://tom.ruegen-grafik.de/files/docs/vanderberg.pdf

Selbstverständlich ist ein permitRootLogin auch bei jedem Debian-System per default verboten.
Muss neu sein und ich bestreite das mal pauschal, kontrolliere aber mal mit einer sarge cd, sofern ich eine in die Finger bekomme.
 
(...)
Selbstverständlich ist ein permitRootLogin auch bei jedem Debian-System per default verboten.

Muss neu sein und ich bestreite das mal pauschal, kontrolliere aber mal mit einer sarge cd, sofern ich eine in die Finger bekomme.

Bei Debian Sarge stable 3.1 (frische Installation) ist die Option auf "yes", also nicht verboten:

Code:
PermitRootLogin yes
 
Jetzt mal zu den einzelnen Komponenten:

Ich empfehle:
  • apache2
  • mysql ist ja gesetzt, bei den Versionen 4.x oder 5.0 weiß ich nicht, was die Anforderungen sind und wie groß der Unterschied ist (ich halte ja postgresql hoch) - generell würde ich die aktuelle 5.0 nehmen
  • PHP 5.x
  • FTP - ich empfehle vsftpd: klein, schnell, sicher
  • Zur Sicherung der managementports (ssh, ggf. ftp, usw.) empfehle ich ein VPN - mit OpenVPN oder IPSEC - damit erübrigt sich die Nebendiskussion über Portknocking und ssh-Standardeinstellungen (nur gut, dass man die Standardeinstellungen nicht ändern kann, oder ;) )
apache2

Nero - kannst du mal noch schreiben, auf was du speziell noch Wert legst - was es noch zu klären gibt und wie die Planungen aussehen.
 
Um mal nochwas zu einem grundlegenden Detail zu sagen: Als Dateisystem würde ich euch XFS empfehlen. Ist sehr schnell, stabil, hat einen umfassenden Satz an Werkzeugen und gehört mit zu den ältesten und damit erprobtesten Dateisystemen. Solltet ihr euch dagegen entscheiden, wäre der nächste Kandidat aus meiner Sicht ext3. Zu Reiser solltet ihr aber auf keinen Fall greifen.
 
Nachdem nun eigentlich alles läuft außer dem E-Mail Server wollte ich - nachdem ich inzwischen einiges darüber gelesen habe - XMail auf dem Server installieren. Nach Debian-Manier wollte ich das über apt-get machen. Allerdings erhalte ich nun auf einmal folgende Fehlermeldung:

serverlocale.png


Hab auch schon probiert mit dpkg-reconfigure localeconf manuell auf ISO-8859-15 oder ISO-8859-1 zu schalten. Aber immer wieder die gleiche Fehlermeldung. localeconf ist installiert und mit dpkg-reconfigure locales erreiche ich gar nichts.

Mit Google finde ich massenhaft solche Probleme mit Debian, allerdings keine wirklich hilfreichen Posts. Die meisten schreiben "irgendwann ging es dann wieder" :P Aber das kann ja nicht die Lösung sein.

Kann mir jemand helfen?
 
Hallo,

waehrend deine LANGUAGE und LC_ALL Variablen nicht gesetzt sind, ist der Wert von LANG unvollstaendig.
Code:
export LC_ALL=de_DE.ISO-8859-1
export LANGUAGE=de_DE
In die /etc/profile, oder bei Debian glaub ich /etc/environment, ich weiss nicht wie's bei Debian da gerade steht.
Das sollte reichen.

Weil bei DragonFly seit einiger Zeit WideCharacter unterstuetzt wird, hab ich meine locales auf UTF8 stehen.
Code:
export LANG=de_DE.UTF-8
export LC_ALL=de_DE.UTF-8
export LANGUAGE=de_DE
 
Hi,

vielen Dank - aber sooo einfach ist es leider nicht ;) Das hab ich schon probiert. Bei Debian heißt die Datei in der Tat environment und liegt in /etc. Aber egal was ich dort eintrage, Debian beschwert sich immer "cannot set BLABLA xy: no such file or directory".

Nach dieser Anleitung
http://www.ubuntuusers.de/viewtopic.php?t=1432
wo es auch um das Problem geht, habe ich auch folgende Werte eingetragen:

LANG=de_DE@euro
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=de_DE@euro

Aber es ist vollkommen egal. Die Fehlermeldungen bleiben *noahnung*
 
Zum einen, wie ich oben schon geschrieben habe, setze LC_ALL nicht, das kann einige Programme aus dem Tritt bringen.
Zum anderen, was passiert, wenn du auf der console "export LANG=de_DE@euro" eingibst? Welche Fehlermeldung spuckt er dir dann aus?
 
Welches Programm kommt bei LC_ALL denn durcheinander? ???
LC_ALL zwingt doch bloss alle LC_* Variablen auf einen Wert, waehrend LANGUAGE sie setzt wenn eine Variable noch keinen Wert hat. ...IIRC:-X

de_DE@euro ist doch kein vernuenftiger Wert fuer LANG, IMHO benoetigt LANG auch das Charset. Symbolisiert @euro unter Debian ein Charset? Ehrlich gesagt halte ich das fuer unwarscheinlich.
 
Welches Programm kommt bei LC_ALL denn durcheinander? ???

Zum Beispiel scripte, die bestimmte LC-Variablen für sich umdefinieren, z.B. auf C (Posix).

LC_ALL zwingt doch bloss alle LC_* Variablen auf einen Wert, waehrend LANGUAGE sie setzt wenn eine Variable noch keinen Wert hat. ...IIRC:-X

Eben, das Umdefinieren anderer LC-Variablen funktioniert dann nicht mehr, weil LC_ALL die überlagert. Es reicht normalerweise aus, LANG zu setzen, welches dann alle anderen LC-Variablen auch setzt, abgesehen von LC_ALL.

de_DE@euro ist doch kein vernuenftiger Wert fuer LANG, IMHO benoetigt LANG auch das Charset. Symbolisiert @euro unter Debian ein Charset? Ehrlich gesagt halte ich das fuer unwarscheinlich.

Doch, der steht für latin15, sprich Deutsch mit Euro-Symbol.
 
Du meinst sicher latin9? ;)

Jupp, ISO-8859-15 bzw. lat9.

Ist es sicher, dass Debian das korrekt versteht? Ich wuerde eher ISO-8859-15 im Namen verwenden.

Deshalb auch meine Frage, was bei "export LANG=de_DE@euro" passiert. Gentoo versteht das, und Debian meines Wissens nach auch. Ganz sicher bin ich mir da aber nicht. Außerdem ist es auch noch möglich, dass ein notwendiges Paket fehlt.
 
...und wo ist da das Codeset?

@euro ist ein Modifier, vielleicht ist es ja auch zh_TW.Big5@euro, woher soll er Rechner das wissen, wenn man es ihm nicht sagt?
 
...und wo ist da das Codeset?

Die Angaben sind alle jeweils Optional, und können auch bei Eindeutigkeit weggelassen werden.

@euro ist ein Modifier, vielleicht ist es ja auch zh_TW.Big5@euro, woher soll er Rechner das wissen, wenn man es ihm nicht sagt?

Der Rechner weiß das, weil de_DE@euro ein Synonym für latin9 ist, genauso wie de_DE synonym für latin1 steht. Wozu unnötige Redundanzen einbauen?
 
@Nero
mach doch mal:

# locale -a

da siehst Du welche locales bei Dir installiert sind.
Und anschließend reicht, wie PuckPoltergeist schon sagte, ein

# export LANG="de_DE@euro"

wenn's denn das locale -a zeigt.

Das kannst Du dann in /etc/profile oder in /etc/bash/bashrc (je nach Version) /etc/bashrc
eintragen und alle Tools solltens dann verstehen.

lg
 
Zurück
Oben Unten