Archiv: News

  • 0

phi Medien Systeme GmbH: Deutschland hat den besten Datenschutz

Kategorie : Allgemein , News

Im Ausland wird das Thema Datenschutz teilweise deutlich weniger streng gehandhabt als in Deutschland. Regierungen, Geheimdienste und andere Dritte haben eventuell Zugriff. In Deutschland regelt hingegen das Bundesdatenschutzgesetz den Umgang mit personenbezogenen Daten. Es gibt vor, dass jeder selbst darüber entscheiden kann, was mit seinen Daten gemacht wird – das nennt sich informationelle Selbstbestimmung. Jeder kann sich beispielsweise eine Auskunft einholen, ob Daten von ihm gespeichert wurden und woher diese stammen. Auch der Anbieter, die diese Daten verarbeiten müssen dafür sorgen, dass sie nicht in fremde Hände kommen. Anbieter sind also zum Datengeheimnis verpflichtet.

Spätestens seit den Enthüllungen rund um die Dauerüberwachung durch Geheimdienste der USA und Großbritanniens sind Nutzer zunehmend sensibler geworden – und das zu Recht.

Schnelle Anbindung freut die Nutzer

Es ist kein Zufall, dass internationale Anbieter wie Google, Facebook oder Apple überall auf der Welt Rechenzentren haben. Denn auch wenn man im Internet im Prinzip jeden Inhalt von überall her abrufen kann, hat der Standort spürbare Auswirkungen auf die Ladezeit. Und Experten wissen: Ruft der potenzielle Kunde eine Website auf, zählt jeder Bruchteil einer Sekunde.

Google findet es ausgezeichnet

Das Ranking einer Website wird durch einen lokalen Serverstandort verbunden mit einer lokalen Länder-Domain positiv beeinflusst. Eine .de-Domain und ein deutscher Serverstandort sind für Suchergebnisse in Deutschland deshalb von Vorteil. Google bewertet also lokale Seiten innerhalb eines geografischen Raums höher.

phi betreibt seine Server mit eigener Solaranlage mit 41kWp und CO2-neutralem ÖKO Strom

Deutschland ist sehr engagiert im Umweltschutz – das kann man nicht von einigen unserer Nachbarländer behaupten und schon gar nicht von den USA. Ein Rechenzentrum verbraucht eine Menge Strom, daher ist es ökologischer, wenn dieser aus erneuerbaren Energien in Deutschland stammt. Beim Hoster phi setzen wir zudem auf Ressourcen-sparende technische Bauteile. Grünes Hosting – ja, das gibt es! Unserer Server betreiben wir vollständig mit CO2-neutralem Strom aus eigener Solaranlage mit 41kWp und von ÖKO Strom Lieferanten.

Prompte Hilfe im Fall der Fälle

So mancher Anbieter hat zwar einen deutschsprachigen Kundenservice, aber das Rechenzentrum befindet sich im Ausland. Problematisch wird das im Fall der Fälle, sobald ein Problem auftritt, das schnell behoben werden soll. Dann müssen sich Servicetechniker vor Ort und der Kundenservice erst einmal kurzschließen und eventuell noch Sprachbarrieren überwinden. Ein Hoster, der wie phi praktisch nebenan sitzt, hat es da um einiges einfacher und kann flexibler so wie schneller auf eventuelle Störungen reagieren.

Share

  • -

Meltdown und Spectre

Kategorie : News

 

Viele Kunden fragen sich derzeit, ob Sie ebenfalls von den unter den Namen „Spectre“ und „Meltdown“ bekannten Sicherheitslücken betroffen sind.

Seid Ihr auch betroffen?

Wir benutzen für unsere Infrastruktur zu 100% VMWare vSphere basierte Hardware Virtualisierung, unsere VM Hosts sind dadurch von Haus aus schon mal nicht verwundbar gegen Meltdown. Die Sicherheitspatches wie im VMWare Security Advisory beschrieben (https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html) haben wir bereits vor dem Release des SA mit dem Kumulativen Sicherheitspatch ESXi650-201712401-BG am 02.01.2017 auf allen Hosts installiert. Das Auslesen eines Speicherbereichs der nicht zur eigenen VM gehört ist damit nicht möglich.

Das Patchen der Gast Systeme (Ihrer VMs) obliegt Ihnen als System Owner. Fühlen Sie sich dazu nicht in der Lage, können Sie die Aufgabe des Patch Managements gerne an uns übertragen. Melden Sie sich dazu einfach telefonisch über die 02461 59360 oder via eMail an die support@phi.de.

 

Worum geht es überhaupt?

Spectre und Meltdown nutzen kritisch Sicherheitslücken in Modernen Prozessoren aus. Es handelt sich hier um einen Fehler in der Hardwarearchitektur.

Die Meltdown Lücke betrifft jeden Intel Prozessor seit 1995 (mit out-of-order execution) außer Intel Itanium und Intel Atom Prozessoren mit einem Baujahr vor 2013. Bei AMD Prozessoren ist derzeit noch unklar ob diese ebenfalls betroffen sind. ARM Prozessoren sind teilweise ebenfalls betroffen. (https://developer.arm.com/support/security-update)

Die Spectre Lücke betrifft nahezu jeden Prozessor, das Google Project Zero hat die Spectre Lücke jedenfalls sowohl auf AMD, Intel als auch auf ARM CPUs ausnutzen können.

Die technischen Details sind in der oben verlinkten Projekt Seite nach zu lesen. Grundsätzlich ermöglichen beide Lücken, sofern sich ein Angreifer auf dem System befindet, den Speicherzugriff vom Speicherbereich eines Programmes in den Speicherbereich eines anderen Programmes. Theoretisch wäre es also möglich Daten aus dem Home-Banking Programm über das ausnutzen dieser Lücken zu extrahieren.

Wieso theoretisch?

Der Angreifer braucht Zugriff auf das verwundbare System um diese Lücken ausnutzen zu können.

Nähere Informationen zu den genannten Sicherheitslücken sind hier zu finden.

https://spectreattack.com/

Es sind derzeit keine fälle bekannt bei denen Spectre und Meltdown durch Angreifer ausgenutzt worden sind.

Wo finde ich Patches?

Achten Sie auf die von Ihrem Softwarehersteller bereitgestellten Sicherheitspatches und installieren Sie diese Zeitnah.

Kann ich Spectre und Meltdown in Aktion erleben?

Ja. Das Project Zero hat hierzu 4 kleine Video Schnipsel aufgenommen.

Share

  • -

Neuer kompakter Hochleistungscluster

Kategorie : News

Es gibt Nachwuchst in der Firma phi Medien System GmbH. Ein neuer VMware Cluster von der Firma HP (DL580) mit zwei Servern ist in unserem Brandabschnitt eingezogen.

Mit einer Leistungsfähigkeit von 672 GB Arbeitsspeicher und 192 GHz Prozessor Takt aufgeteilt auf 160 logische CPU Kernen. Der neue Cluster, bestehend aus 2 Nodes mit jeweils 4 CPUs a 10 Kernen getaktet auf 2,4 GHz, ermöglicht uns die Aufnahme sehr großer zusammenhängender VMs wie beispielsweise Render-Nodes oder Raster Image Prozessoren.

Durch seine 32 physikalischen Netzwerkkarten á 1Gbit/s sind wir in der Lage auch Physikalisch getrennte Kunden-netze zu realisieren und hiermit auch höchsten Sicherheitsansprüchen gerecht zu werden.

Der Hochleistungscluster ist an unsere 16 Gbit/s FC SAN für maximale Verfügbarkeit angebunden. Damit sich zugleich auch nicht alles auf einem Node abspielt, sorgt unser 10 Gbit/s Backbone Netz in zusammenarbeit mit dem Distributed Resource Scheduler für eine ausgeglichene Lastverteilung. Die interne Kommunikation innerhalb der Kunden-netze erfolgt hier ebenfalls mit 10 Gbit/s.

Betrieben wird unser neuer Hochleistungscluster mit der Software vSphere Enterprise Plus 6.5 der gleichzeitig mit dem vCenter 6.5 zusammen arbeitet. Sie bietet Kernfunktionen zur Einhaltung der garantierten Service-Levels, wie z.B. Minimierung von Ausfallzeiten, Datensicherheit und automatisiertes Ressourcenmanagement.

Share

  • -

Zimbra – Nach Mails in den Log-Files suchen

Kategorie : News

Wenn man nachvollziehen möchte, ob eine Mail gesendet bzw. empfangen wurde, kann man selbstverständlich die Log-Files manuell durchsuchen. Hilfreicher ist aber der Befehl ‚zmmsgtrace‘. Dieser Befehl durchsucht standardmäßig die Log-Datei ‚/var/log/zimbra.log‘.

Die Syntax ist dabei:

zmmsgtrace [options] [<mail-syslog-file>...]

Hier die Beschreibung der wichtigsten Optionen (in Englisch):

Long Name Short Name Description
–help Shows the help for the usage options for this tool.
–id -i Message ID. Case sensitive regex.
–sender -s Sender address. Case insensitive regex.
–recipient -r Recipient address. Case insensitive regex.
–srchost -F Source host, using hostname or IP. Case insensitive regex.
–desthost -D Destination host, using hostname or IP. Case insensitive regex.
–time -t Start, end times in YYYYMM[DD[HH[MM[SS]]]] format
–year File year if no YYYY in file
–nosort Do not sort @ARGV files by mtime
–debug Verbose output useful for debugging
–man Display the entire man page. Contains useful examples.

 

Man logt sich also via SSH auf dem Mailserver ein und wechselt zum User ‚zimbra‘. Anschließend gibt man den Befehl ein.

Achtung: Wenn der Befehl nicht gefunden wird, dann liegt es daran, dass ‚zmmsgtrace‘ nicht in ‚/opt/zimbra/bin‘ liegt, sondern in ‚/opt/zimbra/libexec‘. Man kann dann den kompletten Pfad angeben.

Einige Beispiele:

/opt/zimbra/libexec/zmmsgtrace -s hermann

Zeigt die Meldungen aller Mails an, in denen in der Absende-Adresse ‚hermann‘ steht.

/opt/zimbra/libexec/zmmsgtrace /var/log/zimbra.log.1.gz /var/log/zimbra.log -s 'heinz\.test' -t 20170717,20170721

Durchsucht die Log-Dateien ‚/var/log/zimbra.log.1.gz‘ und ‚/var/log/zimbra.log‘ nach Mails des Absenders ‚heinz.test‘ im Zeitraum 17.07.2017 – 21.07.2017.

Quelle: https://wiki.zimbra.com/wiki/CLI_zmmsgtrace

Share

  • -

Nach Update verliert Alienvault seinen Netzwerkzugriff

Kategorie : News

Nach einem Update kann es vorkommen, dass Alienvault keinen Netzwerkzugriff hat. Der Grund dafür ist, dass Alienvault den entsprechenden Netzwerktreiber verliert.

Um dies zu verhindern, speichert man den entsprechenden Treiber (z.B. firmware-bnx2_0.43_all.deb) direkt auf dem Server. Wir haben dazu direkt im Home-Verzeichnis des Benutzers ‚root‘ ein zusätzlicher Verzeichnis namens ‚network-driver‘ angelegt und den Treiber dort gespeichert.

Nach dem Update und dem anschließenden Neustart muss man sich nun direkt am Server als ‚root‘ einloggen. Um auf das Terminal zu kommen, muss die Option ‚Jailbreak System‘ ausgewählt werden.

Nun führt man folgende Befehle aus:

service networking stop
dpkg -i Pfad_zum_Netzwerktreiber/firmware-bnx2_0.43_all.deb

Anschließend startet man das System neu.

Share

  • -

Whitelist / Blacklist Zimbra

Kategorie : News

Möchte man bestimmte Domains oder E-Mail-Adressen via Blacklist blocken oder via Whitelist erlauben, muss man die Konfiguration des ClamAV entsprechend ändern.

Dazu öffnet man die Datei /opt/zimbra/conf/amavisd.conf.in (als User ‚zimbra‘) und sucht nach folgendem Abschnitt:

  { # a hash-type lookup table (associative array)
    'nobody@cert.org'                        => -3.0,
    'cert-advisory@us-cert.gov'              => -3.0,
    'owner-alert@iss.net'                    => -3.0,
    'slashdot@slashdot.org'                  => -3.0,
    'bugtraq@securityfocus.com'              => -3.0,
    'ntbugtraq@listserv.ntbugtraq.com'       => -3.0,
    'security-alerts@linuxsecurity.com'      => -3.0,
...

 

Am Anfang dieser Liste kann man nun die Einträge eintragen, die erlaubt werden sollen (Whitelist). Dazu vergibt man diesem Eintrag ein hohen negativen Wert (maximal -10.0). Dabei ist zu beachten, dass am Ende jeder Zeile ein Komma stehen muss.

  { # a hash-type lookup table (associative array)
    'zimbra.com'                             => -10.0,
    'nobody@cert.org'                        => -3.0,
    'cert-advisory@us-cert.gov'              => -3.0,
    'owner-alert@iss.net'                    => -3.0,
    'slashdot@slashdot.org'                  => -3.0,
    'bugtraq@securityfocus.com'              => -3.0,
    'ntbugtraq@listserv.ntbugtraq.com'       => -3.0,
    'security-alerts@linuxsecurity.com'      => -3.0,
    'mailman-announce-admin@python.org'      => -3.0,
...

Einträge, die geblockt werden sollen (Blacklist) erhalten dem entsprechend einen hohen positiven Wert (maximal +10.0)

  { # a hash-type lookup table (associative array)
    'spammer.org'                            => +10.0,
    'zimbra.com'                             => -10.0,
    'nobody@cert.org'                        => -3.0,
    'cert-advisory@us-cert.gov'              => -3.0,
    'owner-alert@iss.net'                    => -3.0,
    'slashdot@slashdot.org'                  => -3.0,
    'bugtraq@securityfocus.com'              => -3.0,
    'ntbugtraq@listserv.ntbugtraq.com'       => -3.0,
    'security-alerts@linuxsecurity.com'      => -3.0,
    'mailman-announce-admin@python.org'      => -3.0,
...

Anschließend muss der Dienst neu gestartet werden

zmamavisdctl stop && zmamavisdctl start

Wichtig:

Nach einem Update von Zimbra gehen diese Einstellungen verloren.

Man sollte also immer eine Kopie der Datei amavisd.conf.in an einer anderen Stelle gesichert haben, um nach einem Update die entsprechende Datei zu überschreiben.

Share

  • -

Zentralisierte Sicherung der Konfiguration von HP ProCurve Switchen

Kategorie : News

Es ist ein bisschen umständlich, wenn man mehrere HP ProCurve Switche im Netzwerk hat und deren Konfiguration regelmäßig sichern möchte.

Deswegen habe ich mir eine zentralisierte Sicherung eingerichtet:

Dazu benötigt man einen Linux-Server (in meinem Fall CentOS 6) mit dem TFTP-Server-Dienst und der Scriptsprache expect.

Die Skriptsprache expect dient zur Automatisierung von interaktiven Aufgaben unter Unix. Es handelt sich um eine Erweiterung der Skriptsprache TCL für interaktive Anwendungen wie telnet, ftp, passwd, fsck, rlogin, ssh und andere.

Zuerst installiert man den TFTP-Server:

yum install syslinux tftp-server -y

Der TFTP-Servers wird mit Hilfe des xinetd-Daemon gestartet. Hierzu passt man die Konfigurationsdatei des Daemon (/etc/xinetd.d/tftp) wie folgt an:

# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -c -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

Der Ordner, auf den nun der TFTP-Server verwiest (Upload- und Download-Ordner ist hier in der Zeile server_args angegeben (/var/lib/tftpboot).

Anschließend passt man noch iptables an.

Ob nun xinetd und damit tftpd immer aktiv bleiben soll oder nicht, bleibt jedem selber überlassen.

Weiterführende Information zur Konfiguration siehe https://dokuwiki.nausch.org/doku.php/centos:pxe:tftp

Nun installiert man noch expect:

yum install expect -y

Weiterführende Informationen zu expect siehe http://mikiwiki.org/wiki/expect

Damit die Konfig-Dateien der Switche auch noch zentral gelagert werden, wo auch andere Konfig-Dateien sich befinden, habe ich noch einen Ordner /BackupConfigs angelegt. Im Folgenden wird via Samba eine Windows-Freigabe in diesen Ordner gemounted. In dieser Samba-Freigabe habe ich noch eine leere Datei chkfile angelegt.

Nun kommen wir zum eigentlichen Backup-Prozess. Dazu habe ich zwei Scripte backup.sh, switch-backup2.sh) und eine Datei, welche die Netzwerk-Adressen, Username und Passwort enthält, switch.list), geschrieben. Diese drei Dateien liegen alle in einem Verzeichnis.

Alle Parameter, die anzupassen sind, sind im Folgenden rot und fett markiert.

backup.sh:

Dieses Script macht folgendes:

  • Es liest die Datei switch.list zeilenweise aus,
  • übergibt die entsprechenden Parameter an das Script switch-backup2,
  • mountet eine Samba-Freigabe in den Ordner /BackupConfigs (wurde vorher angelegt), auf der die Konfig-Dateien kopiert werden,
  • schaut nach, ob die Samba-Freigabe gemountet ist, indem geprüft wird, ob die Datei chkfile existiert,
  • kopiert die Konfig-Dateien vom TFTP-Ordner (hier /var/lib/tftpboot) in die Samba-Freigabe,
  • löscht Konfig-Dateien, die älter sind als 60 Tage,
  • unmounted die Samba-Freigabe wieder und
  • versendet eine Mail.

 

#!/bin/bash

#Read Date
d=`date +%d-%m-%Y`

date +"Startzeit: %d.%m.%Y %H:%M"  > mail.txt
echo " " >> mail.txt
echo " " >> mail.txt
echo "Zugriff auf folgende Switche:" >> mail.txt

#Read each line in switch.list

while read line
do
      case "$line" in
            "#"*) ;;
            *) zeile=$line;;
      esac

      #Split each line into IP, Name, User, Password
      IFS=","
      set - $zeile
      if [ -n "$zeile" ]; then
            #Open switch-backup2.sh with Parameters 
            #File to establish connection to each Switch and transfer Running Config 
            #to tftproot folder on local host
            date +"$2: %d.%m.%Y %H:%M"  >> mail.txt
            ./switch-backup2.sh $1 $2 $3 $4 $d
            sleep 1
      fi
done < ./switch.list

echo " " >> mail.txt
echo " " >> mail.txt
echo "Folgende Dateien wurden erstellt:" >> mail.txt
echo " " >> mail.txt

#List files in tftproot folder on local host and write it to mail.txt file
ls -ltr /var/lib/tftpboot/ >> mail.txt
echo " " >> mail.txt

#Mount Backup Folder on Samba-Share
mount -t cifs -o username=Sambauser,password=Sambapassword "//Path-To-Samba-Share" /BackupConfigs

#Check, if the mount point exists
file="/BackupConfigs/chkfile"

if [ -f "$file" ]
then
      #Delete all Configs older than 60 days (2 months)
      echo "Folgende Dateien älter als 2 Monate wurden gelöscht:" >> mail.txt
      find /BackupConfigs/*.cfg -mtime +60 -print -exec rm {} \; >> mail.txt
      #Move Configs
      mv /var/lib/tftpboot/*.cfg /BackupConfigs
      sleep 5
      umount /BackupConfigs
else
     figlet "ERROR" >> mail.txt
     echo "***** MOUNT-PUNKT NICHT ERREICHBAR - DATEIEN NICHT VERSCHOBEN ****" >> mail.txt
fi
date +"Endzeit: %d.%m.%Y %H:%M"  >> mail.txt

#Send Email
mail -s "Mail-Subject" "mailadress@mailserver.com" < mail.txt

switch-backup2.sh:

#!/usr/bin/expect

#Set Variables
set var_IP [lindex $argv 0]
set var_Name [lindex $argv 1]
set var_User [lindex $argv 2]
set var_Pass [lindex $argv 3]
set var_Datum [lindex $argv 4]

#Wait 5 seconds after every command
set timeout 5

#Open SSH connection for User to IP of the Switch
spawn /usr/bin/ssh $var_User@$var_IP

#Wait for message (yes/no) and sends ‚yes‘
expect "(yes/no)? " {
   send "yes\r"
}

#Wait for request of ‘password’ and send the password
expect "password:"
send "$var_Pass\r"

expect "Press any key"
send " "

expect "$"
send "config\r"

send "copy running-config tftp IPAdress-of-Linux-System $var_Datum-$var_Name.cfg\r"
expect "$"

send "exit\rexit\rexit\r"

expect "(y/n)"
send "y\n"

switch.list:

#IP-Adress,Name-Of-The-Switch,User,Password
IP-Adress-HP-Switch1,HP-Switch1,User,Password
IP-Adress-HP-Switch2,HP-Switch2,User,Password

Die Mail, die man erhält, sieht wie folgt aus:

Startzeit: 24.03.2017 14:31
  
 Zugriff auf folgende Switche:
 HP-Switch1: 24.03.2017 14:31
 HP-Switch2: 24.03.2017 14:31
 
  
 Folgende Dateien wurden erstellt:
  
 insgesamt 36
 -rw-rw-rw- 1 nobody nobody 14854 24. Mär 14:31 24-03-2017-HP-Switch1.cfg
 -rw-rw-rw- 1 nobody nobody  2216 24. Mär 14:31 24-03-2017-HP-Switch2.cfg

  
 Folgende Dateien älter als 2 Monate wurden gelöscht:
 /BackupConfigs/16-01-2017-HP-Switch1.cfg
 /BackupConfigs/16-01-2017-HP-Switch2.cfg
 
 Endzeit: 24.03.2017 14:33

Für eine zeitgesteuerten Ablauf muss man jetzt nur noch die crontab anpassen:

0 23 12 * * /Path-To-Script/backup.sh >> /Path-To-Logfiles/log.txt 2>&1

Dieses Script wird nun jeden 12. im Monat um 23:00 ausgeführt und schreibt zusätzlich die Ausgabe in ein Log-Datei namens log.txt

Share

  • -

Speedport-Hybrid mit OpenVPN

Kategorie : News

Viele Leute haben Geschwindigkeitsprobleme bei der Dateiübertragung zwischen zwei Sites über eine OpenVPN Verbindung, wenn die Speedport-Hybrid-Technologie der Deutschen Telekom an einem der Standorte verwendet wird.

Wenn der Verbindungsaufbau klappt und alles richtig eingestellt scheint, stellt man fest, dass beim Umschalten auf LTE bei hoher Last die Bandbreite für die Übertragung abfällt oder der Upload ggf. sogar ganz abbricht.

Aus eigener Erfahrung stellte ich irgendwann fest, dass die Einstellungen richtig sind. Das Problem schien jedoch die MTU (Maximum Transmission Unit, maximale Größe eines unfragmentierten Datenpakets in einem Computernetzwerk) zu sein.

Durch Zufall habe ich bei Google einen interessanten Eintrag gefunden, wo jemand das Problem hatte, dass er beim Öffnen einer Internetseite immer einen Fehler bekommen hat und den MTU-Wert mal auf 1280 stellen sollte. Danach war das Upload-Problem behoben.

Der zu niedrige MTU-Wert der DSL-Leitung ist also die Ursache für die Geschwindigkeitsprobleme.

In einem LAN wird in der Regel über Ethernet-Frames kommuniziert. Ein Ethernet-Frame hat eine maximale Größe von 1518 Byte (wenn alle Geräte des Layer2 Jumbo-Frames unterstützen, kann ein Ethernet-Frame eine Größe von 9038 Byte annehmen). Davon beansprucht der Header 14 Byte und die Prüfsumme (Frame Check Sequence, FCS) weitere 4 Byte. Somit verbleiben genau 1500 Byte für Nutzdaten. Die MTU für Ethernet beträgt also 1500 Byte. Bei DSL (PPPoE, Point-to-Point Protocol Over Ethernet) liegt der Wert bei < 1492.

Das führt dazu, dass die Pakete ausgepackt und in kleinere Pakete neu verpackt werden müssen.

Ist im Paket nun ein „don’t fragment (DF) bit“ gesetzt worden (z.B. von der Software), darf das Paket nicht fragmentiert werden. Dies kann dazu führen, dass eine Kommunikation nur langsam oder gar nicht zu Stande kommt.

Das gilt auch für VPN-Verbindungen und führte in diesem speziellen Fall zum Abbruch der Kommunikation.

Das LTE-Netz lässt nur einen MTU-Wert von um die 1300 zu, was dann beim Umschwenken der Kommunikation wegen erhöhtem Bandbreitenbedarf auf die LTE Leitung problematisch werden kann.

Nach einigen Versuchen mit dem Ping-Befehl und der Angabe verschiedener MTU-Paketgrößen bin ich irgendwann auf den Wert 1280 gekommen, der bei mir als letzter erfolgreicher Ping durchgegangen ist:

ping -l 1280 -f phi.de (1280 ist die MTU)

Damit ist für meine Internet-Leitung der optimale MTU-Wert 1280 Byte, wenn ich Problemen durch Fragmentierung beim automatischen Schwenk auf die LTE-Leitung vorbeugen will.

Das ist in meinem Fall der maximale Wert, bei dem noch ein Ping erfolgreich ist. Bei einer MTU-Größe von 1281 wird der Ping dann als nicht erfolgreich beendet.

Mit dem Wert wird die VPN-Verbindung jetzt sauber aufgebaut, und der Upload- und Downloadwert kommt zu 80% an die richtige DSL-Geschwindigkeit heran.

Share

  • -

Firefox 52 sperrt Plugins aus

Kategorie : News

Mozilla hat mit der Version 52 des Firefox Browsers nun die Ankündigung, Plug-Ins die die NPAPI Schnittstelle Verwenden nicht mehr zu unterstützen, wahrgemacht.

Dies betrifft auch die allseits beliebten Plug-Ins für Java und Flash was aktuell vermehrt zu Problemen führt, da viele Web Applikationen, ob der marktreife diverser Alternativen, immer noch auf diese veralteten Plug-Ins aufbauen.

Es gibt allerdings momentan noch einen Workaround die deaktivierten Plug-Ins wieder zu aktivieren, diese Möglichkeit soll aber mit dem nächsten Release auch abgeschaltet werden, den Herstellern der betroffenen Anwendungen bleibt aktuell also nur die veralteten Techniken endlich ein zu Motten und auf aktuelle Standards zu setzen.

Das ist allerdings immer leichter gesagt als getan, Beispielsweise habe ich mehrere Fibre Channel Switche in Betrieb deren Management ausschließlich über eine Java Anwendung erfolgen kann, hier bleibt dann aktuell nur der Internet Explorer oder die Erstellung einer „Management VM“ auf den älteren Versionen der verwendeten Browser abgelegt werden, diese sollte man allerdings dann wirklich nur für den internen Gebrauch verwenden.

Nicht schön aber es muss ja weitergehen.

 

Workaround

Im Firefox gibt man in der URL Zeile dazu die Adresse about:config ein.

Firefox warnt dann, dass die Gewährleistung bei möglichen Schäden hier endet.

Dort klicken wir auf „Ich bin mir der Gefahr bewusst!“

Mit einem Rechtsklick neben die Werte und einem Linksklick auf „Neu -> Boolean“ legen wir einen neuen Boolean Wert an, dieser kann nur die Werte „True“ und „False“ annehmen.

Der Name des boolean-Wertes lautet dann plugin.load_flash_only

Nach einem klick auf OK geben wir hier noch den Wert „false“ an und klicken erneut auf OK.

Nach einem Neustart des Browsers sollten alle vorher aktivierten Plugins wieder unter Add-ons > Erweiterungen angezeigt werden.

 

 

Share

  • -

Datenschutz Zertifizierung bei der phi

Seit April 2016 ist die phi Medien Systeme GmbH sicherheitszertifiziert nach der ISO/IEC-Norm 27001. Das bedeutet für Sie die Garantie höchster Sicherheitsstandards hinsichtlich der Vertraulichkeit, Integrität und Verfügbarkeit Ihrer Daten und Systeme – regelmäßig überprüft von den Sicherheitsexperten des TÜV Rheinland. Damit ist die Sicherheit der Daten und Systeme unserer Kunden integraler Bestandteil all unserer Geschäftsprozesse.

Prüfkriterien und Sicherheitsziele der TÜV Zertifizierung.

TÜV Zertifizierung 27001

Bei der ISO-27001-Zertifizierung durch den TÜV Rheinland wurden unter anderem folgende Bereiche der phi Medien Systeme GmbH untersucht und bewertet:

  • Sicherheitsrichtlinien
  • Organisation der Informationssicherheit
  • Personalsicherheit
  • Physische und umgebungsbezogene Sicherheit
  • Management der Kommunikation und des Betriebes
  • Zugangs- und Zugriffskontrolle
  • Management von Sicherheitsvorfällen
  • Erfüllung rechtlicher und organisatorischer Anforderungen
  • Business Continuity Management

Um diese Sicherheitsziele zu erreichen, hat die phi Medien Systeme GmbH ein Informations-Sicherheits-Management-System (ISMS) nach den Anforderungen der ISO/IEC 27001:2013 etabliert, welches die Grundlage für die Gewährleistung höchstmöglicher Sicherheit der Infrastrukturen für die Kunden der phi Medien Systeme GmbH darstellt, zusammen mit allen zugehörigen Informationen hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit. Die Normenkonformität und Funktionsfähigkeit des Sicherheitsmanagementsystems der phi Medien Systeme GmbH wurde vom unabhängigen Audit-Team überprüft und wird durch die Zertifizierung nach ISO 27001 bescheinigt.

Um unseren Kunden einen dauerhaften und gleichbleibend hohen Sicherheits-Standard zu garantieren, wird die Wirksamkeit des ISMS durch jährliche Überwachungsaudits sowie Re-Zertifizierung nach jeweils drei Jahren kontinuierlich überwacht und dokumentiert.

Share

Share