Sales vs IT …

The Great Office War


Absolut sehenswert!

Advertisements
Sales vs IT …

Standard-ACLs

Wie oft wird dieser Mist eigentlich noch verbreitet?

Question: Where should you place standard ACLs in the Network?
Answer: Standard ACLs should be placed as close as possible to the destination to prevent unintended traffic from filtering to your other networks.

Standard-ACLs werden nicht zum Filtern von Traffic verwendet! Dazu sind die extended Access-Listen da. Standard-ACLs haben ihre Daseinsberechtigung z.B. im Filtern von Routing-Updates, für Access-Classes, etc. Aber leider ist die Original-Aussage in diversen Cisco-Trainings zu finden und wird auch genauso oft nachgeplappert (leider auch von Leuten, die es besser wissen sollten).

Standard-ACLs

IPX hat gewonnen!

Naja, zumindest in der Art und Weise Netzwerk-IDs zu konfigurieren finden wir die alte HEX-Notation bei IPv6 ja auch wieder. Es ist also an der Zeit, sich an die ganzen “sprechenden” Netzwerk-IDs aus den Buchstaben A, B, C, D, E, F und der Zahl 0 (wie “o”) zu erinnern, die man früher gerne verwendet hat.

Da wären z.B.:

ADAC, AFFE, BABE, BEBE, BEEF, B00B, CAFE, C0DE, DEAD, D00F, EFFE, FACE, FEED, FEFE, F00D

Mehr fällt mir beim besten Willen nicht mehr ein … Wer kennt noch weitere sprechende Namen?

P.S. Nein, ein “Best Practice” soll das hier nicht werden. Ein sinnvoller Adressplan ist diesen Namen sicher vorzuziehen.

IPX hat gewonnen!

Konfiguration eines DNS-Servers im Cisco IOS

In meinem Heim-Netz stehen im Moment ein paar Änderungen an, um einen PC-Server mit seinen diversen Diensten abzulösen. Der erste Schritt war die Migration des DHCP-Servers auf einen Catalyst 3560. Über den DHCP-Server im IOS bzw. der ASA wurde aber vermutlich schon genug geschrieben.

Der nächste Schritt ist die Migration des Windows 2003 DNS-Servers auf meinen Internet-Router (im Moment ein Cisco 1841 mit IOS AdvSec. 12.4(20)T). Im IOS ist ein fast vollwertiger DNS-Server enthalten, dessen Konfiguration dem eines “richtigen” DNS-Servers sehr ähnlich ist. Alles was man in dem hervorragenden Buch “DNS and BIND” gelernt hat, bleibt auch hier gültig. Einschränkungen sind, daß man im IOS keinen Zonentransfer machen kann, was für ein Heim-Netz aber verschmerzbar ist. Weiterhin funktionieren die Reverse-Lookup-Zonen nicht, das vermisse ich schon mehr.

Eine kleine Basis-Konfiguration (der IOS DNS-Server kann noch deutlich mehr):

Als erstes wird die Zone definiert:

ip dns primary domain-name soa primary-server-name mailbox-name 
     [refresh-interval [retry-interval [expire-ttl [minimum-ttl]]]]

Im einfachsten Fall ist das also ein

gw(config)#ip dns primary example.com soa ns.example.com admin.example.com

Für die fehlenden Angaben werden vom Router automatisch Default-Werte eingetragen:

gw(config)#do sh run | i ip dns
ip dns server
ip dns primary example.com soa ns.example.com admin.example.com 21600 900 7776000 86400

Die Zeile “ip dns server” wurde vom Router auch automatisch konfiguriert.

Als nächster Schritt wird dem Router noch ein eigener Domain-Name mitgegeben und die Ressourcen des Netzes werden definiert:

gw(config)#ip domain-name example.com
gw(config)#ip host gw.example.com 10.255.250.1
gw(config)#ip host server.example.com 10.255.255.10
gw(config)#ip host csamc.exampe.com 10.255.255.14
gw(config)#ip host c3560.exampe.com 10.255.255.1
gw(config)#ip host c2940.exampe.com 10.255.255.5

und so weiter und so fort. Ein Eintrag, der bei dem DNS-Server nicht zwingend ist, aber zu einer “sauberen” Konfiguration dazugehört, ist,

gw(config)#ip host example.com ns ns.example.com
gw(config)#ip host ns.example.com 10.255.250.1

Genau so können bei Bedarf MX- und SRV-Records eingetragen werden.

Wer in seinem Home-Netz redundante Server hat, kann natürlich auch mehrere Adressen für einen FQDN konfigurieren:

gw(config)#ip host www.example.com 10.255.255.11 10.255.255.12

Als letzte Konfiguration muss dafür gesorgt werden, daß der Router auch Anfragen für fremde Domains zu einem Upstream-DNS-Server weiterleiten kann. Ich benutze vor meinem 1841 eine Fritzbox als DSL-Router, daher reicht ein einfacher name-server-Eintrag:

gw(config)#ip name-server 192.168.178.1

Wenn der Router seine IP-Konfiguration per DHCP oder PPP bekommt, kann auch der gelernte DNS-Server verwendet werden:

interface Dialer1
 ip address negotiated
 encapsulation ppp
 ppp ipcp dns request

Überprüfen kann man die Konfiguration mit einem “show hosts”:

gw#sh hosts
Default domain is example.com
Name/address lookup uses domain service
Name servers are 192.168.178.1

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)
example.com               NA    (perm, OK)  0  NS       ns.example.com
SOA      ns.example.com admin.example.com
0 21600 900 7776000 86400
gw.example.com            None  (perm, OK)  0   IP    10.255.250.1
server.example.com        None  (perm, OK)  0   IP    10.255.255.10
csamc.exampe.com          None  (perm, OK)  0   IP    10.255.255.14
c3560.exampe.com          None  (perm, OK)  0   IP    10.255.255.1
c2940.exampe.com          None  (perm, OK)  0   IP    10.255.255.5
ns.example.com            None  (perm, OK)  0   IP    10.255.250.1
www.example.com           None  (perm, OK)  0   IP    10.255.255.11
10.255.255.12
security-planet.de        None  (temp, OK)  0   IP    88.198.206.211
gw#

Der letzte Eintrag (security-planet.de) ist ein temporärer, den der Router über seinen Upstream-DNS aufgelöst hat.

Und hier komplett die relevante Konfiguration:

hostname gw
!
ip domain name example.com
ip host example.com ns ns.example.com
ip host gw.example.com 10.255.250.1
ip host server.example.com 10.255.255.10
ip host csamc.exampe.com 10.255.255.14
ip host c3560.exampe.com 10.255.255.1
ip host c2940.exampe.com 10.255.255.5
ip host ns.example.com 10.255.250.1
ip host www.example.com 10.255.255.11 10.255.255.12
ip name-server 192.168.178.1
!
ip dns server
ip dns primary example.com soa ns.example.com admin.example.com 21600 900 7776000 86400
Konfiguration eines DNS-Servers im Cisco IOS

CCIE Plaques

Anmerkung: Diesen Beitrag wollte ich eigentlich schon längst abgeschickt haben, wollte aber noch ein paar genauere Daten suchen. Der Beitrag “Thoroughly Disappointed” von Joe Harris erinnerte mich jetzt aber daran, ihn doch schon zu veröffentlichen:

Als 2005er CCIE habe ich ja leider nicht die schöne Holz-CCIE-Tafel mit der Medaille bekommen, wie sie z.B. auf der Webseite von Heinz Ulm zu bewundern ist. Man kann diese alten Tafeln zwar auch als “Jung-CCIE” in den Staaten bestellen, das habe ich bisher aber nicht getan. Meine ist aus Kunststoff, die aber auch ganz schick ist:

Jetzt habe ich aber im März meinen zweiten CCIE (R/S) gemacht und habe erwartet, daß ich das gleiche Modell nochmal bekomme, halt nur mit einem anderen Aufdruck. Aber diese CCIE-Tafel sieht schon wieder anders aus (die Farbe stimmt nicht ganz, sie ist mehr blau – evtl. sollte ich mich doch mehr mit dem Weissabgleich meiner Kamera beschäftigen):

Grund genug sich einmal umzuhören, von wann bis wann, die unterschiedlichen CCIE-Tafeln verwendet wurden:

Original aus Holz:

verwendet bis 13.03.2001, CCIE#7019

schwarz/silber Plastik-Modell:

verwendet ab 17.07.2001 (CCIE#7817)
verwendet bis 26.09.2006 (CCIE#16931)

blaues Plastik-Modell:

verwendet ab 21.5.2007 CCIE#17999

Wenn jemand genauere Daten hat, um das noch besser einzugrenzen, würde ich mich über eine Nachricht freuen.

Weiteres zu den Plaques:

  • Es gibt Gerüchte, dass es von der originalen Version kurzfristig auch eine “günstigere” gab. Dazu fehlen mir aber jegliche Informationen.
  • Am Ende der Phase mit der Original-Plaque wollte Cisco überhaupt keine Plaques mehr versenden, anstelle dessen sollten sie im CCIE-Store erwerbbar sein.
  • Beim Wechsel von der grau/anthrazit-farbenen auf die blaugrüne sind teilweise beide Plaques versendet worden.
CCIE Plaques

Skandal: DNSSEC hilft nicht gegen Hardware-Ausfälle

Es liest sich so, als wenn das manche Leute denken würden:

Gerne verweisen sie darauf, dass DNSSEC kein Allheilmittel für die Absicherung des DNS ist. “Nach allem, was wir wissen, wäre der jüngste Angriff auf Server der IANA und ICANN nicht durch DNSSEC verhindert worden, denn dabei wurden die Domains beim Registrar gekapert”, sagt Dittler. Verhindert werden könne eben nur eine Manipulation auf der Strecke, nicht an der Quelle selbst. Die Umleitung des Datenverkehrs von Youtube kürzlich wäre ebenfalls durch eine DNSSEC-Signatur nicht verhindert worden. “Das war ein reines Routing-Problem.” Auch gegen die Fälschung der BGP-Routen suchen die Experten gerade ein Mittel – dafür braucht es ein weiteres PKI-System, parallel zu DNSSEC.

Skandal: DNSSEC hilft nicht gegen Hardware-Ausfälle

QNAP TurboStation

Um meinen Server im Arbeitszimmer mittelfristig los zu werden, habe ich mir gerade ein NAS gekauft. Der Beschreibung und den diversen Bewertungen im Internet nach, sollte die QNAP TurboStation das perfekte Gerät für mich sein. Um erst einmal mit einem kleinen Gerät testen zu können, habe ich mich für die Version “TS-109 Pro II” entschieden, die Platz für eine interne Festplatte bietet.
Die ersten zwei Ernüchterungen kamen innerhalb der ersten Stunde:

  1. Das Gerät akzeptiert kein Admin-Password mit einem “$”:
  2. Die Entwickler der Weboberfläche wissen nicht, welche IP-Adressen erlaubt sind und welche nicht:

    Mit dem letzten Subnet einer “Klasse” habe ich in den letzten 10 Jahren keine Probleme mehr gehabt. Selbst mit Betriebssystemen, die nicht für eine saubere IP-Unterstützung bekannt waren… Und wenn die IP über das Windows-Konfigurationsprogramm gesetzt wird, dann klappt es auch mit meiner gewünschten IP.

Das fängt ja gut an … Ich berichte weiter, wenn es sich lohnt.

QNAP TurboStation