HomeMatic CCU2 in Betrieb nehmen

Nachdem ich meine ersten Schritte der HomeAutomation mit einer auf einem Raspberry PI basierten FHEM gegangen bin, dabei aber durchweg auf HomeMatic Komponenten gesetzt habe, wollte ich nun auch die Steuerzentrale die direkt von HomeMatic angeboten wird testen.

Inbetriebnahme

Der Aufbau und der erste Start des Gerätes ist recht einfach wenn man sich etwas mit IT auskennt und nicht versucht sich an die Anleitung zu halten. Darin steht nämlich z. B. dass man die Webseite der Steuerzentrale im lokalen Netz über http://homematic-ccu2 erreichen kann – was natürlich in jedem normalen Netz nicht funktionieren wird. Im Gegenteil findige Werbetreibende haben die URL mit .com erweitert registriert und genau dort landet man mit gängigen Browsern auch da diese von einem Tippfehler ausgehen.

Nachdem man es also hinbekommen hat die IP Adresse des neuen Gerätes entweder über den eigenen Router oder die HomeMatic Windows Software herauszufinden, wird man von der Software begrüßt und gebeten ein Update durchzuführen (sehr sinnvoll). Die Startseite in welche man danach geleitet wird ist sehr übersichtlich und man findet sich recht schnell darauf zurecht.

image

Sicherheitsschlüssel ändern

Die wichtigen Dinge zuerst ;-). Über den Button Einstellungen –> Systemsteuerung erreicht man das Menü mit den wesentlichen Einstellungsmöglichkeiten der Software. Unter dem Punkt Sicherheit hat man hier auch die Möglichkeit den verwendeten AES Schlüssel von dem sonst verwendeten Standard (identisch auf allen Geräten und daher nicht empfehlenswert) abzuändern. Den neuen Schlüssel sollte man auf jeden fall an einem oder besser mehreren sicheren Orten aufbewahren! Man kann in dieser Maske zudem den SSH Server aktivieren und ein Backup erstellen (empfehlenswert nachdem man den Sicherheitsschlüssel geändert hat).

image

Zeitserver Ändern

Im Standard verwendet die CCU2 einen Zeitserver von Homematic. Da man damit für den Hersteller transparent macht, dass man seine Produkte verwendet etc. stelle ich diese Einstellung auf einen allgemeinen ntp server um. In der Systemsteuerung klickt man hierfür auf Zeit-/ Positionseinstellung und ändern den Wert des Zeitservers wie in meinem Beispiel ab:

image

CCU – Firewall

Die Adressbereiche die für den eingeschränkten Zugriff verwendet werden, werde nicht mit den vom DHCP Server erhaltenen Daten abgeglichen. Ich habe bei mir ein 10er Netz und die Freigaben waren für ein 192er class B eingerichtet. Man sollte diese Einstellungen somit auf sein eigenes Netz anpassen und speichern. Erreichen kann man diese über den Menüpunkt Firewall konfigurieren ebenfalls in der Systemsteuerung.

Allgemeine Einstellungen

Wer mit der CCU2 auch mit dem Preis pro kWh Strom oder Gas rechnen möchte, kann die dafür derzeit relevanten Kosten unter Allgemeine Einstellungen hinterlegen. Das ist ggf. hilfreich wenn man z. B. mit Hilfe der Schaltsteckdosen den Stromverbrauch des Trockners oder des Kühlschranks ermitteln möchte.

Gerät anlernen

Die Anlage wird natürlich erst durch die Angeschlossenen Geräte nützlich. Daher klicken wir im rechten oberen Eck auf den Button Geräte anlernen. Daraufhin öffnet sich folgendes Fenster und der Lernmodus ist für 60 Sekunden aktiv. Innerhalb dieser Zeit sollte man auf dem anzulernenden Gerät ebenfalls den entsprechenden Knopf betätigen. Für jedes erfolgreich angelernte Gerät sollte der Zähler unter Posteingang am Ende der 60 Sekunden entsprechend erhöht werden.

image

Klicken Sie auf den Posteingang und prüfen Sie ob alle gewünschten Geräte aufgeführt sind. Handelt es sich bei dem Gerät um einen Tausch eines bestehenden Gerätes, so können Sie dies über die Aktion im System hinterlegen. Um das Gerät verwenden zu können, müssen Sie den Button Fertig betätigen. Sie können auch bereits in dieser Ansicht anfangen ihre Geräte in Gruppen zusammen zu fassen z. B. Kinderzimmer.

image image

Facebooktwittergoogle_pluslinkedinmail

MySQL Server Absichern

Oft gewünscht – bei MySQL vorhanden: Das mach mich sicher Skript! Um einen MySQL server im ersten Schritt abzusichern gibt man als root folgenden Befehl ein:

mysql_secure_installation

Danach folgen eine Handvoll Fragen die natürlich mit dem MySQL-root-Benutzer anfangen:

image

image

image

image

image

Hat man die Fragen alle richtig beantwortet, so sind die Testdaten und Zugänge aus dem System entfernt, der root Benutzer abgesichert und die entsprechenden Privilegien richtig gesetzt. Zusätzlich empfehle ich den Datenbankport nicht auf der Firewall freizuschalten damit ganz sicher keiner von außen auf das System kommt. Wie man das mit Hilfe von iptables macht erkläre ich hier.

Facebooktwittergoogle_pluslinkedinmail

Debian Webserver – Einstellungen für die Mailzustellung (MTA)

Ein Webserver soll in aller Regel auch die Fähigkeit besitzen eMails zu senden. Ich bin ein großer Freund davon diese Systeme zu trennen und auf den Webservern den MTA (in unserem Fall exim4) so einzustellen, dass er ausgehende Mails an einen dedizierten Webserver (Smarthost) zum Versand weiter gibt. Auf diesem Weg umgeht man zum einen die Komplexität der umfänglichen Konfiguration eines Mailserver und zum anderen muss man sich nicht mit Problemen wie SPAM-listen etc. herumschlagen. Auf unserem System starten wir die Konfiguration wie folgt (vorausgesetzt exim4 ist schon installiert – sonst muss man dies mit apt-get install exim4 noch erledigen):

# dpkg-reconfigure exim4-config

SNAGHTMLa8d3bfdimage image image image image image image

Nach der Grundkonfiguration von exim müssen wir noch die Zugangsdaten für unseren Smarthost hinterlegen (heute sollte es keinen offenen Mailserver mehr geben – und wenn steht er mit Sicherheit auf allen SPAM listen und sollte nicht verwendet werden). Hierzu fügen wir in der Konfigurationsdatei /etc/exim4/passwd.client unsere Zugangsdaten ein:

# vi /etc/exim4/passwd.client
target.mail.server.example:login:password

Da mein Mailserverprovider noch immer auf SSL (Port 465) setzt und noch kein STARTSSL (Port 587) anbietet, muss ich EXIM noch beibringen sich auch entsprechend mit dem Server zu verbinden. Dies erledigt man in der Konfigurationsdatei /etc/exim4/exim4-conf-template. Dort sucht man nach dem String (der Doppelpunkt am Ende ist wichtig):

remote_smtp_smarthost:

und fügt danach folgendes ein:

protocol=smtps

SNAGHTMLac113d7

Mails an den Root Benutzer weiterleiten

Es gibt diverse Services (z. B. cron) welche Nachrichten an den root-Benutzer des Systems schicken. Um diese Nachrichten in angemessener Zeit verarbeiten zu können ist es ratsam diese an eine Mailadresse weiterzuleiten

# vi /etc/aliases

in diese Datei fügt man die Zeile:

root:whatever@fragmichnicht.de

ein und lässt danach die Aliase neu erstellen

# newaliases

Nun sollten die Maileinstellungen des Server vollständig funktionsfähig sein und ausgehende Mails (z. B. von einem Blog-System oder cron) an die dafür vorgesehenen Adressen versendet werden.

Facebooktwittergoogle_pluslinkedinmail

Kernel für einen Webserver härten

Die Standards der meisten Debian Vorlagen von Hostern enthalten oft schon einige Verbesserungen der Sicherheitseinstellungen. Es schadet aber nicht diese zu prüfen und ggf. zu justieren. Der einfachste Weg besteht dabei darin eine Kopie der Konfigurationsdatei sysctl.conf zu erstellen und dort die eigenen Einstellungen zu hinterlegen (so behält man immer die Standards und bekommt keine Probleme bei Systemupdates):

# cp /etc/sysctl.conf /etc/sysctl.d/local.conf

In der kopierten Datei sollten folgende Werte (fett) angepasst bzw. auskommentiert werden. Die Beschreibungen über den Werten selbst sind recht aussagekräftig. Ich verzichte jetzt mal dies alles zu wiederholen:

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
#kernel.domainname = example.com
# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3
##############################################################3
# Functions previously found in netbase
#
# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1 
# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
net.ipv4.tcp_syncookies=1
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1
###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#
Facebooktwittergoogle_pluslinkedinmail

SSH-Zugang Absichern und Härten

Normalen (nicht root) Benutzer anlegen

Bevor wir uns um das Absichern/Härten des SSH Zugangs kümmer können ist es wichtig einen regulären Benutzer auf dem System anzulegen. Dies erledigt man auf der Kommandozeile mit folgendem Befehl:  

adduser fragmichnicht

Adding user `fragmichnicht' ...

Adding new group `fragmichnicht' (1002) ...

Adding new user `fragmichnicht' (1002) with group `fragmichnicht' ...

Creating home directory `/home/fragmichnicht' ...

Copying files from `/etc/skel' ...

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for fragmichnicht

Enter the new value, or press ENTER for the default

Full Name []:

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] y

SSH Schlüssel erzeugen und einbinden

Als nächsten Schritt legen wir uns einen private und einen public-key an um diesen für die Anmeldung via ssh verwenden zu können. Passwörter sind schon lange nicht mehr wirklich sicher und die Verwendung von solchen keys ist zudem deutlich praktischer als die Verwendung von vermeintlich sicheren Passwörtern. Die Schlüssel erstellen Sie entweder über die Linux Kommandozeile oder über das Windows tool Putty Key Generator.

Den Private-Key schützt man auf seinem lokalen System am besten weiterhin mit einem Passwort und speichert ihn an einem sicheren Ort. Der Schlüssel sollte nach Möglichkeit wirklich privat sein und nicht aus den Händen gegeben werden. Den Public-key zu veröffentlichen ist dagegen kein wirkliches Problem (wie der Name schon impliziert).

cd /home/fragmichnicht/  

mkdir .ssh

chmod 700 .ssh

chown fragmichnicht:fragmichnicht .ssh

cd .ssh

vi authorized_keys

Hier fügen wir nun den public key zu dem Schlüsselpaar welches wir gerade erstellt haben ein.

Danach fügen wir den neu angelegten Benutzer der Gruppe sudo hinzu damit dieser sich jederzeit via sudo root Rechte besorgen kann.

usermod -a -G sudo fragmichnicht

Sollte sudo noch nicht installiert sein so erledigt dies ein:

apt-get install sudo

Wenn ihr für die Benutzer der Gruppe sudo nicht wollt, dass diese ein Passwort eingeben müssen um sich root Rechte zu besorgen, dann erreicht man dies über folgende Zeile in der /etc/sudoers (Änderungen an dem file über visudo!)

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL) NOPASSWD: ALL

Härten der SSH-config

An sich sollte sich ein root-Benutzer nie direkt remote an einem System anmelden können und auf einem Server benötigt man auch keine grafische Oberfläche (X11). Ich poste nachfolgend meine sshd-config mit allen Werten (die geänderten fett gedruckt). Je nach System und Version müssen ggf. mehr Werte angepasst werden um zu dieser Konfiguration zu kommen. Die Änderungen an der Konfiguration müssen mit root-Rechten und folgendem Befehl durchgeführt werden:

vi /etc/ssh/sshd-config

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Damit die Einstellungen wirksam werden muss der SSH Dienst neu gestartet werden. Dies erreicht man mit dem Befehl:

/etc/init.d/ssh restart

Damit sind die Grundlagen für einen sicheren SSH-Zugang zu dem eigenen Server gelegt.

Facebooktwittergoogle_pluslinkedinmail