Linux 4

Aus wiki@ANOnet
Wechseln zu: Navigation, Suche

Einiges zum LPI 202

Inhalt:

  • Apache
  • squid
  • samba
  • NFS
  • DHCP
  • PAM
  • LDAP
  • E-Mailserver (sendmail - postfix)
  • Mailzustellung
  • IPtables
  • FTP-Server
  • SSH
  • TCPwrapper
  • SElinux
  • Virtualisierung


Inhaltsverzeichnis

Virtualisierung

Auch in Linux stehen mehrere Linien zur Verfügung:

  • XEN: hier kann auf 2 Arten Virtualisiert werden, para~ und full. Der Vorteil von para ist ~20% Performancegewinn, da direkt auf die Hardware zugegriffen werden kann, allerdings muss für Windows bzw. andere Systeme wieder auf full zurückgegriffen werden. Xen benötigt einen eigenen Kernel, unterstützt allerdings auch 32bit-Systeme
  • kvm, dies wird ab RH6.x standard, XEN und virtualbox werden dann nicht mehr unterstützt. KVM unterstützt nur 64bit-Systeme, und läuft im Unterschied zu XEN nur in einem Kernelmodul
  • (virtualbox)

Installation

yum -y install kmod-kvm kvm
modprobe kvm
modprobe kvm-intel

(die modprobes müssen nur das erste mal händisch geladen werden)

yum -y install virt-manager

um die Virt-Maschinen zu verwalten


service libvirtd start
virsh

Danach hat sich der prompt verändert

virsh # 
virt-manager

startet die GUI


Ein Bridge-Interface wird angelegt:

cd /etc/sysconfig/network-scripts/
cp ifcfg-eth0 ifcfg-br0
vi ifcfg-br0


DEVICE=br0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.16
NETMASK=255.255.255.0
GATEWAY=192.168.0.254
TYPE=Bridge
vi ifcfg-eth0
# Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express
DEVICE=eth0
BOOTPROTO=none
DHCPCLASS=
HWADDR=00:19:B9:35:D1:27
ONBOOT=yes
BRIDGE=br0

nun kann die virtuelle Maschine über die eth des Recheners ans Netz angebunden werden

nun ist ev. ein SELinux-Problem aufgetreten, es wird mit

restorecon -v -R /var/lib/libvirt/images/

berichtigt...

unter

/etc/libvirt/qemu/server.xml 

läge die Konfigurationsdatei der virt. Maschine.


Die Verwaltung der virt. Maschinen kann auch mittels virsh geschehen

SELinux

Weiterführende Informationen unter http://www.os-t.de/buecher_new.php (Security-Enhanced Linux) wird verwendet, um lokale Security zu erhöhen, da rwx als Berechtigungslevels etwas zu wenig ist. SELinux ist dzt für 88 Applikationen ausgelegt Der Hintergrund ist eigentlich nur, dass ein Prozess "eingesperrt" bleibt. Es arbeitet so, dass Dateien "gelabelt" werden

ls -Z

zeigt nun SELinux-Informationen, Dies gilt auch für Prozesse unter ps -Z

http://www.os-t.de/buecher_new.php

-rw-r--r--  root root root:object_r:user_home_t        install.log

ein neu erstellter vhost hat nun folgende Erweiterungen, den SELinuc-Kontext:

[root@server216 conf]# ls -lZ /var/www
drwxr-xr-x  root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t icons
[root@server216 conf]# ls -lZ /var/www2
drwxr-xr-x  root root root:object_r:var_t              html

um nun Apache zu erlauben, auch das andere Verzeichnis zu verwenden, wird

chcon --reference=/var/www -v -R /var/www2

verwendet

setroubleshoot

lässt meldungen in var/log/messages erscheinen

setenforce 0|1 lässt SEL ein/ausschalten

Das Regelwerk kann sich mit den setools angeschaut werden

sesearch -A | less
sesearch -A | grep "httpd_t " |grep httpd_sys_content_t

bringt nun, was dem httpd erlaubt ist


Dieses Regelwerk wird durch ein eigenes RPM installiert

mittels

restorecon -v /var/.../...

wird SELinux ggf wieder hergestellt. Allerdings müssen hierfür die Dateien/Ordner richtig gekennzeichnet sern (file-labeling), was mit

system-config-selinux 

gesetzt werden kann. SELinux kann hier auch für einzelne Prozesse abgeschaltet werden


Bei Sicherungen/syncs muss darauf geachtet werden, dass die SELinux-Informationen mitgesichert und ggf wiederhergestellt werden

mittels

seinfo -A 
yum -y install setroubleshoot

ist ein Service, welches allerdings noch gestartet werden muss.

chkconfig setroubleshoot

Dadurch werden Zusatzinfos nach /var/log/messages gesendet. so werden auch Problemlösungsansätze geliefert

Iptables

cat /proc/net/ip_conntrack

Grundlagen

Im Grunde existieren 3 Firewalltypen:

  • Packetfilter: arbeitet auf
    • L2, MAC, Type,
    • L3, s/d-IP, Protokoll, TTL, QoS, Fragmentation,
    • L4-5 UDP/TCP Portnummer
      • TCP: Windowsize, Flags,

Ein PF hat allerdings nicht die Möglichkeit, die Verkehrsrichtung, den Verbindungsaufbau zu steuern, lenken, erkennen. Der Vorteil ist, dass sie sehr schnell ist. IPCHAINS war/ist ein Paketfilter

  • Proxy-Firewall

Der Proxy bricht die Verbindung Client/Server auf, kann daher den Inhalt der Pakete analysieren. Der Nachteil hier ist, dass es nur für bestimmte Applikationen funktioniert. Durch den Cache gewinnt man 8-10% an Bandbreite, was heute allerdings eher nebensächlich ist. Der Hauptgrund ist das Überwachen, das Loggen

  • Stateful inspect

Sie vereint die Vorteile der beiden anderen. Sie läuft als Kernelmodul, kann den Fluss überwachen (Richtung), und kann - je nach Modul - auch die Inhalte analysieren. Ein derartiges Modul muss für jede Anwendung vorhanden sein. Dies geschieht in einem "Zwischenlayer" zwischen network&IP-Layer Seit Kernel 2.4 wird IPTABLES mitgeliefert.

iptables sitzt also zwischen der Network- und Internetlayer Wenn nun ein Client eine Verbindung zu einem externen Server aufbaut, wird IPT dieses FORWARDen. Wenn der Client nun einen Server auf der Iptable-Maschine zugreift, läuft die Anfrage über INPUT, die Antwort der im IPtable-"Server"läuft über OUTPUT. Wenn die IPT-Serverapplikation ihrerseits ins Internet muss, läuft dies sinngemäß gleich

Verwalten von IPTables

  • FWBuilder kann mittels GUI IPTables bauen
  • "service iptables save" legt ein sicherungsfile an
  • iptables-save schreibt ebendiese auf den Schirm

ein

at now + 10 min
service iptables stop

kann ggf eine fehlkonfigurierte iptables stoppen...

Verwendung

[root@station20 ~]# iptables -nvL
Chain INPUT (policy ACCEPT 3655K packets, 3239M bytes)
 pkts bytes target     prot opt in     out     source               destination         
3622K 3227M LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `BANDWIDTH_IN:'  

Chain FORWARD (policy ACCEPT 130 packets, 9368 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  128  9200 LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `BANDWIDTH_OUT:' 
    2   168 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `BANDWIDTH_IN:' 

Chain OUTPUT (policy ACCEPT 1565K packets, 3132M bytes)
 pkts bytes target     prot opt in     out     source               destination         
1532K 3120M LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `BANDWIDTH_OUT:' 


Hier werden die 3 Filterketten angezeigt, wobei zu beachten wäre, dass per default alle auf "ACCEPT" stehen. Das Ziel der Firewall wäre, dass die Policy auf "DROP" steht. IPtables hat keine Konfigurationsdatei, da es auf Kernelmodulen basiert. Unter

/lib/modules/[Kernel]/kernel/net/ipv4/netfilter/

liegen die betreffenden Module Die Konfigurationen passieren durch absetzen verschiedener Kommandos

ssh-Regel

es soll ausschließlich ssh auf eine Maschine funktionieren: Gefiltert kann werden nach:

  • Quellport >1024
  • Zielport 22 --dport
  • QuellIP --sports
  • ZielIP -d
  • Protokoll -p
  • Interface -i
  • Connection state
  • FLAGS: syn, ack -m state --state NEW,ESTABLISHED. Nun kommt der Treffer nach /proc/net/ip_conntrack, und kann da überwacht werden
  • am Ende wird definiert, was passieren soll ACCEPT/DROP/REJECT bzw LOG. LOG stellt hier eine Ausnahme dar, denn eine LOG-Regel ist nicht das Ende der Kette, es wird das Regelwerk weiter durchlaufen
iptables -t -I INPUT -i eth0 -s [quellIP] -d [zielIP] -p tcp --sport 1025: --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -D 1

würde den 1. Eintrag löschen

Anschließend könnte die default-Policy von ACCEPT auf DROP gesetzt werden:

iptabels -P INPUT DROP

Damit nun Antwortpakete wieder zurückfinden, sollte nun noch

iptables -I INPUT -m state --state ESTABLISHED -j ACCEPT

gesetzt werden.

Großbuchstabenoptionen fügen in die Regelkette hinzu


Das selbe funktioniert auch ausgehend:

 iptables -I OUTPUT -m state --state ESTABLISHED -j ACCEPT

Aktivieren der Namensauflösung:

iptables -A OUTPUT -o [ETH] -s [IP] -d [DNS-IP] -p udp --sport 53 --dport 53 -m state --state NEW -j ACCEPT


Einbau einer Log-Regel: Die Log-Regel ist die einzige Regel, die den Strom die Regel nicht verlassen lässt. Daher sollte sie sinnvoll in die Regelkette eingebaut werden

iptables -A Input -j LOG --log-level notice --log-prefix "IPTABLES INPUT DROP: "

würde nun alles loggen

Am Anfang sollte eine Regel stehen, welche alle "sinnlosen" Datenströme (RIP, netBIOS, ...) verwirft

iptables -I INPUT -p tcp --dport 445 -j DROP

würde netbios verwerfen

iptables -I INPUT -p tcp -m --multiport --destination-port 137,138,139,445 -j DROP

würde eine Angabe von mehreren Ports zulassen


Am Anfang sollte ebenso ein

iptables -I INPUT 4 -m state --state=NEW -j LOG --log-level notice --log-prefix "IPTABLES NEW_CONNECTIONS: "

Damit werden auch die neu erstellten Verbindungen erfasst werden.

Unter RedHat würde

service iptables save

nach /etc/sysconfig/iptables speichern

service iptables restart

würde die obrige Konfigdatei übernehmen

Diese Datei kann auch bearbeitet werden, so kann das Regelwerk übersichtlich gestaltet und kommentiert werden

Folgendes könnte ein "rettungsanker" sein:

at now +10 min
 at> service iptables stop
 at> [ctrl-d]

dieses at löscht sämtliche iptables, und eine Maschine wäre wieder erreichbar

mit

atq 

könnten die dort angelegten Jobs sichtbar gemacht werden, mit

atrm 4

löschen

iptables -nvL

zeigt die tables an

iptables -p icmp -h

BSP

*filter
:INPUT DROP [210:6778]
:FORWARD ACCEPT [0:0]
:OUTPUT DROP [128:7680]
:NEWFLOOD -  [0:0]
# der "-" besagt, dass keine default-Pol existiert


# allow loopback
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

# drop trash
-A INPUT -i eth0 -d 224.0.0.0/3 -j DROP
-A INPUT -i eth0 -p tcp -m multiport --destination-ports 138,138,139,445 -j DROP


# allow 1 conn/s
# es wurde eine neue Regelkette "NEWFLOOD" erstellt, um NEWFLOODs zu verhindern und die Anzahl der neuen Sessions auf 1/sec zu limitieren
-A INPUT -i eth0 -m state --state NEW -j NEWFLOOD
-A NEWFLOOD -i eth0 -m limit --limit 1/sec -j RETURN
-A NEWFLOOD -j DROP


# allow est
-A OUTPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -m state --state ESTABLISHED -j ACCEPT

# log new connections to server
-A INPUT -i eth0 -m state --state NEW -j LOG --log-level info --log-prefix "IPTABLES INPUT: NEW: "

# allow icmp request
-A INPUT -i eth0 -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -i eth0 -p icmp --icmp-type destination-unreachable -j ACCEPT


# allow ssh
-A INPUT -s 192.168.0.0/255.255.255.0 -d 192.168.0.216 -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

# allow tcp/80

-A INPUT -s 192.168.0.0/255.255.255.0 -d 192.168.0.216 -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

# allow ftp from server to reopserver
-A OUTPUT -o eth0 -s 192.168.0.216 -d 192.168.0.254 -p tcp --sport 1024: --dport 21 -m state --state NEW -j ACCEPT
##aktiv
-A INPUT -i eth0 -s 192.168.0.254 -d 192.168.0.216 -p tcp --sport 20 --dport 1024: -m state --state RELATED -j ACCEPT
##passiv
-A OUTPUT -o eth0 -s 192.168.0.216 -d 192.168.0.254 -p tcp --sport 1024: --dport 1024: -m state --state RELATED -j ACCEPT
# IPTABLES_MODULES="ip_conntrack_ftp" muss nach  /etc/sysconfig/iptables-config

# allow telnet

-A INPUT -s 192.168.0.16 -d 192.168.0.216 -i eth0 -p tcp -m tcp --sport 1024:65535 --dport 23 -m state --state NEW -j ACCEPT

# allow dns
-A OUTPUT -s 192.168.0.216 -d 192.168.0.254 -o eth0 -p udp -m udp --sport 1024:65535 --dport 53 -m state --state NEW -j ACCEPT

# log droppes pkgs
-A INPUT -i eth0 -j LOG --log-level debug --log-prefix "IPTABLES INPUT DROP: "

-A OUTPUT -o eth0 -j LOG --log-level debug --log-prefix "IPTABLES OUTPUT DROP: "

COMMIT

Um die Regelketten kurz und übersichtlich zu halten, werden, wie im Bsp bei "NEWFLOOD" zb die Interfaces extra behandelt, zb. "INPUT_ETH1" Diese Regelketten schließen mit einem DROP bzw REJECT, da sie keine default-policy beinhalten

FORWARD

FTP bräuchte das Modul ip_conntrack_ftp, welches bei RedHat im /etc/sysconfig/iptables-config automatisiert werden könnte


Für die Firewallfunktionalität müsste "forward" verwendet werden:

iptables -I FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -d !192.168.0.0./24 -p tcp --sport 1024: --dport 21 -j -m state --state NEW ESTABLISHED -j ACCEPT

würde FTP zulassen

Für die Retourantwort:

iptables -I FORWARD -m state --state ESTABLISHED -j ACCEPT

würde ALLE Retourwege wieder zulassen

Aktives FTP

Da bei aktiven FTP der 2. Kanal vom Server aufgebaut wird, muss für die Funktion als Modul einem Natdevice mitgeteilt werden

iptables -I FORWARD -i ETH1 -o ETH0 -s !192.168.0.0./24 -d 192.168.0.0./24 -p tcp --sport 20 --dport 1025: -m state --state RELATED -j ACCEPT

Durch das RELATED wird diese Regel an eine bestehende Kommunikationsverbindung angehängt

Passives FTP

Hier macht der Client auch die 2. Verbindung auf

iptables -I FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -d !192.168.0.0/24 -p tcp --sport 1024: --dport 1024: -m state --state RELATED -j ACCEPT


-t

IPTables hat 3 Arten von Tabellen:

  1. filter (default
  2. nat
  3. mangle

chains-Optionen

-Z setzt Zähler zurück
-F flush, cleart alle Regeln
-I schiebt die Regel am Anfang ein
-A Append
-D delete


mit

iptstate 

bzw

cat /proc/net/ip_conntrack

können die Verbindungen gesehen werden

NAT

per default verwendet IPT die Tabelle "filter". Es existieren allerdings noch "nat" und "mangle"

iptables -t nat -nvL

zeigt das Regelwerk für "nat" an


NAT hat 3 Regelketten:

  • prerouting
  • output
  • postrouting

dynamisches(hide, masquerade) NAT: (x:1, postrouting, PAT) es wird verwendet, um "private" Netze ans Internet zu bringen.

iptables -t nat -A POSTROUTING -o eth1 -s 10.0.0.0/24 -d !10.0.0.0/24 -j MASQUERADE
(bzw -j SNAT --to-source [vonIP]-[bisIP][:[vonport]-[toport]], um mehrere IPs zu verwenden


statisches NAT:

  • source-static: 1:1 postrouting, aber kein PAT, es werden die Originalports verwendet
  • destination-static: 1:1: diesmal von aussen nach innen: nun muss die Firewall allerdings auf eine MAC antworten, die ihr nicht gehört (die des Servers). Hier gibt es wieder 3 Lösungsansätze:
    • an der eth0 der Firewall wird ein Subinterface mit der IP des Servers gebaut, somit antwortet die FW nach besten Wissen und Gewissen
    • am Router wird ein statischer ARP-Eintrag gesetzt
    • es wird proxy-arp verwendet: "arp -s [IP] [MAC] pub"

Hier wird dann PREROUTING verwendet, da sich die "Sichtweise" gedreht hat.

iptables -t nat -I PREROUTING -s !10.0.0.0/24 -d 196.78.53.20 -p tcp --dport 80 -j DNAT --to-destinaton 10.0.0.1

Bei den NAT-Einträgen wäre weiters zu beachten, dass die Funktion erst gegeben wäre, wenn dir dazugeförigen forward-Regeln gesetzt sind

mangle

"mangle" kann zum Markieren der Pakete verwendet zu werden: iptables -t mangle -nvL

apache

Die Konfiguration liegt unter /etc/http/ Wobei die Konfiguration erneut gesplittet ist. Die Haupt-konfigdatei liegt unter conf, unter conf.d liegen "ausgelagerte" Konfigurationsdateien, die von apache mitverwendet werden

<Directory />
   Options FollowSymLinks
   AllowOverride None
</Directory>

/ bezieht sich auf die wirkliche / "Indexes" als Option erlaubt, alle im Verzeichnis liegenden Dateien anzuzeigen, wenn sich keine index.html dort befindet


"FollowSymLinks" sollte wohl überlegt werden...

 apachectl -M/-L

liefert die Module

Module können mit rpms nachinstalliert


home-dirs

So kann ein User auf Webseiten in seinem Homeverzeichnis zugreifen. Die Url würde http://server.example.com/~user/html lauten

einrichten

in der httpd.conf

#  UserDir disable
   UserDir public_html


$ setfacl -m -u:apache:r-x
# setsebool httpd_enable_homedirs on


schützen der homedirs

Anlegen einer

.htaccess

mit dem Inhalt

AuthType Basic
AuthName "Geschuetzter Bereich"
AuthBasicProvider file
AuthUserFile /home/another/passwords
Require user max

Danach PWD-File erstellen

htpasswd -c /home/another/passwords max


PAM

yum install mod_auth_pam.x86_64

nach dem restart des httpd wäre PAM verwendbar

die .htaccess noch wie folgt abändern

AuthType Basic
AuthName "Geschuetzter Bereich"
#AuthBasicProvider file
#AuthUserFile /home/another/passwords
Require valid-user
                                       

sowie

# setfacl -m u:apache:r /etc/shadow

ev. muss noch SELinux angepasst werden

cgi

#!/bin/bash
cat << EOF
Content-Type text/html

 My Path is : $PATH
 My User is $(id -un)
 This host is $(hostname)
 
EOF


(Die Leerzeile vor pre wäre wichtig) (http://www.yolinux.com/TUTORIALS/LinuxTutorialCgiShellScript.html)

tools

ab

damit lässt sich der apache testen

apachectl
-l zeigt die geladenen module
-L liefert die Konfigurationsmöglichkeiten der geladenen Module

info/status

in der httpd.conf:

<Location /server-status>

   SetHandler server-status
   Order deny,allow
   Deny from all
   Allow from .example.com

</Location>

<Location /server-info>

   SetHandler server-info
   Order deny,allow
   Deny from all
   Allow from .example.com

</Location>

Hier sollte allerdings der Sicherheitsgedanken nicht vergessen werden


vhosts

Es gibt name- und ip-based vhosts


NameVirtualHost *:80

in der httpd.conf, um die Vhosts aufzudrehen Weiters muss der DocumentRoot und der Servername angegeben werden. Weitere Einträge wären optional

ssl

mod_ssl

installieren


in ssl.conf muss der Pfad zum localhost.key angepasst werden

unter /etc/pki/tls/ liegen die keys


openssl genrsa 1024 > ../private/localhost.key -x509 -days 3650 -out localhost.crt
/usr/bin/openssl req -new -key localhost.key  -x509 -days 365 -out ../certs/localhost.crt

ansatz für ssl auf vhosts: gnutls http://www.tech-nerds.de/blog/2009/02/apache2-mit-mehreren-ssl-virtualhosts/

Versuch ssl

apt-get install libapache2-mod-gnutls
a2dismod ssh
a2enmod gnutls

--- in ports.conf

<IfModule mod_gnutls.c>
 Listen 443
</IfModule>

in vhosts.conf

GnuTLSEnable on
GnuTLSPriorities NORMAL
GnuTLSCertificateFile /etc/apache2/ssl/ssl.key/vhost.crt
GnuTLSKeyFile /etc/apache2/ssl/ssl.key/vhost.key



openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

diverses

a2enmod 

installiert apache2-module

a2dismod

entfernt diese wieder

squid

  • kann http/ftp cachen
  • ssl wird 1:1 weitergeleitet
  • wird über squid.conf konfiguriert

squid.conf

ACCESS CONTROLS

ist aktiviert. Im Auslieferungszustand ist der Zugriff nur vom localhost erlaubt. Die ALC funktioniert auch per Domainname oder MACs. Ebenso ist die Möglichkeit der zeitabhängigen ACL gegeben

Danach ist mit http_access definiert, wer tatsächlich darf. http_access schließt mit "http_access deny all"


acl our_networks src 192.168.0.0/24 
http_access allow our_networks
MEMORY CACHE OPTIONS

ist per def auf 8mb gelegt, kann entsprechend angepasst werden

maximum_object_size_in_memory 8 KB

kann ebenso angepasst werden

DISK CACHE OPTIONS

ebenso kann auf Platten gespeichert werden:

  1. cache_dir ufs /var/spool/squid 100 16 256

100MB in 16 Unterverzeichnissen sowie 256 weoteren Unterverzeichnissen

  1. minimum_object_size 0 KB
  2. maximum_object_size 4096 KB

Das wären die mindest- bzw maximale größe der gespeicherten Dateien. Ev. interessant für Servicepacks o.ä.

grep '^[^#]' /etc/squid/squid.conf

würde auch hier die tragenden Parameter liefern

squid.conf

ACCESS CONTROLS

ist aktiviert. Die acl funktioniert auch per domainname oder MACs. Ebenso ist die Möglichkeit der zeitabhängigen ACL gegeben

Danach ist mit http_access definiert, wer tatsächlich darf. http_access schließt mit "http_access deny all"


acl our_networks src 192.168.0.0/24 http_access allow our_networks

MEMORY CACHE OPTIONS

ist per def auf 8mb gelegt, kann entsprechend angepasst werden

maximum_object_size_in_memory 8 KB

kann ebenso angepasst werden

DISK CACHE OPTIONS

ebenso kann auf Platten gespeichert werden:

  1. cache_dir ufs /var/spool/squid 100 16 256

100MB in 16 Unterverzeichnissen sowie 256 weoteren Unterverzeichnissen

  1. minimum_object_size 0 KB
  2. maximum_object_size 4096 KB

Das wären die mindest- bzw maximale größe der gespeicherten Dateien. Ev. interessant für Servicepacks o.ä.

grep '^[^#]' /etc/squid/squid.conf

würde auch hier die tragenden Parameter liefern


cachemgr

in /etc/httpd/conf.d legt squid eine squzid.conf an. Hier wird ein Alias erwähnt. Dieses wird allerdings nur vom localhost unterstützt

urlfiltering

squiguard.org

http://urlblacklist.com/



/etc/squid/squidGuard.conf

unter /var/squidGuard/blacklists.tar.gz liegt bereits eine Blacklist, sie muss allerdings noch entpackt werden

xpvs blacklists.tar.gz


chown squid:squid -R /var/log/squid
chown squid:squid -R /var/log/squidGuard
chown squid:squid -R /var/squidGuard


von urlblacklist.com kann automatisiert ein aktuelles File geladen werden

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

muss der squid.conf angefügt werden

squidGuard -C all -d -b

Ebenso muss die squidGuard.conf angepasst werden

Auswerten der Logs

calamaris

cat access.log | calamaris

liefert in stdout einen Report:

Proxy-Report

Report period: 06.Nov 14 12:09:49 - 06.Nov 14 13:41:40
Generated at:  06.Nov 14 13:41:52

# Summary
lines parsed:            429 
invalid lines:             0 
parse time (sec):          0 

# Incoming requests by method
method                             request      %    Byte       %   sec  kB/sec 
--------------------------------- --------- ------ -------- ------ ---- ------- 
GET                                     425  99.07  4198282  99.92    0   71.29 
POST                                      4   0.93     3406   0.08    0    7.11 
--------------------------------- --------- ------ -------- ------ ---- ------- 
Sum                                     429 100.00  4201688 100.00    0   70.77 

# Incoming UDP-requests by status
no matching requests              

# Incoming TCP-requests by status
status                             request      %    Byte       %   sec  kB/sec 
--------------------------------- --------- ------ -------- ------ ---- ------- 
HIT                                       0   0.00        0   0.00    0    0.00 
MISS                                    429 100.00  4201688 100.00    0   70.77 
ERROR                                     0   0.00        0   0.00    0    0.00 
--------------------------------- --------- ------ -------- ------ ---- ------- 
Sum                                     429 100.00  4201688 100.00    0   70.77 

# Outgoing requests by status
status                             request      %    Byte       %   sec  kB/sec 
--------------------------------- --------- ------ -------- ------ ---- ------- 
DIRECT Fetch from Source                429 100.00  4201688 100.00    0   70.77 
SIBLING                                   0   0.00        0   0.00    0    0.00 
PARENT                                    0   0.00        0   0.00    0    0.00 
--------------------------------- --------- ------ -------- ------ ---- ------- 
Sum                                     429 100.00  4201688 100.00    0   70.77 

# Outgoing requests by destination
neighbor type                      request      %    Byte       %   sec  kB/sec 
--------------------------------- --------- ------ -------- ------ ---- ------- 
DIRECT                                  429 100.00  4201688 100.00    0   70.77 
--------------------------------- --------- ------ -------- ------ ---- ------- 
Sum                                     429 100.00  4201688 100.00    0   70.77  


Calamaris $Revision: 2.59 $
Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Cord Beermann.
Calamaris comes with ABSOLUTELY NO WARRANTY. It is free software, and you are
welcome to redistribute it under certain conditions. See source for details.
Calamaris-Homepage: http://Calamaris.Cord.de/

Files Blocken

http://www.cyberciti.biz/faq/squid-content-filter-block-files/


SAMBA - NFS

  • Unix
    • /etc/exports
    • NFS -- network file system, auch ein Netzwerkprotokoll
    • udp/(seit version 4)tcp
    • Kernelmodule f. nfs oder Daemons (nfsd, mountd, ...)
    • nfs-utils...rpm
    • keine fixen Ports (via portmapper, tcp/111, mountd ist über 2049 erreichbar)

ACL

    • Konfigfile: IP
    • iptables
    • tcpwrapper (mountd, portmapper)
    • seit v4 kerberos



  • Windows
    • /etc/samba/smb.conf (ev. pro host eine eigene *.conf)
    • samba verwendet smb plus cifs
    • TCP
    • NMBD/SMBD-Process
    • für den Client ein Kernelmodul, falls er das Filesystem mounten möchte
    • fixe Ports: TCP 137-139, 445

ACL

    • Konfigfile IP+User
    • iptables


Um windows/unix kommunizieren zu lassen, müssen die jew. Systeme mittels eigenen nfs/smb-Clients auf den jeweiligen Server zugreifen. Winsrv2k8 hat mittlerweile einen NFS-Server eingebaut


samba

Globalbereich

  • Fileserver
  • Printserver
  • WINS-Server
  • Verweis auf zentrale Userdatenbank (zb AD)
  • kann als PDC einer nt-4.0-Domain fungieren
  • security: hier kann user/server/domain/ads oder share eingegeben werden:
    • default ist user, das bedeutet, es wird die lokale /etc/passwd verwendet, via nsswitch/pam. in der smbpasswd liegen die samba-passwörter, die beiden Files können mit passwordchat abgeglichen werden, der Nachteil, 2 pwd-stores, bleibt allerdings erhalten
    • server (win-OS): es wird unter "Servername" ein Windows-Rechner angegeben, dessen Userdatenbank wird von samba verwendet (nur samba!)
    • domain (win-OS): workgroup: dahinter steckt der Domänenname der win-Domain. Via DNS/WINS wird der zuständige DC gesucht
    • ads (win-OS): neben der Workgroup wird auch ein kerberus-realm verwendet
    • share (win-OS): wieder eine Windowsmaschine ähnlich dem Server, allerdings wird der User bei jedem Zugriff überprüft

es wird eigentlich nur mehr user oder ADS verwendet

  • SMB -> sharing
  • NMB -> für netBIOS
  • WINBIND-Daemon -> für AD

Alle dieser Daemons greifen auf die smb.conf zu.

Mit "net join" kann samba einer Windows-Domäne hinzugefügt werden

Mit testparm wird die syntax von smb.conf geprüft

testparm -v

liefert die default-Werte


Salba unterstützt ACLs, wenn das Fielsystem diese Optionen unterstützt

Es werden die Ports TCP 139/445 sowie UDP 137/138 verwendet.

Sharebereich

[sharenamen] 
 path=<pfad>
 pritable=no
 writeable=@staff --->staff darf schreiben, der rest nur lesen
 guest=no


Änderungen der .conf:

log file = /var/log/samba/%m.log

aktivieren

Auswahl der Art des Sambas

wins support = yes

erhebt samba zum WINS-Server


Printing Options

alle angeschlossenen Drucker sind automatisch freigegeben

FilesystemOptions


Misc


unix charset = ISO8859-1

damit sind Umlaute u.ä. möglich

Username Level = 8

setzt die Groß/Kleinschreibung für User ausser Kraft

hide dot files

um .*-Dateien auszublenden, sollte dieses aktiviert werden

idmap backend

um uid von der sid abzuleiten


Share Definitions das home der User wird automatisch freigegeben, allerdings sieht der User nur sein eigenes ~


smbpasswd -a another

legt für den bestehenden User another einen smb-user an

mittels

pdbedit -L 

werden alle in smb vorhandenen User angezeigt, mittels

pdbedit -v -u another 

genauere Informationen

SELinux!!

 chcon -t samba_share_t /data


nun kann von einer clientmaschine mit

nmblookup -A server116.example.com

auf die shares geschaut werden

mit

smbclient -L server107.example.com -U another


mount //server/public/ /mnt -o username=another


smbstatus 

am Server liefert Informationen, wer verbunden ist und ggf Dateien geöffnet hat

Samba version 3.0.33-3.14.el5
PID     Username      Group         Machine                        
-------------------------------------------------------------------
26018   another       another       192.168.0.16 (192.168.0.16)

Service      pid     machine       Connected at
-------------------------------------------------------
public       26018   192.168.0.16  Thu Jun 10 16:27:51 2010

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
26018        500        DENY_NONE  0x3         RDWR       NONE             /data   .test.swp   Fri Jun 11 0


SWAT

  • arbeitet mitcp/901
  • login erfolgt nicht über https
  • hier sind die password-chat-Konfigurationen auch per html möglich (mit Verweise auf die MANs)

NFS

  • dynamische Ports, daher ist der portmapper (Server und Client) nötig
  • die config liegt in /etc/exports und ist sehr einfach gehalten (leer bei der Installation)
  • lock-daemon (service nfs-lock) muss auf Server und Client laufen
  • läuft unter RedHat als Kernelmodul
rpcinfo -p localhost

überprüft den Portmapper

exports

/data           192.168.0.0/255.255.255.0(rw,sync)    172.30.22.0/24(ro)

wobei * bzw. *.example.com auch möglich wäre


das NFS-Port ist das einzige per default fixe Port, tcp/2049 In /etc/sysconfig/nfs können auch die anderen Ports fixiert werden:

#RQUOTAD_PORT=875
#LOCKD_TCPPORT=32803
#LOCKD_UDPPORT=32769
#MOUNTD_PORT=892
#STATD_PORT=662
#STATD_OUTGOING_PORT=2020
service nfslock status

auf Server+Client

# showmount -e server116
Export list for server116:
/data 192.168.0.0/255.255.255.0

liefert die Freigabe


mount server116:/data /mnt

mountet diese.

auch hier wäre eine zentrale Userdatenbank empfehlenswert

Der User root ist der einzige User, der gemappt wird (auf nobody). Der "normale" user verwendet seine eigene UID. Mittels der Option "no_root_squash" könnte dies abgeschalten werden.

export -r

würde die Änderungen übernehmen

DHCP

DHCP unterscheidet sich von BOOTP durch

  • die Anzahl der Optionen
  • dynamische Zuweisung - Leasetime (IPs aus Pool). In BOOTP wurde IP auf MAC fix gebunden
  • DHCP und BOOTP verwenden udp/67 für den Server, udp/68 für den Client, allerdings verwendet DHCP 4 und BOOTP 2 Pakete
  • BOOTP: 1 Server pro Netzwerk, DHCP unterstützt mehrere Server

Ablauf

  1. Client fordert eine IP-Adresse an - DHCP-DISCOVER
  2. Server antwortet mit einem DHCP-OFFER
  3. Client stellt einen DHCP-REQUEST
  4. Server sendet ein DHCP-ACK

Diese vier Pakete werden per Broadcast verteilt, alle Rechner im Netzwerk können diese sehen, da die IP erst nach dem 4. Schritt "dem Client gehört".

Mit diesem Angebot werden neben der IP mitgeschickt

  1. DNS
  2. Hostname
  3. Leasetime
  4. weitere Optionen

leasetime

nach der halben Leasetime fragt der Client, diesmal gerichtet, den Server, ob diese IP IP behalten werden darf

Sollte der Server nicht erreichbar sein, laufen 7/8 der Zeit ab, und der Client fragt deinen Server erneut. Bei Nichterreichen verliert der Client die IP

DHCP-relay

sollte der DHCP-Server NICHT im gleichen Netzsegment liegen wird (am Router) DHCP-relay verwendet. Der Relay erhält die BCs der Clients, und leitet diese gerichtet an den zuständigen DHCP-Server weiter

Konfiguration

in

/etc/sysconfig/dhcpd

können DHCP-Startoptionen fesetzt werden, so kann u.a. definiert werden, auf welchem Interface der DHCP hören/antworten soll

in

/etc/dhcpd.conf

geschieht die gesamte Konfiguration. Hier wird der DNS, das Default-GW uvm konfiguriert. Auch die Leasetime und der IP-Pool werden hier definiert. Auch werden statische IP-Zuweisungen hier eingestellt

Auch das DDNS wird hier (zumindest der DHCP-Teil) passiert in diesem File, die genaue Konfiguration für DHCP und DNS ist in der MAN beschrieben


unter

/var/lib/dhclient/dhclient-eth0.leases 

finden sich sämtliche Informationen, die der Client vom Server zugewiesen bekommen hat

lease {
 interface "eth0";
 fixed-address 192.168.0.5;
 filename "/kickstart/workstation.cfg";
 option subnet-mask 255.255.255.0;
 option routers 192.168.0.254;
 option dhcp-lease-time 21600;
 option dhcp-message-type 5;
 option domain-name-servers 192.168.0.254;
 option dhcp-server-identifier 192.168.0.254;
 option domain-name "example.com";
 renew 1 2010/6/7 14:49:27;
 rebind 1 2010/6/7 17:39:01;

unter

/var/lib/dhcpd/dhcpd.leases 

finden sich die IPs und Leases des DHCP-Servers

Mittels

dhclient

können IP-Informationen abgefragt werden

PAM

(pluggable authentication module)

  • ist fix im System verankert
  • kann von Apps genutzt werden
  • ist modular aufgebaut

Applications arbeiten entweder direkt über nss oder eben über PAM, wobei PAM wiederum auf NSS umswitchen kann, allerdings kann PAM auch LDAP, winBIND oder Kerberos verwenden

Accountinformationen können über LDAP, NIS bzw die lokale passwd bezogen werden, dies gilt für NSS als auch für PAM Authentifizierung bei kann über den LDAP, die lokale passwd, einen RADIUS, Smartcard, uvm passieren.

in /etc/pam.d/ existiert eine Datei, die wie die PAM verwendende Applikation heisst. Diese Datei besteht aus 3 Spalten und 4 Bereichen.


auth ---> Useridentifizierung
account ---> Access Controll
password ---> Password-Changes (zb abgelaufene/ablaufende Passwörter)
session ---> shell/session/config

Eine Applikation muss nicht alle bereiche benutzen. Jedes dieser 4 Regelwerke muss erfolgreich abgearbeitet werden

in der 2. Spalte wird einer der Werte required, requisite, sufficient oder optional

FTP

Derzeit ist vsftpd im Einsatz. Dieses Paket wäre PAM-gestützt, und beinhaltet Runlevelscripts. Im /etc/vsftpd liegen die Konfigs. chroot ist bei dieser version schon gesetzt


Die Datei "ftpusers" listet User auf, die nicht FTP nutzen dürfen

für ftp-UPload bzw bei Veränderungen am Pfad muss wiederum auf SELinux geachtet werden (man ftpd_selinux)


chroot_list_enable=YES
(default follows)
chroot_list_file=/etc/vsftpd/chroot_list

würde dafür sorgen, dass für alle in chroot_list definierten User ebenso chroot gilt


MAIL

Wurde in Linux 2 zusammengefügt

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge