Archive

Archive for Januar 2012

SSH: verschlüsselungsbasierte Authentifizierung, Portforwarding

2012/01/31 Kommentare aus

Einrichten verschlüsselungsbasierter Authentifizierung

Verschlüsselungsbasierte Authentifizierung kann verwendet werden um die Sicherheit von SSH weiter zu erhöhen. Empfehlenswert ist es den generierten Schlüssel mit einer Passphrase zu schützen, falls aber ein kennwortloses Login gewünscht ist (was für Skripte sehr nützlich ist) kann die Angabe einer Passphrase auch entfallen.

Der erste Schritt zum Einrichten verschlüsselungsbasierter Authentifizierung ist die Generierung eines Schlüsselpaares auf dem Client:

ssh-keygen -t rsa

ssh-keygen erstellt dabei die Dateien .ssh/id_rsa sowie .ssh/id_rsa.pub im Heimatverzeichnis des Benutzers. Die Datei id_rsa enthält den privaten Schlüssel und ist entsprechend zu schützen, id_rsa.pub enthält den öffentlichen Schlüssel. Dieser muss auf dem Server in die Datei .ssh/authorized_keys hinzugefügt werden. Diese Aufgabe erledigt der Befehl ssh-copy-id:

ssh-copy-id myuser@ftp.example.com

Nach Eingabe des Kennwortes des Benutzers myuser auf ftp.example.com erledigt ssh-copy-id seine Aufgabe und fügt den öffentlichen Schlüssel in ~myuser/.ssh/authorized_keys auf ftp.example.com ein. Leider wird der SELinux-Sicherheitskontext nicht automatisch gesetzt, dieser muss eventuell noch manuell auf ssh_home_t geändert werden. Dies kann mit restorecon geschehen:

ssh myuser@ftp.example.com
restorecon -R .ssh

SELinux verweigert den Zugriff falls der Sicherheitskontext von .ssh sowie .ssh/authorized_keys nicht auf ssh_home_t gesetzt worden sind! Der SSH-Server verweigert den Zugriff falls die Dateirechte nicht 700 für das Verzeichnis .ssh und 600 für die Datei authorized_keys entsprechen!

Falls ausschließlich verschlüsselungsbasierte Authentifizierung erlaubt sein soll ist die Direktive PasswordAuthentication in /etc/ssh/sshd_config auf dem Server auf no zu setzen.

Portforwarding

Es gibt zwei Arten von Port Forwarding: Lokales und Remote-Forwarding, welche auch bekannt sind als outgoing bzw. ingoing Tunnel.

Lokales Forwarding

Gibt an, dass der angegebene Port auf dem lokalen (Client) Host auf den angegebenen Host und Port des Remote-Hosts weitergeleitet werden soll. Dies funktioniert durch die Zuteilung eines Sockets auf dem der lokale Rechner lauscht. Immer wenn eine Verbindung zu diesem Port hergestellt wird, wird die Verbindung über den sicheren Kanal weitergeleitet.

In folgendem Beispiel wird eine Tunnelverbindung über den lokalen Port 10000 zu Port 80 (HTTP) auf Remote-Host 192.168.100.161 aufgebaut:

ssh root@192.168.100.161 -L 10000:192.168.100.161:80

Öffnet man nun einen Web-Browser und weist diesen an die Seite http://localhost:10000 zu öffnen, wird der gesamte Netzwerkverkehr zu 192.168.100.161 über SSH getunnelt. Der Nutzen ist klar: Es erscheint die selbe Website wie bei einem direkten Aufruf von http://192.168.100.161, diesmal werden Daten jedoch über eine sichere Verbindung übertragen. Ein Mitschneiden des ansonsten nomalerweise im Klartext übertragenen Netzwerkverkehrs ist nun relativ nutzlos.

Remote Forwarding

Genau umgekehrt: Gibt an, dass der angegebene Port auf dem entfernten (Server) Host auf den angegebenen Host und Port des lokalen Hosts (192.168.100.252) weitergeleitet wird:

ssh root@backup -R 10000:192.168.100.252:631

Erstellung eines privaten Yum-Repository (provisorisch)

2012/01/31 Kommentare aus

Erstellung eines privaten Yum-Repository

Die Erstellung eines eigenen provisorischen Repositories unter Verwendung von Daten der Installations-DVD ist sehr einfach zu bewerkstelligen. Im folgenden Beispiel werden Pakete über HTTP bereitgestellt.

yum install httpd
chkconfig httpd on
service httpd start

Nach Installation des Apache-Webservers und Start desselben werden sämtliche Daten vom Installationsmedium auf den Server kopiert.

mount /dev/cdrom /mnt        # einhängen DVD
cp -a /mnt/* /var/www/html   # wichtig: -a
umount /mnt                  # aushängen DVD

Es muss noch eine Ausnahme in die Firewall hinzugefügt werden, um den Zugriff auf die bereitgestellten Daten via HTTP zu erlauben.

yum install -y system-config-firewall-tui
system-config-firewall-tui

Anpassen -> WWW (HTTP) markieren -> Schließen

Eintrag des Repositories

Das Repository kann nun in Clients eingetragen werden. Um ein zusätzliches Repository hinzuzufügen wird einfach eine Datei mit der Endung „.repo“ im Verzeichnis /etc/yum.repos.d erstellt:

# /etc/yum.repos.d/my.repo
[myrepo]
name=My repository
baseurl=http://192.168.100.10
gpgcheck=0
enabled=1

Nach Ausführung von yum update kann das neu hinzugefügte Repository wie gewohnt verwendet werden.

Netzwerkinstallation

Red Hat stellt auch ein Installationsmedium zur Verfügung das ausschließlich zur Netzwerkinstallation verwendet werden kann. Dieses ist nicht auf der Installations-DVD enthalten und muss gesondert heruntergeladen werden (z.B. CentOS-6.2-x86_64-netinstall.iso). Nach Start von der Netzwerkinstallations-CD und Angabe des eben erstellten Repositories (hier: http://192.168.100.1) kann die weitere Installation über das Netzwerk erfolgen. In Verbindung mit Kickstart ist eine vollautomatische Installation (und Konfiguration) eines gesamten Systems möglich.

Kategorien:RHCE Schlagwörter: , ,

Konfiguration der host- und benutzer-basierten Sicherheit des Dienstes

2012/01/30 Kommentare aus

vsftpd

Die Standard-Konfiguration von vsftpd sieht vor allen in der Datei /etc/vsftpd/user_list angeführten Benutzern den Zugriff zu verweigern. Alle Benutzer, die nicht in dieser Datei enthalten sind können sich also am FTP-Server einloggen. Umgekehrt – Benutzer denen der Zugriff verweigert werden soll werden hier eingetragen.

# vsftpd userlist
# If userlist_deny=NO, only allow users in this file
# If userlist_deny=YES (default), never allow users in this file, and
# do not even prompt for a password.
# Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers
# for users that are denied.

# ...

# Verweigere folgende Benutzer:
bill
steve

Dieses Verhalten macht auch meistens Sinn – vom Login ausgeschlossen sind nur System-Accounts und root. Gelegentlich will man aber nur einigen wenigen Benutzern den Zugriff auf den FTP-Server erlauben. In diesem Fall ist es praktischer die Bedeutung der Datei /etc/vsftpd/user_list umzukehren, um ausschließlich darin enthaltenen Benutzern FTP-Zugriff zu erlauben. Dazu wird der Eintrag userlist_deny in /etc/vsftpd/vsftpd.conf auf NO gesetzt:

userlist_deny=NO

Es folgt der Eintrag erlaubter Benutzer in /etc/vsftpd/user_list:

# Erlaube folgende Benutzer:
alice
bob
sam

Es können sich nun ausschließlich die Benutzer alice, bob und sam an dem FTP-Server anmelden.

Host-basierte Sicherheit

Die Direktive tcp_wrappers in /etc/vsftpd/vsftpd.conf sollte bereits standardmäßig aktiv sein:

tcp_wrappers=YES

Es können nun Host-basierte Zugangsbeschränkungen über die Dateien /etc/hosts.allow und /etc/hosts.deny gesetzt werden:

/etc/hosts.allow

vsftpd : 192.168.100.0/255.255.255.0 EXCEPT 192.168.100.12

/etc/hosts.deny

vsftpd : ALL

Auf diese Weise abgewiesene Clients bekommen die Antwort

421 Service not available

Samba

Host- und Benutzerbasierte Sicherheit wird am einfachsten in der Konfigurationsdatei des Samba-Servers, /etc/samba/smb.conf festgelegt. Unter global eingetragene Beschränkungen gelten global, unter den einzelnen Freigaben eingetragene Beschränkungen ausschließlich für die jeweilige Freigabe. Verwendet werden dazu die Direktiven hosts allow, hosts deny sowie valid users und invalid users.

Die localhost Addresse 127.0.0.1 ist immer erlaubt (wenn nicht explizit in hosts deny angeführt).

Erlaube alle IPs in 150.203.*.* außer einer

hosts allow = 150.203. EXCEPT 150.203.6.66

Erlaube gesamtes Netzwerk

hosts allow = 150.203.15.0/255.255.255.0

Erlaube einige Hosts

hosts allow = lapland, arvidsjaur

Erlaube Hosts in NIS netgroup „foonet“, verweigere einen bestimmten Host

hosts allow = @foonet
hosts deny = pirate

Erlaube Benutzer bob, sam, alice und lokale Gruppe team2, verweigere bill den Zugriff

valid users = bob sam alice +team2
invalid users = bill

SSH

User-basierte Sicherheit für SSH wird in der Konfigurationsdatei /etc/ssh/sshd_config festgelegt. Am wichtigsten ist dabei die Direktive AllowUsers – falls diese angegeben wird können sich ausschließlich die hier angegebenen Benutzer anmelden. Es ist auch möglich, Benutzer ein Login nur von bestimmten Hosts aus zu erlauben.

AllowUsers john fred
AllowUsers bob@192.168.100.102 michael@192.168.150.12
AllowGroups team1
DenyUsers steve bill alice
DenyGroups team2

Benutzer, denen der Zugriff nicht erlaubt ist bekommen nach Eingabe ihres Kennwortes die Meldung

Permission denied, please try again.

Es ist dabei nicht ersichtlich, ob das eingegebene Kennwort falsch war oder dem Benutzer das Login verweigert wurde.

Host-basierte Sicherheit wird am einfachsten über die Dateien /etc/hosts.allow und /etc/hosts.deny konfiguriert:

/etc/hosts.allow

sshd : 127. 192.168.100. EXCEPT 192.168.100.101

/etc/hosts.deny:

sshd : ALL

Per TCP-Wrappers abgelehnte Verbindungsversuche werden mit

ssh_exchange_identification: Connection closed by remote host

beantwortet. Es wird gar nicht erst die Eingabe eines Kennwortes verlangt.

NFS

Host-basierte Zugriffssteuerung sollte bereits bei der Erstellung von NFS-Freigaben konfiguriert sein.

/etc/exports

/mynfsshare   192.168.100.0/255.255.255.0(rw) 192.168.12.1(ro)
/projects       proj*.local.domain(rw)
/usr            *.local.domain(ro) @trusted(rw)
/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            *(ro,insecure,all_squash)

Beschränkungen auf Benutzerebene werden über das Dateisystem festgelegt, entweder über die normalen UNIX-Rechte oder auch unter Verwendung von ACLs.

HTTP

Benutzer- und Hostbasierte Sicherheit wird in der Konfigurationsdatei /etc/httpd/conf/httpd.conf festgelegt. Erlaubte bzw. zu verweigernde Hosts werden über die Direktiven Order, Allow from und Deny from für jedes Verzeichnis einzeln angegeben. Ein Eintrag innerhalb <Directory „/var/www/html“> wird jedoch an alle Unterverzeichnisse vererbt, soweit dort nicht anders angegeben.

<Directory "/var/www/html">
# ...
#
# Controls who can get stuff from this server.
#
 Order allow,deny
 Allow from all
 Deny from 192.168.100.103
</Directory>

Host 192.168.100.103 bekommt nun beim Versuch die Seite anzuzeigen den HTML-Error 403:

Forbidden
You don't have permission to access / on this server.

Benutzerbasierte Sicherheit wird ebenfalls für jedes Verzeichnis einzeln konfiguriert. In folgendem Beispiel wird das Verzeichnis myprivatedir nur nach Eingabe eines gültigen Benutzernamens und des zugehörigen Kennwortes angezeigt:

<Directory "/var/www/html/myprivatedir">
AuthType Basic
AuthName "Eingabe eines Kennwortes erforderlich"
AuthUserFile /etc/httpd/users
require valid-user
</Directory>

Möglich nach require sind valid-user, valid-group, user und group.

Bei Verwendung von Gruppen ist zusätzlich zu AuthUserFile das AuthGroupFile bekanntzugeben:

AuthType Basic
AuthName "Geschützte Ressource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin

Benutzer anlegen:

htpasswd -c /etc/httpd/users alice
htpasswd /etc/httpd/users bob
htpasswd /etc/httpd/users sam

Gruppen werden in einer einfachen Textdatei verwaltet, z.B. /etc/httpd/groups:

admin: bob sam alice
team1: bill steve
Kategorien:RHCE Schlagwörter: , , , , ,

Erzeugung und Bereitstellung von Berichten zur Systemauslastung (Prozessor, Arbeitsspeicher, Datenträger und Netzwerk)

2012/01/27 Kommentare aus

Sehr hilfreich zum Anzeigen von aktuellen Informationen zu CPU-Auslastung, Datenträger-, Arbeitsspeicher- und Netzwerklast ist das Paket dstat. Dieses kann durch Aufruf von

yum install dstat

installiert werden. dstat bietet eine Live-Übersicht der oben genannten Parameter – was jedoch für eine längere Beobachtung des Systems eher weniger hilfreich ist.

Das sysstat-Paket bietet sich an um das System über einen längeren Zeitraum zu überwachen. sysstat lässt sich durch Aufruf von

yum install sysstat

installieren und wie andere Dienste durch service und chkconfig starten:

service sysstat start   # sysstat jetzt starten
chkconfig sysstat on    # sysstat beim Hochfahren starten

Nach Aktivierung von sysstat werden Informationen automatisch gesammelt und unter dem Verzeichnis /var/log/sa abgelegt.

Anzeigen von Berichten zur Systemauslastung

Durch sysstat (eigentlich: sar) gesammelte Daten können durch sadf und sar ausgegeben werden.

# CPU-Auslastung von CPU 1 zwischen 11:00 und 14:00 Uhr
sadf -s 11:00:00 -e 14:00:00 -P 0
# SWAP-Verwendung
sadf -- -W

# Auslastung Arbeitsspeicher aktuell
sar -r
# Auslastung Arbeitsspeicher 27. Tag des Monats
sadf /var/log/sa/sa27 -- -r

sadf zeigt dabei die von sar gesammelten Daten an, welches für jeden Tag eine eigene Datei unter /var/log/sa erstellt. Im letzten Beispiel würde die Auslastung des Arbeitsspeichers für den 27. des Monats angezeigt.

Weitere Informationen bieten die Manpages zu top, free, ps, dstat, iostat, sar, sadfs (…), sowie vor allem die Website zu sysstat.

Kategorien:RHCE Schlagwörter: , , ,

SMB: Einrichtung eines gemeinsamen Verzeichnisses für einzelne Clients, gemeinsames Verzeichnis für die Zusammenarbeit

2012/01/23 Kommentare aus

Die Einrichtung eines gemeinsamen Verzeichnisses für die Zusammenarbeit mehrerer Benutzer sollte zuerst auf Dateisystemebene funktionieren und erst danach über CIFS exportiert werden.

Die Installation des Samba-Servers erfolgt durch Aufruf von

yum install samba

Erstellung von Benutzerkonten

Der erste Schritt ist die Erstellung einer Gruppe und das Hinzufügen/Erstellen der jeweiligen Mitglieder der Gruppe:

groupadd team1
useradd -s /sbin/nologin -g team1 alice
useradd -s /sbin/nologin -g team1 bob
useradd -s /sbin/nologin -g team1 sam

In obigem Beispiel wurde die Gruppe team1 und die Benutzer bob, sam und alice als deren Mitglieder erstellt. Da ein Login auf dem lokalen System für diese Benutzer nicht notwendig ist wurde den Benutzern die Login-Shell /sbin/nologin zugewiesen.

Zuweisen von Benutzerkennworten

Kennworte werden von Samba in einer eigenen Datenbank geführt. Die Erstellung eines Kennwortes für einen Benutzer erfolgt durch Aufruf von smbpasswd. Nachfolgend werden Kennworte für die Mitglieder der Gruppe team1 erstellt:

smbpasswd -a bob
smbpasswd -a sam
smbpasswd -a alice

Erstellung eines gemeinsamen Verzeichnisses

Wichtig bei der Erstellung des gemeinsamen Verzeichnisses zur Zusammenarbeit sind korrekt gesetzte Zugriffsrechte, falls nötig ein gesetztes Sticky-Bit sowie der entsprechende SELinux-Sicherheitskontext.

mkdir /share
chgrp team1 /share
chmod 3770 /share

Das Verzeichnis zur Zusammenarbeit wird mit Hilfe des Befehls mkdir erstellt, chgrp ändert die Hauptgruppe des Verzeichnisses zu team1. Mit chmod werden ausreichende Zugriffsrechte gesetzt, um den Mitgliedern der Gruppe team1 eine Zusammenarbeit zu ermöglichen. Die Bedeutung der oktal angegebenen Unix-Rechte ist hier noch einmal im Detail aufgeschlüsselt:

3   Set Group ID (2) + Sticky Bit (1)

Durch Setzen von Set Group ID (oktal 2) befinden sich neu erstellte Dateien und Verzeichnisse automatisch im Eigentum der Gruppe team1. Das gesetzte Sticky-Bit (oktal 1) bewirkt dass nur der jeweilige Eigentümer einer Datei diese auch löschen darf – obwohl die gesamte Gruppe Schreibrechte hat. Das Sticky-Bit sollte nur dann gesetzt werden wenn diese Funktionalität gewünscht ist.

7 Benutzer: Lesen (4) + Schreiben (2) + Ausführen (1)

7 Gruppe: Lesen (4) + Schreiben (2) + Ausführen (1)

0 Andere: keine Rechte

Benutzer und Gruppe haben Lese- (oktal 4), Schreib- (oktal 2) und execute-Rechte (oktal 1), in Summe also jeweils oktal 7 (rwx). Alle Anderen haben keine gesetzten Rechte, können also weder den Inhalt des Verzeichnisses einsehen, in das Verzeichnis wechseln oder Dateien bzw. Verzeichnisse anlegen oder ändern.

Konfiguration von SELinux

Von Samba freigegebene Verzeichnisse und Dateien müssen den Kontext samba_share_t haben. Zur einfacheren Konfiguration von Sicherheitskontexten ist es empfehlenswert, das Paket policycoreutils-python zu installieren. Dieses stellt unter anderem den Befehl semanage bereit:

yum install  policycoreutils-python
semanage fcontext -a -t samba_share_t /share
restorecon -R /share

Wichtig ist der genaue Syntax bei Aufruf von semanage – kein Forward-Slash nach Angabe des Verzeichnisses (BASH fügt dieses bei Tab-Vervollständigung automatisch an). semanage setzt den Type samba_share_t auf das Verzeichnis /share, restorecon führt diese Änderung dann auch tatsächlich durch.

Ausnahme in die Firewall hinzufügen

Die Firewall wird am unkompliziertesten mit dem Werkzeug system-config-firewall-tui angepasst. Eine Installation erfolgt durch

yum install system-config-firewall-tui

Aufruf der Werkzeugs zur Firewallkonfiguration:

system-config-firewall-tui

–> Anpassen –> „Samba“ markieren –> Schließen

Konfiguration von Samba

Die eigentliche Konfiguration von Samba ist recht einfach. Es wird eine Freigabe mit Angabe des Pfades erstellt und ausreichende Rechte darauf gesetzt.

Zu editieren ist dabei die Konfigurationsdatei /etc/samba/smb.conf. Erforderlich ist eine Anpassung von workgroup und netbios name, sowie das Hinzufügen der eigentlichen Freigabe.

workgroup = MYGROUP
netbios name = MYSERVER

[myshare]
 path = /share
 writable = yes
 valid users = +team1
 create mask = 660
 directory mask = 770
 hosts allow = 192.168.100.
 hosts deny = 192.168.100.103

Mit workgroup wird der Name der Arbeitsgruppe angegeben, netbios name setzt den Rechnernamen, der im Netzwerk angezeigt wird. Unter interfaces kann noch angegeben werden auf welchen Netzwerkschnittstellen Samba erreichbar ist. writable ermöglicht schreibenden Zugriff auf die Freigabe, create mask und directory mask geben an, mit welchen Rechten neu erstellte Dateien bzw. Verzeichnisse angelegt werden. valid users enthält durch Leerzeichen getrennt Benutzer, die Zugriff auf die jeweilige Freigabe haben sollen. Gruppen werden durch vorangestelltes + gekennzeichnet. Hostbasierte Zugriffssteuerung kann mit hosts allow bzw. hosts deny erreicht werden.

Nach erfolgter Anpassung der Konfiguration muss der Netbios-Name Daemon nmb sowie der Samba-Server smb (neu) gestartet werden:

service nmb start
service smb start
chkconfig nmb on
chkconfig smb on

Die Freigabe sollte nun in der Netzwerkumgebung sichtbar sein und von den Benutzern bob, sam und alice zu benutzen sein.

Weiterführende Informationen bieten die Befehle

man samba
man samba_selinux
man smb.conf
tail -f /var/log/messages
tail -f /var/log/audit/audit.log
getsebool -a | grep samba

NTP: Bereitstellung für ausgewählte Clients

2012/01/19 Kommentare aus

Der Network Time Protocol Daemon lässt sich durch Ausführung von

yum install ntp

installieren. Das Paket ntp enthält sowohl den NTP-Client als auch den NTP-Server. Beide werden über die selbe Konfigurationsdatei, /etc/ntp.conf gesteuert. Um den NTP-Dienst für ausgewählte Clients bereitzustellen ist nur die Änderung einer einzigen Zeile nötig:

# Hosts on local network are less restricted.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org

Mit restrict wird der Zugriff von Clients reguliert – nach Entfernung des Kommentarzeichens und Anpassung des Netzwerkes/der Netzwerkmaske ist die Konfiguration bereits erledigt. Falls der Server eine andere Quelle zur Zeitsynkronisation verwenden soll sind die server-Einträge entsprechend abzuändern. Die server-Direktive gibt Server bekannt die ausschließlich als Quelle dienen, falls ein gegenseitiger Zeitabgleich von mehreren Systemen gewünscht ist sollte anstatt server peer verwendet werden. Die peer-Direktive erlaubt bidirektionale Zeitsynkronisierung. Eine Übersicht verfügbarer NTP-Server ist auf www.pool.ntp.org einsehbar.

Nach erfolgter Konfiguration ist der Server zu starten:

service ntpd start  # ntpd jetzt starten
chkconfig ntpd on   # ntpd beim Hochfahren starten

Ausnahme in die Firewall hinzufügen

NTP verwendet Port 123 UDP, dieser muss nach Aktivierung des NTP-Servers noch freigeschalten werden. Die Firewall wird am einfachsten mit dem Werkzeug system-config-firewall-tui angepasst. Eine Installation erfolgt durch

yum install system-config-firewall-tui

Aufruf der Werkzeugs zur Firewallkonfiguration:

system-config-firewall-tui

–> Anpassen –> Weiter –> Hinzufügen

Port: 123

Protokoll: udp

Die Erreichbarkeit des NTP-Servers lässt sich mit dem Werkzeug ntpq oder auch ntpdate von einem Remote-System aus testen:

ntpq -p localhost       # Test auf lokalem System
ntpq -p 192.168.1.10    # Test von Remote-System
ntpdate 192.168.1.10    # Test von Remote-System

 

Weiterführende Informationen bieten die Befehle

man ntp.conf
man ntpq
man ntpdate
Kategorien:RHCE Schlagwörter: , , ,

Verwendung von /proc/sys und sysctl zur Modifizierung und Einrichtung der Kernel-Laufzeitparameter

2012/01/19 Kommentare aus

Diverse Kernelparameter lassen sich zur Laufzeit verändern bzw. auslesen. Linux stellt dazu das /proc-Dateisystem bereit. Darin ist eine Vielzahl von Dateien enthalten, die Informationen über das laufende System enthalten. Die meisten davon lassen sich mit Hilfe des Befehls cat ansehen. Dateien unterhalb /proc/sys lassen sich zur Laufzeit verändern und ermöglichen damit eine Veränderung diverser Kernelparameter.

Anzeigen diverser Informationen in /proc

cat filesystems    # vom Kernel unterstützte Dateisysteme
cat swaps          # aktuell verwendete Swap-Speicher
cat interrupts     # belegte Interrupts
cat version        # Kernelversion

Veränderung von Kernelparametern zur Laufzeit

In /proc/sys gelegene Dateien lassen sich nicht nur wie oben beschrieben auslesen, sondern meist auch mit echo oder durch Aufruf von sysctl beschreiben:

echo 1 > /proc/sys/net/ipv4/ip_forward            # IP-Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all  # Ping nicht beantworten
echo 1 > /proc/sys/net/ipv4/conf/eth2/accept_source_route    # Source Route

Permanente Änderung von Kernel-Parametern

Auf diese Weise durchgeführte Änderungen gehen nach einem Neustart des Systems jedoch verloren. Sollen Parameter permanent modifiziert werden ist ein Eintrag in /etc/sysctl.conf notwendig. Diese Datei ist bereits im System vorhanden und kann entsprechend angepasst werden.

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1
# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536
# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536
# Controls the maximum shared segment size, in bytes
kernel.shmmax = 4294967295
# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 268435456

Die Einträge spiegeln die Verzeichnisstruktur innerhalb /proc/sys wieder, anstatt dem Forward-Slash (/) wird hier einfach ein Punkt verwendet.

Nach einer Änderung von Parametern in /etc/sysctl.conf ist der Aufruf des Befehls sysctl notwendig, um diese auch wirksam zu machen:

sysctl -p   # Lade Einstellungen aus sysctl.conf

 

Weiterführende Informationen bieten die Befehle

man sysctl
man sysctl.conf
Kategorien:RHCE Schlagwörter: , , , ,