Am I running XP?

Eine Webseite von Microsoft gibt Auskunft:

Windows XP End of Service

Puh, Glück gehabt … ;-)

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Cisco IOS: Interface-ACLs für VPNs

Jeder Router, der mit dem Internet verbunden ist, sollte mit einer eingehenden Access-Liste (ACL) auf dem externen Interface konfiguriert sein, der den Zugriff auf den Router einschränkt. In diesem Beitrag zeige ich, wie so eine ACL aussehen kann.

Anmerkung1: Die gezeigte Konfig gilt nur für IOS-Versionen 12.4+. Bei älteren IOS-Releases ist etwas mehr Konfiguration notwendig.
Anmerkung2: Dies gilt nicht für die ASA da dort so eine ACL nicht benötigt wird. Auf der ASA filtert die Interface-ACL standardmäßig nur den durch die ASA durchgehenden Traffic, aber nicht den Traffic, der zur ASA selbst gesendet wird.

Die folgenden Beispiele basieren auf der folgenden Topologie:
VPN-Interface-ACLs

Voraussetzungen:
Der Router sollte mit einer Stateful-Firewall-Konfig versehen sein, die Antwort-Pakete auf selbst generierten Traffic ohne ACEs erlaubt. Das ist Bestandteil der Baseline-Security und vereinfacht die Konfiguration. In diesen Beispiel wird das ältere CBAC verwendet, da es deutlich einfacher zu verstehen und implementieren ist, als die leistungsfähigere Zone-Based-Firewall:

ip inspect name FW ftp
ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
!
interface GigabitEthernet0/0
  ip access-group SITE-A-INTERNET-IN in
  ip inspect FW out
!
ip access-list extended SITE-A-INTERNET-IN
  deny ip any any

Basierend auf dieser Konfiguration wird die ACL mit den benötigten ACEs ergänzt.

Scenario 1: Site-to-Site VPNs mit statischen VPN-Peers
Bei diesem einfachen Beispiel wird angenommen, dass alle Peers eine statische public IP haben, die zwischen den beiden Gateways nicht genatted werden. Der in der ACL benötigte Traffic ist IP-Protocol 50 (ESP) und UDP/500 (ISAKMP). Viele Beispiele im Internet haben auch ACEs für IP/51 (AH), dies wird aber normalerweise nicht für VPNs verwendet.

Als erstes wird eine Object-Group für alle VPN-Peers erstellt (Object-Groups benötigen mindestens IOS 12.4(20)T+):

object-group network IPSEC-PEERS
  host 198.51.100.1
  host 203.0.113.1

Dann wird in der ACL der ESP- und ISAKMP-Traffic von den VPN-Peers zum Router-Interface erlaubt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die letzte Zeile ist für die VPN-Funktionalität natürlich nicht nötig, erleichtert aber das Troubleshooting.

Scenario 2: VPN-Peers hinter einem NAT-device mit statischen IPs
Wenn ein oder beide IPsec-Peers sich hinter einem NAT-Device befinden, dann verwendet IPsec NAT-Traversal, das auch mit UDP/500 anfängt, aber dann auf UDP/4500 wechselt.

Dafür werden die folgenden Einträge benötigt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp non500-isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die Einträge in der Object-Group sind weiterhin die public IPs der Router, nicht die realen IP-Adressen der Router.
Wenn alle Router hinter einem NAT-Device sind, dann wird der ACL-Eintrag für ESP (IP/50) nicht benötigt, da dann der gesamte User-Traffic über UDP/4500 gesendet wird.

Scenario 3: IPsec-Peers mit dynamischer IP-Adresse
Dies ist das typische Remote-Access-Scenario, oder aber auch verwendet, wenn z.B. Branchoffices mit günstigen Kabel- oder DSL-Anschlüssen betrieben werden, für die keine festen IPs verfügbar sind. Daraus resultiert die folgende ACL:

ip access-list extended SITE-A-INTERNET-IN
  permit esp any host 192.0.2.1
  permit udp any host 192.0.2.1 eq isakmp non500-isakmp
  ! generally allow ping from the internet if your security-policy allows that:
  permit icmp any host 192.0.2.1 echo

In diesem Scenario wird die Object-Group mit den IPsec-Peers nicht benötigt, da deren IP im Vorwege sowieso nicht bekannt sind.

Viel Spaß beim Absichern der VPNs!

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

High-Tech-Unternehmen DHL

Eigentlich hätte heute eine wichtige Sendung mit DHL kommen sollen. Ein Blick in die Sendungsverfolgung zeigte dann aber “Rücksendung eingeleitet – Der Empfänger ist unbekannt verzogen”.

Erstaunlich aber, was mir beim DHL-Kundendienst gesagt wurde:

  • Wenn die Rücksendung einmal eingeleitet wurde, dann kann sie nicht gestoppt werden.
  • Selbst wenn ich zum Paket-Verteilzentrum fahren würde um den Paketwagen dort abzufangen, bekomme ich meine Sendung nicht.
  • Und sie habe auch keine Adressen von den Verteilzentren.

Der Grund für die Rücksendung war wohl ein fehlendes “b” hinter der Hausnummer. Und das obwohl meine Büronachbarn genau gegenüber heute von DHL beliefert wurden.

Und ich dachte bisher, nur mit Hermes ist eine Paketzustellung reine Glücksache …

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Geld für GnuPG

logo-draft-1Zur Zeit bin ich dabei einen weiteren Teil meiner “alles verschlüsseln”-Strategie umzusetzen. Das wird demnächst auch noch ein eigener Beitrag werden.
Dazu passend berichtet heute heise.de, dass GnuPG per Crowdfunding Geld einsammeln möchte. Als jemand, der unter anderem auch OpenPGP einsetzt, ist das natürlich eine Sache die ich auch unterstützte. Das Ziel ist zwar schon fast erreicht, aber noch kann man natürlich mitmachen!

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Wir backen uns ein Netzwerk

Netzwerkbaeckerei

Passend zur Adventszeit backen wir uns ein Netzwerk anstelle es wie sonst immer aus realen Komponenten zusammenzubauen. Zusätzlich gibt es ein Gewinnspiel für Netzwerker:

Die Netzwerftbäckerei zur Weihnachtszeit

Viel Spaß dabei und schöne Advents- und Weihnachtszeit!

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Cisco ASA VPNs: Spoke-to-Spoke Traffic via Hub

In dem Cisco Support-Forum kommt regelmäßig die Frage, wie man per VPN Spoke-zu-Spoke Kommunikation über den Hub leiten kann.
Diese Konfiguration wird hier gezeigt. Vorweg aber der Hinweis, dass bei Vorhaben wie diesen, IOS-Router oftmals die bessere Wahl sind, da sie dabei um ein vielfaches flexibler sind als die ASA.

Die Konfiguration wird anhand des folgenden Aufbaus für die ASA-Version 8.4+ gezeigt. Es beginnt mit der Hub-to-Spoke-Konfiguration, die dann später mit einer Spoke-to-Spoke-Kommunikation erweitert wird:

ASA-Hub-and-Spoke

Auf allen ASAs werden Phase1- und Phase2-Policies für IPSec benötigt. Diese sind natürlich nach dem eigenen Bedürfnis zu wählen:

crypto ikev1 policy 1
 authentication pre-share
 encryption aes 256
 hash sha
 group 5
 lifetime 86400
!
crypto ikev1 enable outside
!
crypto ipsec ikev1 transform-set ESP-AES256-SHA esp-aes-256 esp-sha-hmac

Auf allen ASAs werden die benötigten Object-Groups, ACLs, Crypto-Maps und Tunnel-Groups angelegt. Zusätzlich wird der Traffic vom NAT ausgenommen:

Spoke1:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE1-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE1-NETWORKS SPOKE1-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Spoke2:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE2-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE2-NETWORKS SPOKE2-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Hub:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
 group-object SPOKE2-NETWORKS
!
access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group HQ-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group HQ-NETWORKS object-group SPOKE2-NETWORKS
!
crypto map VPN 1 match address VPN-HQ-TO-SPOKE1
crypto map VPN 1 set peer 203.0.113.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN 2 match address VPN-HQ-TO-SPOKE2
crypto map VPN 2 set peer 198.51.100.1
crypto map VPN 2 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
tunnel-group 198.51.100.1 type ipsec-l2l
tunnel-group 198.51.100.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough

nat (any,outside) source static HQ-NETWORKS HQ-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Mit der gegebenen Konfiguration kann zwischen Spoke1 und dem Hub, als auch zwischen Spoke2 und dem Hub per VPN kommuniziert werden.

Jetzt wird die VPN-Konfig um Spoke-to-Spoke-Kommunikation erweitert. Dabei soll jeder Spoke den Traffic für die anderen Spokes durch den schon bestehenden Tunnel zum Hub senden. Der Hub sendet den Traffic dann zum jeweiligen Spoke weiter.

Spoke1:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE2-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Spoke2:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS

Die Crypto-ACLs haben jetzt permit-statements für die Kommunikation zum Hub, als auch zum anderen Spoke. Weiterhin wird auch der Spoke-to-Spoke-Traffic nicht genatted da die Spoke-Ziele der NAT-Exemption-Object-Group hinzugefügt wurden. Die Crypto-ACLs könnte man durch eine weitere Object-Group für die VPN-Ziele natürlich noch eleganter konfigurieren.

Hub:
Auf der Hub-ASA müssen zwei Änderungen vorgenommen werden.
Als erstes werden die Crypto-ACL so erweitert, dass die Crypto-ACL zum Spoke 1 auch den Traffic von Spoke2 beinhaltet und die Crypto-ACL zum Spoke2 auch den Traffic vom Spoke1 beinhaltet.

access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Als letzten Schritt wird die ASA so konfiguriert, dass Hairpinning erlaubt wird, also Traffic auf dem selben Interface die ASA verlassen kann, über das der Traffic empfangen wurde.

same-security-traffic permit intra-interface
Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Apple und die Security

Apple LogoFrüher war die Security von Apple Computern so einfach. Vor der Auslieferung hat Steve Jobs einfach eine Hand voll Feenstaub auf die Macs gestreut und sie wurden quasi unverwundbar. Leider geht das heute nicht mehr. Apple muss für die Sicherheit seiner Systeme mit “normalen” Sicherheitsmechanismen sorgen. Um so ärgerlicher, wenn Security Bugs auch nach mehreren Updates immer noch in der Software enthalten sind:

Im Juni/Juli (ok, es war schon 2013) hatte ich einen regen E-Mail-Verkehr mit dem Apple Product Security Team über ein Problem mit verschlüsselten Volumes das sich folgendermaßen zeigt:

  1. Auf einer externen Festplatte (in meinem Fall war es eine USB-Platte) wird eine verschlüsselte Partition angelegt (das macht man im Festplattendienstprogramm).
  2. Wenn man diese externe Platte anschließt, wird man nach dem Password gefragt und der vormals verschlüsselte Inhalt ist zugänglich.
  3. Wenn man nicht mehr mit dem Inhalt der Platte arbeiten muss, kann man diese über das Kontextmenü der Partition auswerfen.
  4. Jetzt sollte man annehmen, dass der Inhalt nicht mehr erreichbar ist und das Betriebssystem auch den Schlüssel nicht mehr im Speicher behält. Aber:
  5. Man loggt sich aus und wieder ein (gerne auch mit einem anderen Benutzerkonto).
  6. Die verschlüsselte Partition ist sofort wieder gemountet, ohne dass man erneut ein Password eingeben muss (und das Kennwort war natürlich nicht im Schlüsselbund gesichert).

Leider ist dieser Fehler immer noch enthalten. Sowohl im danach erschienenen Update 10.8.5, als auch in der neuen Version 10.9 “Mavericks”.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Hacker Halted 2013

hacker-haltedDieses Jahr war ich wieder auf der Hacker-Halted Konferenz, die im September in Atlanta stattfand. Vor drei Jahren war ich zumindest von dem EC-Council-Training alles andere als begeistert, aber eine zweite Chance wollte ich der Veranstaltung dennoch geben. Das galt insbesondere für das Angebot, den Hotelaufenthalt zum Training und der Konferenz kostenlos zu bekommen. Mein erster Gedanke war zwar “na, kriegen die ihre Veranstaltung nicht voll”, aber die Gelegenheit habe ich doch genutzt.
Als Training habe ich mir den 3-Tages-Kurs “CAST-615: Cryptography Deep Dive” bzw. “Hacking Encryption and Countermesures” ausgesucht, da mich das Thema sehr interessiert. Die Einleitung zum Kurs klang auf jeden Fall gut:

Perhaps you already know SSL/TLS in depth, you can setup a VPN in your sleep, and you have been using TruCrypt for years. Maybe your middle name is AES (John AES Smith), but do you know enough? This course will teach you the major algorithms in depth, allowing you to understand proper implementation and exploitation. For example can you crack hard drive encryption? How likely is it to be able to break a given RSA implementation? This course does not assume you have a strong math background, it will teach you enough number theory to understand cryptography.

Auch wollte ich nach den Erfahrungen von 2010 keinen Kurs besuchen, der zu einer Zertifizierung führt. Aber manchmal kommt es doch anders …

Unter den Voraussetzungen zum Kurs wurde extra erwähnt, dass keine besonderen mathematischen Vorkenntnisse vorhanden sein müssen. Die Mathematik ist der Bereich, bei dem ich selbst in exzellenten Büchern wie z.B. Practical Cryptography aussteige.

Der Kurs bestand aus verschiedenen Blöcken: Mathematische Grundlagen, historische Mechanismen, moderne Kryptographie, Steganographie und Cryptoanalyse.

Gleich zu Anfang des ersten Tages hatte der Trainer Chuck Easttom auch herausgestellt, für wie schlecht er alle bekannten mathematischen Erklärungen hält und dass er eine eigene Methode hat, die notwendige Mathematik verständlich zu erklären. Nun, das war dann auch nur eine zusammenhanglose Aneinanderreihung mathematischer Begriffe; zu einem Verständnis dieser hat das allerdings auch nicht geführt. Das war, nun ja …
Die historischen Verfahren haben in meinen Augen viel zu viel Platz eingenommen, Steganographie halte ich für überbewertet und muss sich in so einem Kurs sicher nicht über einen halben Tag erstrecken. Kryptoanalyse war das, worauf ich am meisten gespannt war. Dort habe ich dann doch erwartet, aktuelles zu lernen, z. B., wie kryptografische Verfahren gebrochen werden. Effektiv war das eine Übersicht von Methoden, wie known-plaintext-attacks, choosen-plaintext-attacks oder die Wichtigkeit, Kryptografie mit Cipher-Block-Chaining anstelle Electronic-Code-Book zu implementieren. Irgendwie habe ich mich um zehn Jahre zurückversetzt gefühlt, als ich den (damals sehr guten) Cisco-Kurs VPBAV (IPSec) gegeben habe. Dort bestand der erste Tag ungefähr aus dem Stoff, den wir in diesen drei Tagen durchgenommen haben (ok, ohne die Mathematik und ohne Erklärung von AES, der Standard war zu der Zeit als der Kurs entwickelt wurde noch nicht vorhanden. Auch Steganographie kam natürlich nicht drin vor). Zusammengestrichen ist der Kurs dann auch das, was ich in meinem IPSec-Workshop am ersten Vormittag mache. Als Anregung nehme ich aber dann doch mit, die Arbeitsweise von AES in meinen Workshop zu integrieren.

Eine schlimme Vorahnung überkam mich, als angekündigt wurde, dass es einen anderen EC-Council-Kurs gäbe, der zur Zertifizierung zum E|CES (EC-Council Certified Encryption Specialist) führt und mit diesem Kurs fast deckungsgleich sei. Und da sowohl unser, als auch das Zertifizierungstraining und die Prüfung vom selben Trainer entwickelt wurde, war auf einmal auch dieses Training ein reines Zertifizierungs-Training. In diesem ging es dann auch hauptsächlich darum, das zu lernen, was man für die Prüfung benötigt, anstatt tiefergehendes Wissen zu vermitteln. Dieses Training war leider kein Deep-Dive und auch um “Hacking Encryption” oder Countermeasures ging es eher nicht. Es war das, was ich als minimale Grundlagen der Kryptographie für jeden Security-Professional bezeichnen würde. Zudem waren es Grundlagen ohne praktische Anwendung, auf die man dann hätte aufbauen können.

Die Kursunterlagen sollte man natürlich auch nicht vergessen (Kostprobe unter https://www.eccouncil.org/Certification/ec-council-certified-encryption-specialist). Die gedruckten Slides wirkten so, als hätte ein Kind zum ersten Mal die Powerpoint Cliparts entdeckt und diese mussten jetzt unbedingt allesamt in den Slides dargestellt werden. Ein Resultat daraus war, dass die Schrift so klein wurde, dass man sie fast nicht mehr lesen konnte.

ecesIm Nebenraum lief auch wieder eine CEH-Schulung (Certified Ethical Hacker). In den Pausen habe ich häufiger kurz durch die geöffnete Tür geschaut. Was wurde dort meistens gemacht? Lediglich das sture Lernen von Prüfungsfragen. Das bestätigt meine Meinung, die ich schon in meinem ersten Hacker-Halted-Beitrag geschrieben habe, dass der CEH noch weniger wert als wertlos ist … Ach ja, E|CES (EC-Council Certified Encryption Specialist) bin ich jetzt auch. Und auch diese Zertifizierung ist mehr als wertlos. Als Kursteilnehmer bei EC-Council kann man quasi nicht durchfallen und vom Anspruch ist sie auch eher rudimentär.
Apropos Prüfung … Die Exam-Seite, auf der man sich einloggt, seine Prüfungen verwaltet und auch die Prüfung ablegt, arbeitet mit HTTP anstelle HTTPS (bzw. es gibt ein Zertifikat, aber das ist für einen anderen FQDN). Und nach der Registrierung bekommt man seinen Usernamen und das Password im Klartext zugesendet. Zumindest wenn die E-Mail ankommt, das ist sie bei mir nämlich nicht direkt:

MTA helo: zeus.atlas.eccouncil.org, MTA hostname: 67.221.176.34.static.nyinternet.net[67.221.176.34]

Die darauf folgenden knapp drei Konferenztage waren dann aber doch sehr gut. Es gab etliche sehr gute Vorträge, die neue Informationen lieferten oder aber zum Nachdenken anregten. U.a. berichtete Charlie Miller über den Stand der Mobile Security. Es ging weiterhin um Unicode und Security, bei dem ich mich häufiger gefragt habe, ob der Normalizer in den Cisco IPS-Appliances das auch erkennen kann oder um den Security-Zustand der Industrial Control Systems (ICS). Bei letzterem wird einem dann doch sehr mulmig. Die Security in diesen Systemen ist irgendwie vergleichbar mit dem frühen Internet. Es gibt einfach keine Security …

DragonDaySlider2Am Abend des ersten Tages gab es dann die Preview von Dragon Day, einem Independent Hacker Film, bei dem die USA durch einen Cyber-Angriff in die elektronische Steinzeit zurückgeworfen werden. Das war zwar kein großes Kino, aber trotzdem gut gemacht und gelungene Unterhaltung. Und Popcorn gab es auch!

Am zweiten Tag waren diverse kurze Sessions à 40 Minuten vorgesehen. Z.B. Angriffe auf SSL-Implementierungen. Sowas hätte ich mir auch in dem “Encryption Deep-Dive” gewünscht. Auch die weiteren Sessions waren fast alle sehr interessant. Am dritten Tag gab es dann nur vier Sessions am Vormittag. Bis auf eine waren auch die gut. Aber die letzte hatte es wirklich in sich. Durch komplette Ignoranz wie IT-Systeme und Netzwerke funktionieren, wurde unter abenteuerlichen Annahmen ein theoretischer Angriff präsentiert, der dann hypothetisch mit Mechanismen abgewehrt wurde, die bekanntermaßen nicht wirklich funktionieren (nämlich Security by Obscurity). Oh, war das schlecht …

Und damit ist es mal wieder Zeit für eine Zusammenfassung: Die EC-Council-Zertifizierungs-Trainings sind in meinen Augen die wohl schlechtesten Trainings am Markt (und ich besuche viele Trainings). Wenn man in einem Kurs-Thema schon Grundlagen hat, dann sollte man das entsprechende ec-council-Training eher nicht besuchen, es sei denn, man ist nur an der Zertifizierung interessiert. Etwas neues lernen wird man vermutlich nicht. Wenn man ein Thema noch nicht kennt, kann es durchaus lohnen, dümmer wird man sicher auch nicht. Und da der Konferenz-Teil durchweg gut war, kann ich mir bei einem ähnlich guten Angebot durchaus vorstellen, im nächsten Jahr wieder bei der Hacker-Halted dabei zu sein und dann z.B. das “Digital Forensic” Training zu besuchen. Oder noch besser das Training zum Thema “Securing Windows”. Dazu gibt es keine Prüfung und Teilnehmer dieses Trainings haben mir gesagt, dass es richtig gut gewesen sein soll.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Cisco AnyConnect als Client-WAN-Beschleuniger

In der EOS/EOL-Ankündigung des “Cisco Wide Area Application Services (WAAS) Mobile Products” ist eine interessante Info enthalten. Der AnyConnect Client bekommt eine weitere Rolle zugewiesen:

Early field trials (EFTs) of the new AnyConnect platform with integrated WAN optimization are scheduled for Q4CY13

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

O2 und IPv6

Von Zeit zu Zeit frage ich ja Anbieter wie es denn inzwischen mit IPv6 aussieht. Jetzt war mal wieder der Anbieter meines Business-DSL-Anschlusses dran. Die Antwort des O2-Geschäftskundensupports wann dort IPv6 zur Verfügung stehen wird war, nun, sagen wir mal “interessant”:

Aktuell kann ich Ihnen keinen Zeitpunkt nennen, an dem Ihnen IPv6 Adressen zur Verfügung gestellt werden können. Da unserer Netz eine ausnahmslose Übersetzung beherrscht ist dieses auch vorerst nicht nötig.

Na, dann ist das Problem ja gelöst, “ausnahmslose Übersetzung” sei Dank!

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Nächste Seite »