Update 28. Feb 2014: Mittlerweile wird durch ein yum update automatisch auf CentOs 6.5 upgedated.
Mehr als kleine Erinnerung für mich selbst beschreibe ich hier, wie ein einfaches, aber abgesichertes LAMP-System eingerichtet wird.
(Wenn man statt MySQL lieber PostgreSQL installiert, dann führt dieser Weg dorthin)
Unser Ziel ist eine funktionierende LAMP-Umgebung, auf die dann je nach Bedarf ausgebaut werden kann.
Als Betriebssystem verwende ich CentOS, derzeit in der Version 6.4, und auch nur damit sind die folgenden Anweisungen getestet.
Der Ausgangspunkt ist eine CentOS 6.4 Minimalinstallation, die man auf verschieden Weise bewerkstelligen bzw. von verschiedenen Quellen beziehen kann. Darauf gehe ich hier nicht ein und setze eine funktionierende Erstinstallation voraus. In der Folge werde ich auch nicht alle Schritte bis ins letzte Detail erklären. Es gibt ausreichend Dokumentation zu allen Bereich im Internet und dieser Post soll nur eine Gedächtnisstütze sein und kein Lehrgang. Ich kann nur empfehlen, sich über alle Schritte – wenn nicht klar ist, warum sie gesetzt werden, oder die Implikationen, die sich daraus ergeben – zu informieren.
Ein Linux-System sollte niemals via copy’n’paste aus einem Tutorial aufgesetzt werden. Es ist wichtig zu verstehen, warum etwas gemacht wird. Dies würde allerdings den Rahmen dieses Posts sprengen!
Wir haben also ein laufendes System mit nur einem Benutzer – root. Ob der Zugriff am Server selbst oder über ein Terminal erfolgt, ist unerheblich, Vorraussetzung ist natürlich, daß das grundlegende Netzwerk läuft. Es schadet sicherheitshalber aber nicht, auch Direktzugriff zu haben, wenn man insbesondere bei der Firewall etwas vergeigt. Im Grund reicht es aber, den Server remote neu starten zu können.
Legen wir also los:
Zuerst installieren wir uns drei Tools, die wir auf jeden Fall immer benötigen werden: vim (OK, vi ist an Bord und täte es auch, aber ich bin vim gewöhnt) , wget und man. Statt vim kann es natürlich auch zB nano sein – irgend ein Editor halt, den ihr gewöhnt seid.
yum install -y vim wget man
Nun schalten wir SELinux aus – ein Server braucht das eher weniger:
in /etc/selinux/config setzen wir
SELINUX=disabled
Nun sollten wir rebooten (nur so wird das wirksam), zuvor nehmen wir aber noch ein paar Änderungen am Netzwerk vor.
Als Entrümpelungsmaßnahme entfernen wir IPv6, es gibt zur Zeit keine brauchbaren Tools dafür:
Mit
ip addr
sehen wir erst einmal, ob IPv6 überhaupt aktiviert ist.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether c8:60:00:be:44:00 brd ff:ff:ff:ff:ff:ff
inet 5.9.59.15 peer 5.9.59.1/32 brd 5.9.59.31 scope global eth0
inet6 fe80::ca60:ff:febe:4400/64 scope link
valid_lft forever preferred_lft forever
Weg damit:
Wir legen eine Datei in /etc/modprobe.d an und nennen sie zum Beispiel disable-ipv6.conf.
In diese schreiben wir
install ipv6 /bin/true
in /etc/sysconfig/network fügen wir folgende Zeilen hinzu – bei der Gelegenheit sollten wir auch gleich unseren Hostnamen setzten, soferne noch nötig. Alle andere Zeilen (DHCP etc) sollten bei der Installation schon richtig gesetzt worden sein.
HOSTNAME=yourhost.yourdomain.tld NETWORKING_IPV6=no IPV6INIT=no
Bevor wir nun einen Reboot ausführen – SELinux ist ja noch nicht deaktiviert und die Netzwerkänderungen wollen aktiv werden – ist dies ein guter Zeitpunkt, erst einmal ein generelles Update zu machen – je nach Quelle ist die Minimalinstallation ja nicht unbedingt ganz auf der Höhe. Daher folgt nun ein
yum -y update
und nun booten wir erst einmal neu – sicherheitshalber schalten wir vorher noch die Firewall aus, um auf jeden Fall wieder remote einloggen zu können.
service iptables stop; reboot
(Für die Änderung am Netzwerk würde auch ein init 3 gereicht haben, übrigens.)
Edit: Ich arbeite gerade an einer Centos 6.4 minimal Installation, wo die Firewall nicht aktiviert war, da hilft auch service iptables start nicht. In diesem Fall muß man die Firewall erst generell aktivieren. Hierzu gehen wir folgendermaßen vor:
Falls es nicht installiert installiert sein sollte:
yum install system-config-firewall-tui
Dieses Tool starten wir nun mit
system-config-firewall-tui
und erhalten eine simple GUI
Mittels <LEERTASTE> aktivieren wir die Firewall, unter Anpassen können wir gleich einen Eintrag für SSH durchführen lassen.
Schließen-OK-Ja und die grundsätzliche Firewall-Aktivierung ist durchgeführt. (Nun nicht vergessen, sicherzustellen, daß der iptables Dienst vorerst deaktiviert bleibt – s.o.)
Fahren wir mit SSH fort – dem einzigen Zugang zu unserem Server, der daher besonders sicher sein soll.
Wir werden den Port von SSH ändern, den Superuser ausschließen, eine eigene Berechtigungsgruppe anlegen und überhaupt nur Authenitifikation über Schlüssel zulassen.
Das hat eventuell den Nachteil, dass man von unterwegs, sofern man nicht ein eigenes Gerät mit gültigem Schlüssel hat, nicht einloggen kann. In meinem Fall ist dies aber OK und es bleibt jedem selbst überlassen, wie dicht er seinen SSH-Zugang macht.
Bisher hatten wir nur den Superuser root, nun legen wir einen Arbeitsuser an –
useradd username
und weisen ihm ein Passwort zu:
passwd username
Nun müssen alle Schlüssel von den Geräten, mit denen eingeloggt werden soll, kopiert werden, zuvor brauchen wir aber die Struktur im Heimatverzeichnis des Benutzers:
mkdir ~/.ssh cd ~ chmod 0700 .ssh touch .ssh/authorized_keys chmod 0600 .ssh/authorized_keys
Nun müssen von allen Geräten, von denen auf den Server eingeloggt werden soll, die öffentlichen Schlüssel kopiert werden. Dies beschreibe ich aber hier nicht weiter.
Nun sollte man versuchsweise – unter Beobachtung von /var/log/secure – einen Login-Versuch machen und sehen, ob es funktioniert. Normalerweise sind hier keine Probleme zu erwarten.
Nun wollen wir den Port ändern und bestenfalls einen möglichst hohen wählen – Portscanner beginnen normalerweise mit 1 bzw. mit einer Liste typischer Ports, je höher die Nummer, desto länger dauert es und dem Einbrecher wird langweilig – einem Script natürlich nicht, aber das bricht vielleicht wegen timeout ab, wie auch immer…
vim /etc/ssh/sshd_config
Finde die Zeile
#Port 22
entkommentiere sie und ändere die Portnummer:
Port 12322
Bevor wir den SSH daemon neu starten, führen wir weitere Maßnahmen durch:
Wir legen eine Gruppe – zB sshusers – an und fügen unseren Arbeitsuser der Gruppe hinzu.
groupadd sshusers usermod -a -G sshusers <username>
In /etc/ssh/sshd_config ändern wir noch folgendes (finde und entkommentiere/ersetze oder füge hinzu, falls nicht vorhanden)
PermitRootLogin no MaxAuthTries 1 PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys UsePAM no PasswordAuthentication no KerberosAuthentication no GSSAPIAuthentication no AllowGroups sshusers MaxStartups 2
Nun entfernen wir noch die aktuellen host keys
rm -f /etc/ssh/ssh_host*key*
und starten endlich den sshd (service sshd restart) neu. Sinnvollerweise lassen wir unser Terminal offen und versuchen einen neuen Login in einem weiteren Terminal, falls es nicht funktioniert, haben wir immer noch unser altes. Es sollte aber alles funktionieren soweit. (Nicht vergessen, der Port ist geändert, dies muß dem SSH client mitgeteilt werden ( -p 12322).
Versuche auch, mit root einzuloggen, es sollte nicht funktionieren.
Nun haben wir also einen einigermaßen sicheren SSH Zugang, aber die Firewall läuft noch nicht. Bei einer normalen Installation von CentOS 6.4 minimal sollte eine Zeile für SSH angelegt worden sein. Wir öffnen
/etc/sysconfig/iptables
und ändern die Portnummer.
Simpel sieht die Zeile so aus:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 12322 -j ACCEPT
Nun starten wir die Firewall und wenn wir Glück haben, sollten wir immer noch auf der Konsole arbeiten können. Nunja, mit Glück hat es weniger zu tun, aber die Fälle, wo man sich durch eine Fehlkonfiguration der FW aus einem System gesperrt hat, sind Legion. Bei einem lokalen Rechner ist das nicht weiter tragisch, problematischer wird es bei einem Server, wo man nicht lokal einloggen kann. Zumindest die Möglichkeit, den Server aus der Ferne zu Resetten sollte aber gegeben sein, und hier würde sich empfehlen, Änderungen an der FW nicht in /etc/sysconfig/iptables zu machen, sondern von der Kommandozeile aus. Wenn dann was schiefgeht, kann man immer noch rebooten und hat die FW im alten Zustand, soferne man nicht mittels service iptables save die Änderungen gespeichert hat. Hierzu werde ich vielleicht später einmal einen eigenen Post schreiben.
Nun ist also SSH relativ dicht und die FW werkelt auch, kommen wir nun zu einem gerne übersehenen, aber für alle möglichen Dinge – wie zum Beispiel Logdaten – nicht ganz unwichtigem Punkt.
Die Serverzeit:
Wir installieren den ntp daemon – einfach mit
yum -y install ntp
und schalten ihn ein
chkconfig ntpd on
Nun synchronisieren wir die Zeit mittels
ntpdate pool.ntp.org
oder, wenn ihr einen anderen Zeitserver verwenden wollt, nehmt den.
Nun noch den daemon starten und nie mehr zu spät kommen 🙂
service ntpd start
Nunmehr ist es Zeit, sich ein wenig dem AMP zu widmen. Es ist vorerst nicht unbedingt nötig, aber für einen weiteren Ausbau meist unerläßlich, einige zusätzliche Repositories anzuzapfen, daher werden wir dies zu allererst erledigen.
Ich verwende gerne epel und rpmforge, obwohl es da manchmal zu Konflikten kommen kann (die aber in den Repo-Settings behandelt werden können), daher werden diese nun eingerichtet. Die Links und Versionen sind mit Zeitpunkt der Veröffentlichung dieses Posts gültig, das kann sich natürlich mittlerweile geändert haben…
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm rpm -ivh rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm
rpm --import https://fedoraproject.org/static/0608B895.txt wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm rpm -ivh epel-release-6-8.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm rpm -Uvh remi-release-6.rpm
Das Remi Repo muß noch in /etc/yum.repos.d/remi.repo ‘enabled=1’ werden.
Ich gebe Epel den Vorzug vor CentOS base, am einfachsten geht das mit Prioritäten:
yum install yum-priorities
Wir editieren /etc/yum.repos.d/epel.repo und fügen eine Zeile
priority=10
der
Nun machen wir noch einmal ein
yum update
es sollte sich dabei nicht viel tun allerdings,
Nunmehr installieren wir die Developer Tools. Manche werden meinen, das würde doch ein gewisses Sicherheitsrisiko bergen, aber erstens geht es ohne schwer und zweitens, wenn einer Zugang zu unserem Server erlangen würde, könnte er das auch selbst tun, daher…
yum groupinstall 'Development Tools'
Nun endlich installieren wir unseren AMP:
yum install httpd mod_ssl mysql-server php php-mysql
Wie ihr bemerkt, habe ich hier nur einen PHP Minimalstack installiert. Alle weiteren Module werden dann je nach Bedarf hinzugefügt. So hält man die Sache schlank.
Wir schalten Apache und MySQL ein
chkconfig httpd on chkconfig mysqld on
Bevor wir Apache starten, sollten wir in /etc/httpd/conf/httpd.conf den ServerName an unseren Hostname anpassen und eine gültige ServerAdmin Emailadresse eingeben – alle weiteren Einstellungen hängen von Einsatzzweck des Servers ab.
Nun starten wir den Indianer und sehen uns mal im Browser an, ob er richtig ums Lagerfeuer tanzt. Und, nanu, es funktioniert nicht – kann auch nicht, weil unsere Firewall es verhindert. Wir müssen sie also für die Ports 80 und 443 öffnen.
Wie wir besprochen haben, führen wir die Änderung erst einmal auf der Konsole aus, damit wir nichts permanent kaputt machen.
Vorher sehen wir uns aber erst einmal die aktuellen Einstellungen an.
iptables -L --line-numbers -n -v
Wir sollten etwa so etwas bekommen
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 6143 8434K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 3 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 4 1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:12322 5 1635 211K REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 4561 packets, 324K bytes) num pkts bytes target prot opt in out source destination
Da sind also drei Ketten (Chains), INPUT, FORWARD und OUTPUT. Zu iptables könnte manwiederum Romane schreiben, hier nur ein paar Infos und Google ist Euer Freund (Yahoo & Co natürlich auch).
Wichtig zu wissen ist, daß dies eine sehr einfache Firewall-Konfiguration ist (und jede Menge Leute daran herummeckern würden, denke ich mal). Sie funktioniert aber einwandfrei und mehr braucht es vorerst nicht.
In der INPUT Kette sehen wir, übersetzt, folgendes:
1: alle Verbindungen von allen Quellen zu allen Destinationen durch alle Protokolle – also ALLE, die bestehen (ESTABLISHED), oder ‘mit einer anderen Verbindung in Beziehung (RELATED) stehen’ – das kommt zB bei FTP vor und ich will hier nicht näher darauf eingehen, sind zugelassen.
2: alle ICMP Requests werden bedient – einfachstes Beispiel, es wird auf einem remote Ping geantwortet. Es gibt eigentlich keinen Grund, so etwas nicht zuzulassen, aber man kann im Rahmen der Diskussion, wie man seinen Server am besten ‘unsichtbar’ macht, wohl darüber diskutieren. Ich bin kein Freund von DROP, aber dazu später.
3: alle internen Verbindungen sind erlaubt – Wenn die daemons sich über lo unterhalten wollen, dann sollen sie doch…
4: Das ist die Regel, durch die wir mit dem SSH-Client von der Ferne eine neue Verbindung aufmachen dürfen. Man könnte hier noch eine oder mehrere fixe IPs eintragen, von denen man einloggen darf, bei mir ist das unpraktisch, daher lasse ich es.
5: Alles andere wird abgelehnt. Punkt
Die FORWARD Kette läßt ganz einfach nichts durch, wo wir weder Ursprung noch Ziel sind – wir sind kein Relay von irgendwas, also kein Durchhaus, wo jeder nach belieben durchlatschen darf. Immer erinnert, daß dies ein LAMP-Server sein will und nichts anderes. Man könnte in der Policy auch DROP verwenden und würde sich die Regel sparen, aber ich finde, lieber aktiv verweigern als still unter den Tisch kehren.
OUTPUT hat gar keine Regeln, wir lassen alles raus – (policy ACCEPT) hat das zu verantworten.
Nun ist es aber an der Zeit, unserem Indianer das Tipi aufzusperren.
Wir wollen das nun einmal nicht in der Konfigurationsdatei bearbeiten, sondern erst einmal von der Konsole die Regeln hinzufügen:
iptables -I INPUT 4 -m state --state NEW -p tcp --dport 80 -j ACCEPT iptables -I INPUT 4 -m state --state NEW -p tcp --dport 443 -j ACCEPT
Die Regeln in den einzelnen Chains werden hintereinander abgearbeitet, bis eine zutrifft. Diese wird dann ausgeführt und Schluß. Daher ist es auch wichtig, hier keine Regel einfach anzufügen, sondern wir schieben sie hinein, zumindest vor die Regel, die in unserer INPUT chain alles verwirft. Sonst kommen diese neuen Regeln nämlich nie zum Zuge und das Kriegsbeil wird ausgegraben.
Im Browser sollte nun die freundliche Apache 2 Test Page zu sehen sein, sowohl unter http:// als auch unter https://. Ein temporäres Server Zertifikat wurde bei der Installation freundlicherweise gleich mitgeliefert.
Übrigens: HTTP ist ein zustandsloses Protokoll, daher macht es keinen Sinn, die FW-Regeln für bereits etablierte (ESTABLISHED) Verbindungen einzurichten.
Wenn nun alles funktioniert, speichern wir die hinzugefügten Firewall-Regeln ab, die sind sonst nämlich nach dem nächsten Start wieder verschwunden.
service iptables save
Im Wesentlichen war’s das, was uns vielleicht noch fehlt, ist ein wenig logging. Wir wollen ja schließlich wissen, was unsere Fierewall so macht. Wir legen eine neue Chain LOGGING an und verschieben den INPUT REJECT (den von FORWARD gleich mit) nach LOGGING.
Nun allerdings ohne weiteren Kommentar ist hier die nach dieser Aktion gültige Konfigurationsdatei:
*filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [133:26943] :LOGGING - [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 12322 -j ACCEPT -A INPUT -j LOGGING -A FORWARD -j LOGGING -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " -A LOGGING -j REJECT --reject-with icmp-host-prohibited COMMIT
Was hier passiert ist, daß einfach die letzte Zeile der INPUT-Chain, sowie die FORWARD-Chain, die ja beide den Zugriff blocken sollen, zuerst zur LOGGING-Chain weitergereicht werden. Die LOGGING-Chain schreibt alles, was sie dargereicht bekommt, ins Protokoll und weist dann die Anfrage zurück. Anfragen, die vorher von einer der anderen INPUT-Regeln mit wohlwollen durchgelassen wurden, kommen hier natürlich nicht an und damit auch nicht ins Log.
Wird jetzt die Firewall gestartet, loggt sie nach /var/log/messages – das wollen wir noch ändern!
vim /etc/rsyslog.d/iptables.conf
Dort kommt folgende Zeile hinein:
:msg, contains, "IPTables-Dropped: " -/var/log/iptables.log
und den Logger mit
service rsyslog restart
neu starten. Klar, was passiert, oder?
Ein Log-File will sich drehen, wir brauchen Rotation. Die sollten wir für jedes neue Logfile immer einrichten, damit nicht irgendwann einmal (in 10 Tagen/Monaten/Jahren oder so) plötzlich kein Platz mehr auf der Platte ist, oder die Datei korrupt oder sonstwas passiert.
Eine neue Konfigurationsdatei für logrotate muß also her:
vim /etc/logrotate.d/iptables
da hinein kommt
/var/log/iptables.log {
missingok
notifempty
rotate 4
weekly
size 30k
nocompress
create 0600 root root
}
Man lese man, wenn man mehr darüber wissen möchte 😉
Ein weiteres nettes Tool zur Absicherung des Servers ist fail2ban.
fail2ban – um es kurz zu machen – blockiert IP-Adressen, von denen zu oft in zu kurzer Zeit versucht wird, sich erfolglos zB via SSH einzuloggen. Dies kann passieren, wenn man sein Passwort vergessen hat (schlecht), überhaupt erst das Einloggen mittels Passwort statt Keys erlaubt (noch schlechter) oder ein übelwollender Mensch versucht, Kontrolle über unseren Server zu bekommen (weniger schlecht, weil wir erwischen ihn mit fail2ban).
Die Installation ist denkbar einfach. Da wir schon das Epel Repo eingerichtet haben, machen wir das mit yum:
yum install fail2ban
Zwischendurch mal ganz allgemein zu yum: Mit der Option -y kann man übrigens eine Installation ohne weitere Zwischenabfragen durchführen, auch wenn bei der Installation erst noch andere Pakete installiert werden müssen, von denen das eigentliche Paket abhängt. Ich verwende es nur in den wenigsten Fällen, weil ich mir doch lieber gerne erst ansehe, was denn da auf die Platte kommen soll.
Zurück zu fail2ban. Nach der Installation ist ein wenig Konfiguration angesagt. Die Konfigurationsdateien befinden sich unter /etc/fail2ban/
Der daemon selbst wird in der Datei fail2ban.conf konfiguriert. Hier gibt es nicht allzuviel zu tun, im Grunde braucht man es gar nicht angreifen. Was ich vorzugsweise ändere ist der Ort für die logs. Standardmäßig (Version 0.8.10) ist das der SYSLOG, ich hab lieber ein eigenes Logfile, daher ändere ich das logtarget.
logtarget = /var/log/fail2ban.log
Wo ein Log da Rotation, wir erinnern uns.
Nun zur Konfiguration der Regeln, nach denen fail2ban seine Mauern aufzieht.
Diese findet man unter /etc/fail2ban/jail.conf
Die einzelnen Einträge sind ziemlich selbsterklärend, wichtig ist der Teil [ssh-iptables], der normalerweise in der Konfigurationsdatei schon enthalten ist.
Hier ein Beispiel:
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=12322, protocol=tcp]
sendmail-whois[name=SSH, dest=root, sender=fail2ban@your.server.com]
logpath = /var/log/secure
maxretry = 5
Wichtig ist, die zuvor geänderte Portnummer von ssh – in unserem Beispiel 12322 – zu verwenden. Die Email-Adresse, die als Absender für Meldungen verwendet wird, kann man auch noch ändern.
Dabei wollen wir es belassen, natürlich kann fail2ban viel mehr, aber fürs Erste reicht uns das, die Hauptarbeit muß ohnehin die Firewall erledigen.
Nun stellen wir sicher, daß fail2ban auch immer brav startet
chkconfig fail2ban on
und starten den daemon auch gleich.
service fail2ban start
Und was, wenn man sich mal selbst mit fail2ban ausgesperrt hat. Hier ist die Lösung.
In der jail.conf gibt es, falls das jemandem aufgefallen ist, einen Eintrag dest=root. Das bedeutet nichts anderes, als das fail2ban seine Fehlermeldungen an den lokalen Benutzer root schickt. Nicht nur dieser Dienst macht das, auch andere verwenden lokale Adressen.
Da wir nicht jedesmal umständlich in den lokalen Postfächern nachsehen wollen, hier kurz ein Ausflug zu Aliases, dem lokalen Adressbuch. Es befindet sich in /etc/aliases. Sieht man sich diese Datei an, stellt man schnell fest, das fast alles auf root umgeleitet wird. Nun wollen wir root selbst auf eine echte Email-Adresse, die wir auch bequem in unserem Desktop-Client lesen können, umleiten. Hierzu fügen wir einfach ganz unten eine Zeile ein, die auf diese Adresse deutet.
# Person who should get root's mail root: webmaster@deinedomain.eu
Abspeichern und fertig.
Jetzt sollten wir einmal ein paar PHP Einstellungen vornehmen, die einfach sein sollen.
Die php.ini befindet sich in /etc/php.ini und wir ändern hier
date.timezone = Europe/Vienna (oder was immer euch am nächsten kommt) log_errors = On error_log = /tmp/php_errors.log (oder anderswo - wenn anderswo: Es muß für Apache schreibbar sein) display_startup_errors = On (oder auch nicht, je nach dem...) error_reporting = (was immer ihr für nötig haltet, aber verwendet es)
Apache neu starten!
Schließlich machen wir mysql noch ein wenig sicherer, mit den Einstellungen werden wir uns ansonsten hier nicht weiter beschäftigen, darüber kann man weitere 100 Seiten schreiben.
Erstmal mysql starten, wenn noch nicht geschehen:
service mysqld start
und nun einfach
/usr/bin/mysql_secure_installation
laufen lassen, für root ein schönes Passwort ausdenken und sonst brav immer Yes sagen.
Wenn auf mysql auch entfernt zugegriffen werden soll, muß in der Fierwall eine entsprechende Regel eingefügt werden.
Damit haben wir in aller Kürze ein grundlegendes LAMP-System eingerichtet, welches nun je nach Einsatzzweck ausgebaut werden kann.
Noch einmal ein Appell am Schluss: Macht niemals einfach copy’n’paste, denkt über das, was ihr macht, nach, lest in den man pages oder im Internet, damit ihr auch versteht, was ihr da tut. Dann ist das alles keine Hexerei und macht sogar Spaß.
Danke fürs Lesen und ich freue mich immer auf Kommentare!