NETWAYS’ Upcoming Training #Summer2018

Our Open Source trainings are designed to support your modern business processes

New Ways with NETWAYS – Our goal is to design your learning process as comfortable as possible! 


Foreman – Life Cycle Management for Servers
2 days training sessions | 03.07.2018 to 04.07.2018

CEPH – Scale out Storage
2 days training sessions | 03.07.2018 to 04.07.2018

GitLab – Modern Software Development
2 days training sessions | 10.07.2018 to 11.07.2018

Icinga 2 Fundamentals – Monitoring Redesigned
4 days training sessions | 10.07.2018 to 13.07.2018

Bareos – Level 1 – Introduction to Bareos
3 days training sessions | 16.07.2018 to 18.07.2018

Graylog – Centralized Logfile Management
2 days training sessions | 17.07.2018 to 18.07.2018

Bareos – Level 2  – Backup with LTO
2 days training sessions | 19.07.2018 to 20.07.2018

Ansible  Configuration Management
2 days training sessions | 24.07.2018 to 25.07.2018

Ansible AWX (Tower) 
1 day training session | 26.07.2018


For the whole NETWAYS training schedule visit: netways.de/training. For assistance please contact us.

 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

Die Extrawurst

Icinga Web 2 bietet eine Reihe von Möglichkeiten, Gruppen-Mitgliedschaften zuzuweisen. Am häufigsten werden Gruppenmitgliedschaften entweder via Web angelegt oder aus einem LDAP-Verzeichnis gezogen. Der bekannteste Vertreter dabei ist Microsofts Active Directory.

Weniger bekannt ist, dass man in eigenen Modulen Benutzer- sowie Gruppenmitgliedschafts-Backends bereitstellen kann. Manchmal braucht man aber gar nicht ein volles Backend, sondern nur ein paar kleine Korrekturen. Aus einem solchen Grund entstand diese Woche in einem Kundenprojekt ein neues Icinga Web 2 Modul: Extragroups.

Zusätzliche Gruppen für jeden

Einmal installiert, lassen sich in der config.ini des Moduls flexible Regeln definieren.

[Jeder ist ein Mimimi]
add_groups = "Mimimi"

Das allein hat erst mal keinen Effekt, also hinterlegen wir in der /etc/icingaweb2/roles.ini eine Rolle, welche unseren Usern eine entsprechende Einschränkung verpasst:

[Mimimi Demo]
groups = "Mimimi"
monitoring/filter/objects = "host_name=*mi*"

Sobald wir uns neu anmelden sind wir Mitglied der Gruppe “Mimimi” und sehen nur noch Hosts welche “mi” enthalten. Dabei ist nebensächlich, ob eine Benutzergruppe namens “Mimimi” existiert oder nicht.

Mustervergleich mit Benutzernamen

Lasst uns das Ganze ein wenig einschränken:

[Alle Heuler sollen Mimimis werden]
user_filter = "username=*heul*"
add_groups = "Mimimi"

Was hier passiert dürfte klar sein, wir machen nur noch unsere Heuler zu Mimimis.

Regeln basierend auf Umgebungsvariablen

Ihr möchtet alle Benutzer mit ein paar Ausnahmen in eine spezielle Gruppe geben, aber nur wenn diese remote arbeiten? Erstellt einfache eine auf deren IP-Range basierende Regel:

[Einschränkung wenn via VPN verbunden]
env_filter = "REMOTE_ADDR=192.0.2.*"
user_filter = "username!=tom&username!=admin"
add_groups = "Via VPN verbunden"

Ähnlich wie REMOTE_ADDR in diesem Beispiel können alle vom Web-Server bereitgestellten Umgebungsvariablen benutzt werden. Im nächsten Beispiel zeigen wir Netzwerk-Admins welche via Nagstamon angemeldet sind lediglich wirklich wichtige Hosts und Services:

[Filter für Nagstamon]
env_filter = "HTTP_USER_AGENT=Nagstamon*"
user_filter = "group=Network Admin"
add_groups = "VIP objects filter"

VORSICHT: Der User-Agent kann einfachst gefälscht werden. Dieses Beispiel dient dem Komfort unserer Benutzer: sie wollen in Nagstamon nicht mit allen Problemen belästigt werden. Für sicherheitskritische Regeln taugt der User-Agent nicht.

Mehrere Gruppen zuweisen

Manchmal will man mehrere Gruppen auf einmal zuweisen, ohne die ganze Regel zu klonen. Das lässt sich einfach bewerkstelligen, denn add_groups akzeptiert eine Komma-getrennte Liste:

[VPN-Benutzer einschränken]
; ..
add_groups = "Eingeschränkte Benutzer, Spezielle Dashboards, Business-Prozesse"

Soll die Gruppenliste noch dynamischer sein? Vorausgesetzt dass ein Webserver-Modul oder dessen Konfiguration diese Information bereitstellt, lässt sich jede Umgebungsvariable via {VARIABLE_NAME} nutzen:

[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"

Auch in Strings die aus Umgebungsvariablen kommen funktioniert das Komma (,) als Trennzeichen. Und man kann natürlich Variablen-Platzhalter mit statischen Werten kombinieren:

[Eine Reihe von Gruppen]
add_groups = "Spezial-Gruppe, {REMOTE_GROUPS}, {HTTP_AUTHZ_GROUPS}"

Auf Gruppenmitgliedschaften basierende Regeln

Der user_filter erlaubt auch Regeln basierend auf bereits zugewiesene Gruppen. In unserem umfangreicheren letzten Beispiel erhalten alle Benutzer zusätzliche Gruppenmitgliedschaften via HTTP_AUTHZ_GROUPS. Na gut, jeder außer der guest und der admin-Benutzer.

Wenn sie Nagstamon nutzen während sie via VPN verbunden sind, sollen sie zusätzlich in die Gruppe Nagstamon Remote kommen.

Wird Nagstamon ohne VPN benutzt, sollen Mitglieder der Gruppen “Linux Benutzer” und/oder “Unix Benutzer” in die Gruppe “Nagstamon Lokal” kommen. Alle außer dem admin:

[Gruppen des SSO-Moduls zuweisen]
add_groups = "{HTTP_AUTHZ_GROUPS}"
user_filter = "user_name!=guest&username!=admin"

[Nagstamon via VPN]
env_filter = "REMOTE_ADDR=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
add_groups = "Nagstamon Remote"

[Nagstamon ohne VPN]
env_filter = "REMOTE_ADDR!=192.0.2.*&HTTP_USER_AGENT=Nagstamon*"
user_filter = "username!=admin&(group=Linux Benutzer|group=Unix Benutzer)"
add_groups = "Nagstamon Local"

Dabei gilt es zu beachten, dass der Filter basierend auf die group-Eigenschaft nur Gruppen sieht, welche von vorhergehenden Regeln zugewiesen wurden. Von anderen Backends bereitgestellte Gruppenmitgliedschaften sind nicht zugänglich.

Das war’s auch schon, viel Spaß!

Thomas Gelf

Autor: Thomas Gelf

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

A personal Linux backup solution

Having personal backups is a must, but what can you do if you don’t have a mac that runs timemachine?

My first instinct was using the tool of choice of a friend: duplicity. It’s free software, does encryption and incremental backups, what more could you want? But duplicity does not offer a very user experience. The docs are work in progress, the –help is a bit of a mess and the man page is too verbose for a quick start. Obviously I have little problem reading and learning before using a tool, which is why I gave up and looked for a different one.

Restic does all what I want and duplicity can, but it has a good documentation, bash completion and other optional bonuses for making usage and, in turn, my life much easier.  It makes sense to think about what to backup before thinking about the right tool. I only want to backup from ~, I don’t care about `/etc` or other places with config or data, it would be no use to me when someone was to throw this laptop down a bridge. So just how much is lying around in my home directory?

$ du -h -d1 /home/jflach | grep "G" 
1.9G	/home/jflach/i2
4.3G	/home/jflach/.ccache
20G	/home/jflach/git
108G	/home/jflach/vmware
6.6G	/home/jflach/.cache
20G	/home/jflach/Documents
1.2G	/home/jflach/.thunderbird
3.3G	/home/jflach/Downloads
5.6G	/home/jflach/.vagrant.d
171G	/home/jflach

Luckily I have no folder with an upper case “G” in the name and I can see that over 50% are used up by vmare/. I don’t really need to backup my virtual machines, it’d be annoying to lose them but no reason to panic. `.ccache/`, `.cache/` and `Downloads` are completely irrelevant, bringing the total down to just above 50GB.

Back to restic. Creating a new local backup repository is easy:

$ restic init --repo /tmp/backup                                                                                                    
enter password for new backend: 
enter password again: 
created restic backend 929fc4f740 at /tmp/backup

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Now the for the actual backup, I have a file containing the excluded directories:

$ cat ~/.config/restic.exclude
Downloads
vmware
.ccache
.cache

And the command is simply:

$ restic -r /tmp/backup backup ~ --exclude-file=.config/restic.exclude
enter password for repository: 
password is correct
scan [/home/jflach]
scanned 10123 directories, 64039 files in 0:00
[11:07] 100.00%  76.166 MiB/s  49.612 GiB / 49.612 GiB  74162 / 74162 items  0 errors  ETA 0:00 
duration: 11:07, 76.12MiB/s
snapshot dd45c515 saved

It took eleven minutes on my machine to encrypt and compress about 50GiB of data. Restic starts a few threads and voraciously consumes CPU time and memory as it runs. Get yourself a fresh cup of coffee, working is no fun while the tool runs.

All that’s now left to do is to copy the directory to some external server or hard drive. Restic offers support for common sync tools like sftp, google cloud or rclone, whatever you use it will be your job to automate and define its behavior.

Jean Flach

Autor: Jean Flach

Geboren und aufgewachsen in Bamberg, kam Jean (das "-Marcel" ist still) nach einem Ausflug an die Uni, als Azubi zu NETWAYS. Dort sitzt er seit 2014 im Icinga 2 core Entwicklungsteam.

GitLab Security Update Reviewed

NETWAYS schreibt die Sicherheit ihrer gehosteten Kundenumgebungen groß – daher kamen auch wir nicht um das Sicherheitsupdate in den GitLab Community Edition und Enterprise Edition Versionen herum.

GitLab machte Mitte März öffentlich, dass man auf eine Sicherheitslücke sowohl in der Community als auch in der Enterprise Edition gestoßen sei. Dabei soll es sich um sogenannte Server Side Request Forgery (SSRF) handeln, was Angreifern unter anderem den Zugriff auf das lokale Netzwerk ermöglich kann. GitLab löste dieses Problem nun durch ein Software Update und den Einbau der Option “Allow requests to the local network from hooks and services“, die per default deaktiviert ist und somit den Zugriff der Software auf das lokale Netz unterbindet.

Das Update auf eine neuere Version ist für viele Nutzer eine gute Lösung – allerdings nur, wenn diese keine Webhooks oder Services, die das lokale Netz als Ziel haben, nutzen. Denn wenn plötzlich die Webhooks und Services nicht mehr funktionieren und weder der Admin noch der User weiß, dass man bei der obigen Option einen Haken setzen muss, dann beginnt erst mal die Fehlersuche.

Fazit: Wer unbedingt auf Webhooks und ähnliches angewiesen ist, muss wohl oder übel vorerst mit der Sicherheitslücke leben.

Eingebaut wurde der Fix in folgende GitLab CE und EE Versionen: 10.5.6 / 10.4.6 / 10.3.9. Eine vollständige Übersicht an Releases findet man hier: GitLab Release

Managed Hosting bei NETWAYSGitLab CE und GitLab EE

NETWAYS Web Services – 30 Tage kostenfreies Testen von GitLab CE und GitLab EE

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

Icinga Web 2 – todsicher.

Nachdem ich mich zuletzt in den Sänften Apples ausgeruht habe, geht es heute zurück ans eingemachte – oder besser gesagt: Back to the Roots! Selbst als alter Icinga Web 2– und Modulentwickler habe ich noch längst nicht alle Vorzüge dieses Feldes beansprucht.

Einer davon ist die Möglichkeit, alles Mögliche für die Authentifizierung herzunehmen. Einzige Voraussetzung: der Webserver muss mitspielen. Manche Authentifizierungsverfahren gelten als sicher, andere nur wenn das Passwort weise gewählt ist… aber zumindest eines ist todsicher: TLS (aka “SSL”) Client-Zertifikate. Die Vorteile liegen auf der Hand:

  • mit der folgenden Anleitung relativ einfach umzusetzen
  • Erstellung unsicherer Zertifikate (analog zu den Passwörtern) nicht möglich
  • keine geheimen/privaten Schlüssel werden während der Authentifizierung übertragen (kann man von Passwörtern nicht behaupten)
  • Unbefugte werden schon vom Webserver “abgefangen” und kommen gar nicht erst an Icinga Web 2 heran

Na dann riegeln wir mal ab…

Zertifikate erstellen

Sowohl der Webserver als auch jeder Client brauchen je ein TLS-Zertifikat, das von einer der Gegenseite vertrauenswürdigen Zertifizierungsstelle (CA) unterschrieben ist. Diese Unterschriften könnte ich einkaufen oder kostenlos beziehen, aber der Einfachheit halber erstelle ich mir für beide Seiten je eine CA und unterschreibe je ein Zertifikat.

Die Sänfte Apples bieten in der Schlüsselbundverwaltung einen Zertifikatsassistenten, aber auch der eingefleischte Linux-Sysadmin hat mit Openssl ein Umfangreiches Bordmittel zur Verfügung.

Server

Im Gegensatz zum Client müssen Nutzer beider Betriebssysteme darauf achten, dass das Server-Zertifikat über einen sog. “subjectAltName” verfügt. Sonst staunt man beim Aufbau der Umgebung nicht schlecht: Trotz Vertrauen in die CA und passendem commonName erkennt zumind. Google Chrome das Zertifikat nicht an.

Die hervorgehobenen Stellen müssen höchst wahrscheinlich an die eigene Umgebung angepasst werden – z.B. eine Domäne statt einer IP Adresse und damit auch CN_KIND=DNS.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - server' -md5 -keyout ca-server.key -out ca-server.crt -nodes

CN_KIND=IP ; CN=172.28.128.3

openssl req -newkey rsa:4096 -subj "/CN=$CN" -keyout server.key -out server.csr -nodes

openssl x509 -req -in server.csr -sha512 -out server.crt -CA ca-server.crt -CAkey ca-server.key -CAcreateserial -extensions SAN -extfile <(printf '[SAN]\nsubjectAltName=%s:%s' "$CN_KIND" "$CN")

Client

Bis auf den hier nicht nötigen “subjectAltName” – das gleiche in grün.

openssl req -x509 -newkey rsa:4096 -subj '/CN=example com CA - client' -md5 -keyout ca-client.key -out ca-client.crt -nodes

openssl req -newkey rsa:4096 -subj '/CN=Alexander Klimov' -keyout client.key -out client.csr -nodes

openssl x509 -req -in client.csr -sha512 -out client.crt -CA ca-client.crt -CAkey ca-client.key -CAcreateserial

Kleines Easter-Egg am Rande: Es spielt keine Rolle, ob ein Root-CA-Zertifikat mit SHA512, MD5 oder handschriftlich signiert wurde, da es nur auf dessen Vorhandensein im eigenen Schlüsselbund ankommt.

Zertifikate importieren

Ein nicht offizielles Server-CA-Zertifikat und das eigene Client-Zertifikat muss natürlich in den Browser importiert werden. Dafür ist ein kleiner Zwischenschritt nötig:

alexanders-mbp:debian aklimov$ openssl pkcs12 -in client.crt -inkey client.key -export -out client.p12
Enter Export Password:
Verifying - Enter Export Password:
alexanders-mbp:debian aklimov$

“client.p12” (und evtl. “ca-server.crt”) kann anschließend in den Browser importiert werden. Leider ist ein temporäres Passwort unumgänglich, aber “123456” o.ä. geht auch.

Wer diesen Schritt verschleppt, fällt bei der Einrichtung von Icinga Web 2 auf die Nase: Entweder beschwert sich der Browser über eine “nicht sichere” Verbindung oder der Webserver weist die Verbindung ab.

Icinga Web 2 installieren

DIST=$(awk -F"[)(]+" '/VERSION=/ {print $2}' /etc/os-release); \
echo "deb http://packages.icinga.com/debian icinga-${DIST} main" >  /etc/apt/sources.list.d/${DIST}-icinga.list; \
echo "deb-src http://packages.icinga.com/debian icinga-${DIST} main" >>  /etc/apt/sources.list.d/${DIST}-icinga.list

wget -qO - https://packages.icinga.com/icinga.key | apt-key add -
apt update
apt install icingaweb2 -y

cp /vagrant/server.crt /etc/ssl/certs/todsicher.pem
cp /vagrant/server.key /etc/ssl/private/todsicher.pem
cp /vagrant/ca-client.crt /etc/ssl/certs/todsicher-ca.pem

a2dissite 000-default.conf
a2enmod ssl
a2enmod headers
vim /etc/apache2/sites-available/todsicher.conf
a2ensite todsicher.conf
service apache2 restart

Nachdem das Icinga-Repository hinzugefügt wurde, kann auch schon das Paket “icingaweb2” installiert werden. Dieses bringt den Apache-Webserver mit und integriert sich entsprechend. Darauf hin müssen die Zertifikate installiert und deren Verwendung konfiguriert werden.

/etc/apache2/sites-available/todsicher.conf

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	RewriteEngine On
	RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/todsicher.pem
	SSLCertificateKeyFile /etc/ssl/private/todsicher.pem
	Header always set Strict-Transport-Security "max-age=2678400"

	SSLCACertificateFile /etc/ssl/certs/todsicher-ca.pem
	SSLVerifyClient require
	SSLVerifyDepth 1
	SSLUserName SSL_CLIENT_S_DN_CN
</VirtualHost>

Sollte jemand auf die Idee kommen, den Server mit HTTP anzusprechen, wird er bedingungslos auf HTTPS umgeleitet – und diese Tat auch nicht wiederholen.

Außerdem wird ein TLS-Client-Zertifikat verlangt, das von entsprechender CA unterschrieben sein muss. Dessen commonName wird im Erfolgsfall als Nutzername behandelt – und genau auf diesen Zug springt Icinga Web 2 auf…

Icinga Web 2 einrichten

Nun greift man via Browser auf Icinga Web 2 zu und richtet es wie gewohnt ein… naja, fast wie gewohnt…

Nachdem der Browser nach dem zu verwendenden Client-Zertifikat gefragt hat, grüßt die Anmeldemaske, die auf den Einrichtungsassistenten verweist. Dieser fordert wie zu erwarten den Einrichtungstoken. Nach dessen Eingabe habe ich ausnahmsweise sämtliche Module deaktiviert, da… dieser Blogpost eh schon viel zu lang ist. (Aber nur die Ruhe, wir haben’s schon fast.)

Nach einer kleinen Anpassung der PHP-Konfiguration und einem darauf folgenden Neustart des Webservers…

root@contrib-stretch:~# perl -pi -e 's~^;date\.timezone =.*?$~date.timezone = Europe/Berlin~' /etc/php/7.0/apache2/php.ini
root@contrib-stretch:~# service apache2 restart

… bestätigt auch schon die erste Ausnahme die Regel: Der Typ des Authentifizierungs-Backends ist auf “Extern” zu setzen, da dies der Webserver übernimmt. Die folgenden Einstellungen des Backends können bei dem voreingetragenen belassen werden. Wenn alles richtig konfiguriert wurde, schlägt der Assistent den bedienenden Benutzer als Administrator vor. Ab da bleiben nur noch die Formalitäten…

Fazit

Wer auf das Monitoring-System Zugriff hat, hat viel Macht.

Bernd Erk, NETWAYS CEO

Tja Bernd, auf mein Monitoring-System hat kein Unbefugter mehr Zugriff – todsicher.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Konfiguration des Proxyserver Squid mit SquidGuard und Authenifizierung


Ich werde heute beschreiben wie man den Proxy-Server Squid mit SquidGard einrichtet und Zugriff per Benutzer-Authentifizierung.
Anlass ist, das ich selbst bei mir zuhause diese Kombination einsetze, um meinen Kindern manche nicht kinderfreundlichen Inhalte im Web zu ersparen und zu blocken.
Es gibt verschiedene Einsatz-Scenarien von Squid z.B als Caching von Webseiten zum schnellen Anzeigen im Browser.
Zuerst muss man die Pakete dafür installieren, bei mir im Fall von openSUSE-Leap. Pakete können sich bei anderen Linux Distributionen unterscheiden.
zypper in squid squidGuard
Anschließend den Proxyserver Squid beim Systemstart aktivieren:
systemctl enable squid.service
Starten von Squid
systemctl start squid.service
Bei der fertigen Umgebung wird Squid die Anfragen über den SquidGuard leiten, zum die URL’s oder Domains zu überprüfen, ob derjenige Benutzer die Inhalte sehen darf oder nicht.

Als erstes konfiguriere ich den Squid, Konfigurationsdatei liegt unter:

cd /etc/squid/ && vim squid.confz.B meine squid.conf
auth_param basic program /usr/sbin/basic_pam_auth #----> Wichtig Authentifizierung von Usern, wird per Popup erscheinen
auth_param basic children 5 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
acl localnet src 192.168.100.0/24 # RFC1918 possible internal network #----> Wichtig Zugriff Regel für das Netz von Squid
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet password
http_access allow localhost
http_access deny all
http_port 3145
coredump_dir /var/cache/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
err_page_stylesheet /etc/squid/errorpage.css
redirect_program /usr/sbin/squidGuard -c /etc/squidguard.conf #-----> Wichig weiterleitung über SquidGuard und liest Konfig von squid ein
redirect_children 5 #----> Wieviele Kindprozesse darf Squidguard öffnen.

Es wird in dieser Konfig-Datei vieles per Kommentar erklärt, hier empfiehlt sich es mal gelesen zu haben.

Dann müssen noch Berechtigungen der Datei
/usr/sbin/basic_pam_auth
gesetzt werden, damit die Authentifizierung über die angelegten Benutzer funktioniert:
chgroup shadow /usr/sbin/basic_pam_auth
chmod g+s /usr/sbin/basic_pam_auth

Damit alles aktiv geschaltet wird müssen wird den Proxyserver neustarten:
systemctl restart squid.service

So jetzt damit kommen wir zum SquidGuard:
Die Konfigurationsdatei heisst:
vim /etc/squidguard.conf;
Ein Beispiel von mir:
logdir /var/log/squidGuard
dbhome /var/lib/squidGuard/db
src parents {
ip 192.168.100.0/24 # range 192.168.10.0 - 192.168.10.255
# AND
user papa mama # ident Papa und Mama
}
src kids {
ip 192.168.10.17 # Notebook Kind 1
user username # ident Kind1
# AND
ip 192.168.10.14 # Notebook Kind 2
user username (Kind # ident Kind2
}
dest blacklist {
domainlist blacklist/domains
urllist blacklist/urls
}
#####
#
# Zeitregeln
#####
# abbrev for weekdays:
s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
time tagsueber {
weekly mtwhfas 12:00-16:00 # Unter der Woche
}
acl {
parents {
pass all
}
kids {
pass !blacklist all
}
default {
pass none
redirect http://hostname/cgi-bin/squidGuard.cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&url=%u

Die Datei ist eigentlich sehr einfach strukturiert und auf der Webseite von SquidGuard gut erklärt, deswegen verlinke ich hier gern:
http://www.squidguard.org/Doc/configure.html

Für das Blocken von nicht kinderfreundlichen Seiten gibt es schon fertige Listen, die das meiste auch schon abdecken:
Block-Listen
Diese Listen müssen entpackt und in das Verzeichnis:
cd /var/lib/squidGuard/db/blacklist/
kopiert werden und anschließend initialisiert werden:
squidGuard -C all

So, jetzt sollte alles soweit funktionieren, testen kann man am besten, in dem man mit einem Benutzer, der für das Blocken eingerichtet ist, geblockte URL’s oder Domains aufzurufen, um zu sehen ob diese Seite aufgerufen werden kann.

In diesem Sinne Have Fun!

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren