You are currently browsing the archives for the “Linux” category.

Typo3 Performance Tuning Tips

11. Juni 2009 // Posted in CSS, HTML, JavaScript, apache (Tags: , , , , , , , , ) |  4 Comments

Ich hab hier mal ein paar Tips für die Performance Optimierung von Typo3 zusammen geschrieben. Einige Tips können ohne Probleme auch anderen Content-Management-Systemen bzw normale PHP-Seiten beschleunigen.

  1. CSS und JavaScript unbedingt in externe Dateien auslagern. Bei Typo3 funktioniert das mit den folgenden Befehlen:
    config.inlineStyle2TempFile = 1
    config.removeDefaultJS = external
    das hat den Vorteil, das der Browser diese Dateien nur einmal runterladen muß und bei weiteren Seiten der selben Webseite diese aus dem lokalen Browser-Cache holt, was natürlich wesentlich schneller geht
  2. php-eacclerator
    hierbei handelt es sich um einen PHP-Cache auf dem Webserver. PHP-Scripte werden normalerweise immer zur Laufzeit (d.h. bei jedem Aufruf) vom PHP-Interpreter “kompiliert” und an den Webserver übergeben. php-eacclerator speichert bereits kompilierten PHP-Scripte zwischen und gibt diese bei erneutem abrufen direkt aus ohne das das PHP-Script nochmal neu kompiliert werden muß. Je nach Webseite und Hardware des Webservers kann man mit php-eacclerator die Antwortzeiten (mit yslow gemessen) mindestens halbieren.
  3. JavaScript-/CSS-Dateien und HTML-Templates in Typo3 optimieren
    so komisch sich das anhört, aber wenn man für die Syntax unwichtigen Leerzeichen aus den oben genannten Dateien entfernt spart man wieder Platz und damit Bandbreite. Kommentare haben in CSS und JavaScript-Dateien nichts verloren. Kommentare sind nur für die Entwicklung und nicht für den Produktiv-Betrieb. Außerdem muß man aufpassen, CSS-Klassen möglichst effektiv einzusetzen. Ich persöhnlich bin kein Freund von Browser-Hacks. Meiner Meinung nach ist es effektiver (für die Webseite, nicht für mich), wenn ich eine Standard-CSS-Datei für alle Browser vorhalte und bei Browser, welche immer wieder Probleme bereiten (wie z.B. der IE) eine Extra-CSS-Datei anzulegen und anzupassen. In Typo3 kann man dann mit [useragent = *MSIE*] den Internet-Explorer erkennen und die entsprechend geänderte CSS-Datei ausliefern.
  4. Typo3-Plugin sourceopt installieren und einrichten
    Sourceopt entfernt je nach Einstellung Leerzeichen und Kommentare aus der HTML-Ausgabe. Wenn sourceopt alle Leerzeichen und Kommentare entfernt, kann es zu Problemen mit eingebetteten JavaScript kommen (z.B. bei GMENU-/TMENU-Layer-Menüs)
  5. htaccess-Dateien vermeiden und die Direktiven direkt in die Apache-Konfiguration schreiben
    Am besten ,man entfernt die Direktive AccessFileName aus der Apache-Konfiguration. So praktisch sie sein mag, sie kostet Zeit. Bei jedem Aufruf einer Webseite bzw. bei jedem Abruf einer Datei (auch bei CSS, JavaScript und Grafiken) schaut der Apache jedesmal erst nach ob diese Datei vorhanden ist. Effektiver ist es, die Konfiguration gleich in die Apache-Konfigurations-Dateien zu schreiben. Dies geht natürlich nur, wenn man einen root-Server zur Verfügung hat.
  6. AddOutputFilter für css und JavaScript-Dateien in den Apache-Konfigurationen bzw compressionLevel in Typo3 setzen(in der localconf.php)
    AddOutputFilter kompimiert die angegebenen Dateien und schreibt dies auch in den Header der Datei. Der Browser erkennt dies und kann die Datei wieder dekomprimieren. Hierdurch kann man Bandbreite sparen. Genug CPU-Leistung muß aber vorhanden sein, da die Kompression hier Leistung erwartet. Auf alten kleineren PC’s/Servern ist dies nicht zu empfehlen. HTML-Dateien muß man nicht per AddOutputFilter-Direktive komprimieren. Das kann Typo3 intern mit compressionLevel machen. mit compressionDebugInfo kann man sich die erziehlte Kompression im HTML-Quellcode anzeigen lassen.
  7. Typo3-Core ändern um auch noch übrig gebliebenen JavaScript-Code auszulagern
    Dieser Tip ist nur für Leute, die sich mit PHP auskennen. Ich habe bei meiner Typo3-Installation den Code so verändert das alle JavaScript und CSS-Elemente extern in eine Datei ausgelagert wurden. Der eizigste Nachteil ist, das für die TMENU_LAYER-Menüs für jede Seite JavaScript-Dateien angelegt werden. Nach einer paar Wochen (je nach Auslastung der Webseite) sumiert sich das ganz schön.
  8. JavaScript an das Ende der HTML-Datei/Ausgabe verlagern
    das Laden von JavaScript blockiert im Browser das weiteren Laden von Seiteninhalten. Erst wenn der JavaScript-Code verarbeitet wurde ruft der Browser weitere Seiteninhalte ab. Daher ist es sinnvoller den JavaScript-Code erst am Ende der HTML-Datei zu laden. Je nach Script kann es hier aber zu Problemen kommen
  9. Grafische Menüs(GMENU/GMENU_LAYER) vermeiden und statt dessen Text-basierte Menüs (TMENU/TMENU_LAYER) verwenden
    Bei grafischen Menüs müssen für jeden Button ein oder mehrere Grafiken nachgeladen werden. Bei einem umfangreichen Layermenü und Grafiken von 1-2kB summiert sich das schnell zu einer beträchtlichen Größe zusammen. Effektiver sind hier Text-basierte Menüs da hier nur der text-Inhalt des Buttons und der HTML-Code geladen werden muß. Text-basierte Menüs haben außerdem den großen Vorteil, das Suchmaschinen wie google und Co. diesen Text auch lesen können. Mit Grafiken kann google nichts anfangen.
  10. falls große Grafiken unbedingt notwendig sind, diese per JavaScript nachladen.

amavisd-new und F-Secure oder anderes AV-Programm im chroot

3. Juni 2009 // Posted in Linux, Security, amavisd-new, postfix (Tags: , , , ) |  No Comments

Ich benutze zur Mail-Filterung postfix, amavisd-new, spammassassin und als Antiviren-Programm F-Secure Linux-Server-Security. Amavisd-new in ein chroot verschieben ist nicht wirklich ein großes Problem. Einfach ein Verzeichis anlegen, in der Konfiguration eintragen, die entsprechenden Dateien und Bibliotheken im chroot anlegen/kopieren und amavisd-new funktioniert.

Bei einem Antiviren-Programm geht das aber nicht so einfach. Ich habe lange nach einer Lösung für F-secure gesucht. Es funktionierte weder mit Links noch mit einer Änderung der Start-Datei unter /etc/init.d stabil.

Vor ein paar Tagen habe ich dann aber doch eine sehr einfache Lösung gefunden. Als erstes muß man screen installieren. Bei screen handelt es sich um eine Terminal-Emulation. Man kann mit screen auf der Konsole ein Programm, welches z.B. Fehlermeldungen nach stdout ausgibt, starten und sich aus dem screen-Terminal ausloggen. Logt man sich wieder ein, sieht man alle inzwischen aufgelaufenen Fehlermeldungen. Man kann also auf der screen-Konsole weiterarbeiten, das Programm unterbrechen oder was auch immer….

Um F-Secure Linux-Server-Security nun im chroot benutzen zu können, muß man als erstes alle Dateien in’s chroot in die entsprechenden Verzeichnisse kopieren. Bei einigen AV-Programmen kann man jetzt schon mittels screen ein chroot mit folgendem Befehlen starten:
screen -t test
chroot /chroot-Verzeichnis
/etc/init.d/AV-Programm start

Bei F-Secure-Linux-Server-Security funktioniert das so noch nicht. F-Secure braucht noch Zugriff auf das Proc-Verzeichnis. Links (egal ob Symlink oder Hardlink) funktionieren nich, da wir uns ja in einem chroot befinden. Um das Proc-verzeichnis auch im chroot-Verzeichnis benutzen zu können muß man einfach nur die /etc/fstab ändern. In der Datei fstab sollte schon ein Eintrag für proc vorhanden sein. Einfach diesen in eine neue Zeile kopieren und als Mount-Verzeichnis das chroot-Verzeichnis einstellen.

Jetzt kann F-Secure gestartet werden und es sollte funktionieren. Falls nicht, muß man nochmal alle Datei-Rechte, Bibliotheks- und Programm-Abhängigkeiten und die logs kontrollieren.

Empfehlung für Raid-Controller

2. Juni 2009 // Posted in Datenrettung, Linux, Windows (Tags: , , , , , , , , ) |  No Comments

Bei Servern stellt sich immer die Frage: Wie sichere ich meine Daten vor Datenverlust? Jedem Admin sollte die Antwort klar sein: ein Raid-Controller muß her. Wird Linux als Betriebssystem eingesetzt steht der Admin aber ganz schnell vor einem Problem. Hier müssen erst Fragen wie: Läuft der Controller problemlos unter Linux? Muß der Treiber erst kompiliert werden? Gibt es überhaupt Treiber? erst geklärt werden.

Von billigen Controllern (alles unter 100€) und von Onboard-Controllern rate ich generell ab. Hierbei handelt es sich eigentlich immer um Software-Controller. Hier übernimmt der Treiber die Verwaltung des Raid-Systems. Schmiert das Betriebssystem aus igrnedeinem Grund ab oder der Treiber wird unverhofft entladen, dann ist Ärger vorprogrammiert.

Bei richtigen (teuren) Controllern übernimmt die komplette Verwaltung der Controller. Das hat den Vorteil das die Verwaltung der Daten/Festplatten Betriebssystem-unabhängig abläuft. Ein Fehler im Betriebssystem hat also keine Auswirkungen auf die gepspeicherten Daten. Man kann nur die Daten verlieren, welche noch nicht vom Controller auf die Festplatten geschrieben wurden. Aber auch das kann man verhindern. Mit sogenannten BatteryBackupUnits (Batterien welche direkt am Controller angeschlossen werden) kann man auch bei Stromausfall einen Datenverlust vermeiden.

Das Betriebssystem sieht je nach Konfiguration auch nur den “virtuell” angelegten Raid-Verbund. Auf einzelne Festplatten kann das Betriebssystem nicht zugreifen. Bei Software-Controller ist dies anders. Hier sieht das Betriebssystem sowohl den Raid-Verbund, als auch die einzelnen Festplatten.

Gute Controller bieten auch noch dieverse Einstellungsmöglichkeiten für die Wartung bzw. für Fehlerfälle. Richtig entspannen kann sich der Admin, wenn  der Controller im Fehlerfall Emails versenden kann. So hab ich schon von 2 Server mitbekommen, das eine Festplatte ausgefallen war. Im Normalfall hätte ich das sonst nie mitbekommen. Der Controller läuft im Raid5 auch mit 2 von 3 Festplatten weiter. Es ist halt nur langsamer. Server runterfahren, Festplatten tauschen und wieder hochfahren. Das ist alles was ich tun mußte. Den Rest erledigt der Controller selber.

Und welchen Controller nehmen wir nun? Ich persöhnlich bevorzuge Controller von 3ware. Diese laufen sehr gut unter Linux und unter Windows. Von Linux (zumind. von opensuse) werden sie problemlos erkannt. Einen Treiber muß man nicht extra kompilieren. Alles in allem sind leider sogar die relativ hohen Preise bei ebay für 3ware Controller gerechtfertigt. Dafür hat der Admin halt weniger Arbeit und Stress.

Datenrettung von kaputten Festplatten

2. Juni 2009 // Posted in Datenrettung, Linux, Windows (Tags: , , , , , ) |  No Comments

Irgendwann passiert es jedem. Die Festplatte streikt. Entweder es sind einfach ein paar Daten-Dateien kaputt oder  Windows startet gar nicht mehr. Festplattendiagnose-Programme wie die Seatools oder Windows-Programme wie chkdsk melden immer mehr Fehler. Es kann sogar sein das die Festplatte nur noch klickende Geräusche von sich gibt und gar nicht mehr anläuft. Falls die Festplatte gar keine Geräusche mehr von sich gibt und der Motor nicht mehr anläuft ist mit großer wahrscheinlichkeit die Platine der Festplatte defekt.

Für den Fall, das man eine hundertprozentig baugleiche Festplatte hat, kann man einfach die Platine tauschen. Ansonsten kann man die Festplatte nur wegschmeissen und die Daten abschreiben oder viel Geld (geht glaube ich ab 1000€ los…) für eine Datenwiederherstellung an entsprechende Firmen zahlen.

Einen Geheimtip habe ich für den Fall, das die Festplatte anläuft aber nur klickende Geräusche von sich gibt. In 3 Fällen konnte ich mittels einer fast kompletten Dose Kältespray die Daten von der Festplatte doch noch lesen. Ich weiß nicht was das Kältespray bewirkt. Einen Versuch ist es aber auf jedenfall wert. Vor allem bei wichtigen Daten. Eine Dose Kältespray kostet zwischen 10 und 20€ und damit ein Bruchteil der Kosten eines Datenverlustes oder der Beauftragung einer Spezialfirma zur Datenwiederherstellung.

Läuft die Festplatte normal an und Windows bricht an unterschiedlichen Stellen immer wieder ab oder fährt sich fest, dann hat man mit einer Linux-Recovery-CD noch gute Chance an die Daten ran zu kommen. Windows würde beim Zugriff auf einen defekten Datenträger hängen bleiben oder man kann einfach keine Daten kopieren. Eine Linux-CD (z.B. Knoppix) hat hier den Vorteil das man direkt einzelne Dateien rauskopieren kann. Eine Datein, welche auf defekten Festplatten-Sektoren liegt kann aber auch Linux nicht kopieren. Vielleicht hilft Kältespray, aber meistens kommt jede Hilfe zu spät. Man sollte also immer an ein Backup auf eine Extra-Fesplatte denken.

Kleiner Tip zur Aufallsicherheit von Festplatten findet Ihr hier. Leider ist der Artikel kostenpflichtig aber sehr interessant (nein ich werde nicht vom Linux-Magazin gesponsert). Aufgrund des Artikels kann ich jedem nur zu einem regelmäßigem Backup raten und von Desktop-Festplatten sollte man Abstand nehmen. Gerade für PC-Freaks oder Highend-Anweder lohnen sich die Mehrausgaben. Enterprise-Festplatten haben nicht nur eine längere Haltbarkeit. Sie haben auch eine deutlich längere Garantie und aus eigener Erfahrung kann ich sagen das bei Western Digital-Festplatten der Austausch ganz problemlos verläuft.

quellen: seagate.com, linux-magazin.de, knoppix.org

ssh absichern (mit iptables, ssh-blacklist, chroot)

1. Juni 2009 // Posted in Linux, Security, chroot, iptables, openssh (Tags: , , , , , , , , , , , ) |  No Comments

SSH ist im Prinzip DAS Werkzeug um einen Linux-Server zu administrieren oder Daten über das Netzwerk zu kopieren. Durch die weite Verbreitung ist es aber auch zum Ziel von Hackern/Crackern o.ä. geworden. Geknackte Linux-Server werden dann meistens als Command & Control-Server für Bots benutzt. Einige Provider von Root-Server sind inzwischen dazu übergegangen einen geknackten Server komplett zu sperren und nur noch SSH zuzulassen. Der Server-Besitzer/-Admin kann dann in Ruhe den Server säubern oder die Daten sichern und ihn neu aufsetzen. Auch wenn das für den Webseiten-Betreiber ärgerlich ist, ist es denoch richtig, da jeder geknackte Server eine Gefahr für andere PC’s darstellt.

Früher wurde entweder mit einer Wörterliste bzw. einer Brute-Force-Attacke und dem root-Account der Server versucht zu knacken. Inzwischen werden auch von Bots gesammelte Nutzerdaten bzw. verteilte Bot-Netz-Angriffe beim knacken von SSH-Server benutzt. Das heißt, ein Bot probiert 3 Passwörter aus und meldet das Ergebnis an den Command & Control-Server. Der nächste Bot probiert dann andere Passwörter usw…. Das macht es schwierig solche Angriffe per Blacklist abzuwehren.

Die einfachste Möglichkeit Angriffe zu erschweren ist den SSH-Port auf einen anderen Port zu ändern. Die Ports oberhalb von 40000 oder 50000 werden selten gescannt. Wer macht sich schon die Arbeit alle 65535 Ports eines einzigen Servers mit einem Portscanner zu scannen. Hierbei sollte man aber eins beachten. Falls man sich aus anderen (Firmen-)Netzen auf diesen Server per SSH verbinden will, dann muß dieser Port auch freigegeben sein. Falls dies nicht möglich ist, hat man praktisch keine andere Wahl, als den Standard-Port 22 zu benutzen.

Als nächstes kann man root mit “DenyUsers root” komplett von ssh aussperren. Vorher muß man natürlich einen alternativen Account anlegen UND testen!!!. Bei der Wahl des Benutzers kann man der Phantasie freien Lauf lassen. Er darf nur kein Standard-Benutzer bzw. ein Standard-Passwort sein. Ausgefallene Benutzernamen erschweren Angriffe erheblich. Mit “AllowUsersBenutzernme” kann man openssh noch anweisen, nur diesen einen Benutzer zuzulassen.

Als nächstes können wir mit ChrootDirectory den Benutzer noch in ein Change-Root einsperren (ich weiß, jetzt wirds paranoid). Das hat aber einen ganz wichtigen Hintergrund. Wenn man das Chroot mittels Bash (.bashrc,bash.bashrc und profile) soweit einschränkt das der User quasi nichts mehr machen kann außer einloggen und ausloggen, dann ist das ideal für einen Remote-Zugriff per TCP-Forwarding. Selbst wenn der Account gehackt wird, kann der Angreiffer nichts machen und er muß erstmal rausfinden, ob TCP-Forwarding funktioniert und wohin überhaupt. Das Chroot-Direktory kann man noch auf eine extra-Partition packen und diese ro(read-only) mounten. UmTCP-Forwarding zu aktivieren muß einfach “AllowTcpForwarding yes” in die ssh-Daemon-Konfiguration eingetragen werden.

Weitere wichtige Einstellungen:

  • PermitRootLogin – der User ist mit DenyUsers zwar schon ausgesperrt, aber es schadet nichts das auch auf no zu setzen
  • Protocol – sollte unbedingt auf 2 gesetzt werden
  • UseDNS – aus Performancegründen würde ich das auf no setzen
  • TCPKeepAlive – falls man immer länger auf dem Server arbeitet auf yes setzen
  • HostbasedAuthentication – unbedingt auf no setzen
  • PrintMotd – auf no setzen, da der Angreifer sonst auch ohne Login Daten über Architektur/Betriebssystem sieht
  • PrintLastLog – falls man nur alleine auf dem Server arbeitet egal, aber falls mehrere Benutzer sich einloggen können würde ich es aus Datenschutzgründen abstellen.
  • Strictmode – auf yes setzen
  • MaxAuthtries – ich habs auf 3 gesetzt
  • MaxStartups – hab ich auf 6 gesetzt
  • Subsystem Sftp kann man löschen oder mit # auskommentieren

Als letztes installieren wir noch sshblack. Hierbei handelt es sich um ein Perl-Script, welches eine Liste über fehlgeschlagene Logins führt und bei einem einstellbaren Schwellenwert die IP des Angreiffers für einen frei einstellbaren Zeitraum mittels iptables sperrt. Hierfür muß aber eine iptables-Firewall installiert bzw. eingerichtet werden. (dazu werde ich später noch etwas schreiben)

Jetzt wird sicher der eine oder andere sagen, man kann doch einen SSH-Server auch mit Zertifikaten absichern. Das ist vollkommen richtig. Das Problem dabei ist aber, das man dann nicht mehr von überall auf der Welt draufzugreifen kann. Ein Freund war mal in Indonesien und er hatte einen ping von etwa 500ms. Daran scheitert eine SSH-Verbindung. Nur mit einen Passwort funktioniert das Login aber. Man muß sich also fragen ob man nur aus Deutschland auf den Server zugreifen will oder von überall. In der oben beschriebenen Konfiguration ist der SSH-Server auch nur für TCP-Forwarding ausgelegt.

Man könnte also einen zweiten SSH-Server hinter den geschützen Server aufstellen oder auf der lokalen IP-Adresse 127.0.0.1 installieren und dann über TCP-Forwarding darauf zugreifen. Normale User, welche nichts auf irgendeinem Server per ssh zu suchen haben können so auch sicher remote ihre Mails abrufen. Ich würde z.B. eine Exchange-Server oder Lotus-Domino-Server nie direkt an’s Internet anschliessen, aber das ist Ansichtssache.