zurück

Arktur schützen

allg. Überlegungen	spezielle Schutzgebiete	spezielle Dienste
	Schutz des Rechners Datensicherung Firewall, rootkits Spam-Schutz	Apache Samba Squid SSH SSH-Zertifikat Telnet, FTP usw.

allgemeine Überlegungen
```
Empfänger  : SCHUL-NETZ@LISTSERV.DFN.DE
Absender   : usenet-marcel at xcore.net  (Marcel Noe)

> http://www.netfilter.org/documentation/index.html
```
Ein Packetfilter (idealerweise auf einem eigenen Rechner, der sonst nichts anderes macht) schützt dich nur gegen Angriffe von aussen. Gegen innen hilft das nichts, wenn du nicht auch von innen filterst. Dann kannst du allerdings auch den entsprechenden Daemon entfernen. Ein per Firewall geschütztes System ist "Ein weicher Kern mit einer harten Schale", wie Tsutomu Shimomura einst meinte.
Die grundlegende Vorgehensweise beim Installieren eines Rechners sieht eigentlich immer so aus:
1. Vor der Installation:
  - Welches Betriebssystem setze ich ein?
    Linux? Solaris? BSD? Windows?
  - Welche Dienste möchte ich auf dem Rechner anbieten? Für wen?
  - Welche Hardware hab ich? Kann ich evtl. durch kleine Investitionen ein höheres Mass an Sicherheit gewährleisten (z.B. mehrere Netzwerkkarten, Einsatz von VLAN Technologie, Hardwarerouter mit Packetfilter)?
  - Besorgen der aktuellen(!) Version des jeweiligen Betriebssystems, der jeweiligen Distribution etc.
2. Partitionieren der Festplatte: Daran denken, dass man eigene Partitionen für Benutzer und Betriebssystem anlegt, so dass Scherze wie
```
dd if=/dev/zero of=/tmp/bla.out
```
  nicht dafür sorgen, dass keine E-Mails mehr verschickt oder keine Logfiles mehr geschrieben werden können.
3. Betriebssystem installieren. Bietet mir das Betriebssytem die Möglichkeit des Online-Updates?
  Wenn ja, dann dies gleich als Erstes mal ausführen (unter Debian gibt es so etwas wie security.debian.org, das ist SEHR praktisch).
  Wenn nicht, dann ALLE bisher vorhandenen Patches einspielen.
  Prinzipiell gilt: Packete vom Distributor sind gegenüber selbstkompilierte Programme zu bevorzugen, da man so auch in den Genuss von Patches vom Distributor kommt.
4. Unter Linux ist es nun Zeit, sich Gedanken über den Kernel zu machen. Grundsatz: Alles, was man nicht unbedingt braucht, fliegt raus.
  Wenn möglich: Loadable Module Support ausschalten.
  Unter Kernel Hacking die Optionen "check for stack overflows" und "Magic SysReq" Key aktivieren. Letzteres kann bei einer Kernel Panic nützlich werden.
5. (...)
6. Der Rechner sollte bis zu diesem Punkt KEINE Dienste AUSSER SSH anbieten. (Gegebenenfalls mit NMAP nachprüfen). Wenn SSH läuft, kann man sich eine gemütliche Workstation suchen und von da aus weitermachen.
7. Nun installiert man die Dienste, die man anbieten will. Danach richtet man den Packetfilter ein.
  Hier gilt der Grundsatz: Zuerst alles ablehnen.
  Dann die Dienste freischalten, die man für die Benutzung von aussen anbieten will.
  Tendenziell gilt es zu überlegen, ob man SSH von aussen anbieten will. Zum einen könnte es eine Sicherheitslücke sein, wenn Passwörter bekannt werden. Ausserdem stellt es einen weiteren Dienst da, der ein Loch haben könnte.
  Auf der anderen Seite ist es vielleicht doch nicht schlecht, sich von zuhause aus einloggen zu können, um nach dem Rechten zu sehen. Aus diesem Grund biete ich SSH mit DSA-Autentifikation auch nach aussen an.
8. (....)
Gruss Marcel
spezielle Schutzgebiete
1. Schutz des Rechners
  Der Server gehört in die Besenkammer.
  Wer den Hauptschalter umlegen kann, wer direkten Zugang zum Rechner hat, der kann Arktur beliebig verändern. Er kann sich z.B. vor den Sommerferien eine Hintertür einbauen und diese in den Sommerferien benutzen.
2. Datensicherung
  Der Server selbst (mit seinen Grundprogrammen) ist binnen 30 Minuten wieder installiert.
  Was Zeit kostet, das ist die Restauration der lokalen Einstellungen, das ist die Restauration des Fileserver-Verzeichnisses ("pub auf Arktur"), das ist die Restauration der Home-Verzeichnisse.
  Mindestens 1 Sicherung sollte im Tresor liegen, fernab vom Rechnerraum.
  Anleitung (Reinhold Dorn) (27.08.2007)
3. Firewall, Rootkit usw.
  Arktur ist nicht unüberwindlich. Aber viele beliebte Einflugschneisen für böse Buben lassen sich abdichten. Einige sind schon bei der Erst-Installation eingebaut, insbesondere der so beliebte "firewall".
  - Rootkit-Hinweise (02.08.2011)
  - Firewall:
    Arktur 3.4/3.6/5.x erlaubt, in eleganter Weise ganze Netzbereiche (z.B. Korea) per "iptables" abzublocken, mit der Datei
```
/etc/Schule/vollblock
```
    die von /etc/Schule/ipfilter-start eingebunden wird.
    Eine solche Blockade ist natürlich mit Vorsicht zu geniessen, wenn aus einem der blockierten Bereiche auch erlaubte Direktkontakte (z.B. per FTP) möglich sind.
  - Literatur:
```
http://medienzentrum-oberberg.de/seiten/arktur2.htm#chkrootkit
https://www.spenneberg.com/197.html
http://www.netfilter.org/documentation/index.html
http://www.hackerthreads.org/tutorials/securing_linux.php
Werner Dolle: "Rootkits" ("freeX" 5/2003 Seite 44 - 53 )
```
    Intrusion Detection System
4. Spam-Schutz
  Spam-Schutz bedeutet Eingriffe in Mail für andere Leute. Das ist also vor allem ein datenrechtliches Problem.
  Und auch Spammer sind erfinderisch; sie haben bisher noch jeden vermeintlichen Spam-Schutz umgehen können.
spezielle Dienste
- Apache
  - Datei
```
/etc/httpd/access.conf
```
    Im Prinzip: in jedem <directory xxx> ... </directory>-Block sollte stehen:
```
        order deny,allow
        # ist die Voreinstellung, schadet aber nicht
        # letzter Befehl gilt
        # also: erst mal alles verbieten, dann einige Ausnahmen erlauben
        # keine Leerzeichen beim Komma!

        deny from all
        allow from 127. 192.168. 10. 
        # Netzmaske geht auch: allow from 127. 172.16.0.0/255.240.0.0
        # "localhost" (127.) muss unbedingt eingetragen sein
```
    Dann ist der Apache erst mal nur fürs lokale Netz freigegeben. Er muss nach diesen Änderungen natürlich neu gestartet werden:
```
        /etc/init.d/apache stop
        /etc/init.d/apache start
```
    oder
```
	killall -HUP httpd
```
    Und nach wenigen Minuten sollte geprüft werden, ob er die Änderungen überhaupt angenommen hat:
```
        pgrep -l httpd
```
    sollte mehrere Nummern liefern.
  - René Maroufi hat eine ausführliche Anleitung für den Schutz von Webseiten geschrieben.
- Samba
  Datei
```
/etc/samba/smb.conf
```
  Abschnitt
```
[global]
```
  vor der "include"-Zeile!
  
  Zugriff von draussen abblocken:
```
	hosts allow = 127., 192.168.
	# weitere lokale Netze:	10. 172.16.0.0/255.240.0.0
```
  Wer auch nachlesen will, welcher Rechner sich wann eingeloggt hat:
```
	log file	= /var/log/samba/%m.log
```
  Das Verzeichnis "/var/log/samba" muss natürlich existieren; anzulegen
  - mit dem "midnight commander" mc (Taste f7) oder
  - ```
  mkdir -p /var/log/samba
```
"samba" muss nach diesen Änderungen neu gestartet werden (weil im Abschnitt [global] geändert wurde):
```
          /etc/init.d/samba stop
          /etc/init.d/samba start
```
oder
```
  	killall -HUP smbd
  	killall -HUP nmbd
```
Prüfung auf syntaktische Richtigkeit:
```
  	testparm -s
```
- Squid
  Datei
```
/etc/squid/squid.conf.in
```
  sowie
```
/etc/squid/allowed_clients
```
  In "allowed_clients" stehen die erlaubten IP-Adressen; Vorgabe: komplette Bereiche.
  In "squid.conf.in" stehen die Vorgaben für "squid.conf", die bei jedem Start des "squid" erneut übernommen werden.
  
  Zugriff nur lokal: in "squid.conf.in" nach "Allow everything else" suchen, in der Zeile darunter abändern:
  statt
```
	http_access allow all
```
  neu
```
	http_access deny all !allowed_hosts
```
  "allowed_hosts" ist an dieser Stelle richtig - "allowed_clients" wäre falsch. Ausführlicher zu ergründen beim intensiven Studium der "squid.conf.in"
  Der "squid" muss nach diesen Änderungen natürlich neu gestartet werden:
```
        /etc/init.d/squid stop
        /etc/init.d/squid start
```
  oder
```
	squid -k reconfigure
```
  Kontrollen:
  - beim Neustart dürfen keine Fehler gemeldet werden
  - ```
  pgrep -l  squid
```
  muss eine Zahl zurückgeben (der Zahlenwert ist egal)
- ```
squid -X > /home/tmp/squidconf.log 2>&1
```
    Die Ergebnisdatei kann dann unter Linux in "/home/tmp" angeschaut werden.
- SSH
  
  "ssh" sollte (natürlich) nur entweder als Dämon oder aber per "inet"-Dämon laufen;
  - wenn
```
pgrep -l sshd
```
    eine Zahl liefert, dann muss der entsprechende "ssh"-Eintrag in "/etc/inetd.conf" per Kommentarzeichen ausgeblendet werden.
  Wer seinen Rechner (z.B. wegen des noch kostenlosen T@School-Zugangs) ununterbrochen am Netz lässt, der sollte einerseits (z.B. per TCP-Wrapper) für "root" den Zugang per "telnet" aus dem Internet blockieren, er sollte andererseits auch für "root" den direkten Zugang von draussen blockieren.
  Gelegentlich laufen (z.B. aus fernöstlichen Ländern) Automaten, die u.a. versuchen, als "root" mit simplen Passwörtern den Zugang zu schaffen.
  - "root" darf sich nicht per "ssh" einloggen
    Datei "/etc/ssh/sshd_config"
    (etwa in Zeile 36)
```
	PermitRootLogin	no
```
    oder aber
```
	PermitRootLogin	without-password
```
    Dann muss der Dämon neu gestartet werden:
```
	/etc/init.d/sshd stop
	/etc/init.d/sshd start
```
    Nur sicherheitshalber; wer sich gerade per SSH übers Netz eingeloggt hat, der sollte diese Befehle nicht abschicken; er sägt sonst den Ast ab, auf dem er sitzt.
  - Kontrolle: (übers Netz)
```
	ssh root@localhost
```
    muss mit einer Fehlermeldung enden
```
	ssh hhullen@localhost
```
    muss klappen, wenn "hhullen" ein eingetragener Benutzer auf dem System ist.
    Dann:
```
	su -
```
    und bei Nachfrage das "root"-Passwort eingeben.
  - Ausloggen: jetzt muss sich zuerst "root" ausloggen und anschliessend "hhullen"
  Zertifikat erzeugen
  Für die Anwendung muss im Home-Verzeichnis jedes Benutzers ein Verzeichnis mit dem Namen ".ssh" existieren oder angelegt werden und darin eine Datei, die den "private key" des Nutzers enthält mit dem Namen "authorized_keys". Diese muss vom SSH-Server lesbar sein, darf aber aus Sicherheitsgründen keine Schreibrechte für andere besitzen (also z.B. 755)
  - Anleitungen
    - Holger Dickhuth, Sem. I06T der Technikerschule der Stadt Braunschweig, 2007
    - Anleitung von Falko Timme
    - Howto (Linux)
- telnet, ftp usw. per TCP-Wrapper
  (was auch immer das bedeutet ...)
  - "telnet" entweder blockiert oder nur lokal
  - "ftp" (Server) entweder blockiert oder nur lokal
    Weitere Einschränkungen in "/etc/ftpusers" (Ausschluss-Liste) und"/etc/ftpaccess"
  - "SSH" (Server) eventuell nur lokal
  Diese (und weitere) Einstellungen: /etc/hosts.allow
```
#
# hosts.allow	Hier stehen die Rechner, denen der Zugriff erlaubt ist.
#		Im Gegensatz zu hosts.deny, wo mittels tcpd der 
#		Zugriff verboten ist. Siehe man hosts_access
#
# Author:	Reiner Klaproth, 08.06.2000
#
#
# Änderungen Helmut Hullen 30.8.03
# Änderungen Helmut Hullen 31.8.03
# "twist" und "spawn" ergaenzt 10.9.03 Hullen
# "portmap" für NFS und NIS überarbeitet 18.9.03 Hullen

# Syntax:
# service-Liste: Host-Liste [: Befehl]
# Man-pages hosts_access, hosts_options

# erster Treffer gilt

# erst mal alles, was in "inetd.conf" steht

in.telnetd:		192.168., 127.:	ALLOW
in.telnetd:		ALL: twist  mail -s "%d-Zugriff von %h" root
in.ftpd, in.proftpd:	192.168., 127.:	ALLOW
in.ftpd, in.proftpd:	ALL: twist  mail -s "%d-Zugriff von %h" root

popper, imapd:		192.168., 127.:	ALLOW
popper, imapd:		ALL: twist  mail -s "%d-Zugriff von %h" root

cvs,swat:		192.168., 127.:	ALLOW
cvs,swat:		ALL: twist  mail -s "%d-Zugriff von %h" root

in.tftpd, in.identd, in.comsat:	192.168., 127.:	ALLOW
in.tftpd, in.identd, in.comsat:	ALL: twist  mail -s "%d-Zugriff von %h" root

in.fingerd,in.xfingerd:	192.168., 127.:	ALLOW
in.fingerd,in.xfingerd:	ALL: twist  mail -s "%d-Zugriff von %h" root

# und jetzt die Dienste jenseits von inetd.conf
# bei denen muss "spawn" und "twist" nicht funktionieren

sshd:			192.168., 127.:	ALLOW
sshd:			ALL:		ALLOW
# sshd:			ALL: spawn  mail -s "%d-Zugriff von %h" root
# Zugriff von draussen erlaubt 
# sshd		ALL:	DENY
# Zugriff von draussen gesperrt

# opensshd 3.6p1 erlaubt "spawn" und "twist", 3.7p1 anscheinend nicht

# httpd:			192.168., 127.:	ALLOW
httpd:			ALL:		DENY
# derzeit nicht in "/etc/inetd.conf"

rsync: 			ALL: spawn mail -s "%d-Zugriff von h%" root 
# ist erlaubt, sollte nur berichtet werden

portmap:	192.168.:	ALLOW
# für NFS und NIS
portmap:	255.255.255.255 0.0.0.0
# für PC-NFS, siehe man 8 portmap

portmap:	ALL:		DENY
# "spawn", "twist" und "command xxx" funktionieren nicht; 18.9.03 Hullen

ALL: 		192.168., 127.: spawn  mail -s "%d-Zugriff von %h" root
ALL: 		ALL: 		twist  mail -s "%d-Zugriff von %h" root
# erst mal melden und abwürgen

ALL:		ALL:		DENY
# eigentlich überflüssig ...

# Ende von "hosts.allow"
```
  Tipp am Rande: Das TCP-wrapper-Regelwerk lässt sich mithilfe von tcpdchk(8) und tcpdmatch(8) überprüfen.
absoluter Schutz
Wer absoluten Schutz sucht, der sollte sich mal mit dieser Hardwarelösung beschäftigen; sie ist allerdings nicht per Browser konfigurierbar.

letzte Änderung 24.12.2013

Haftungsausschluss, Impressum

Arktur schützen

"root" darf sich nicht per "ssh" einloggen

Zertifikat erzeugen

telnet, ftp usw. per TCP-Wrapper

absoluter Schutz