Press left mouse button to continue.

Kategorie: Adminstories (Seite 2 von 4)

Die Firewall

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Eine Frage, die immer wieder mal gestellt wird und in „Fachzeitschriften“ regelmaessig bejaht wird ist, brauche ich zu Hause eine Firewall? Das kann man meiner Meinung nach ganz klar mit „Ja/Nein/Kann sein“ beantworten.

Vorab macht es, wie bei so vielen Dingen, Sinn sich zu fragen was man erreichen moechte. Moechte ich den Zugriff meines LANs reglementieren, so dass nur noch http(s) erlaubt ist? Oder moechte ich den Schutz meines Clients verbessern? Oder moechte ich einfach nur etwas ueber mein Netzwerk lernen? Dann ist ja auch noch die Frage, was ich unter Firewall verstehe und ob ich eine lokale oder zentrale Softwareloesung haben moechte? Oder soll es doch lieber gleich Hardware sein?

Wobei ich mit Firewall jetzt eine sogenannte Stateful Inspection-Firewall meine. Also eine Firewall, die den Netzwerkverkehr anhand einfacher Regeln (Erlaube Host A den Zugriff auf Netz A, Port 80) reglementiert. Eine detailiertere Erklaerung findet man, wie so oft, im entsprechenden Wiki-Artikel.

Wenn ich den Zugriff meines Netzwerkes auf externe Ressourcen reglementieren moechte, ist der Einsatz von Hardware vermutlich am unkompliziertesten. Es muss nicht auf jedem beteiligten Rechner eine Firewall eingerichtet und konfiguriert werden. Ich habe da, eher aus Spass an der Freude, zu Hause eine Netscreen 5GT im Einsatz. Hiermit kann ich reglementieren und protokollieren, nutze viele der Funktionen aber nicht. In der Regel bringen neuere Router auch schon ein Stueck weit Firewallfunktionalitaet mit. In diesem Szenario haelt sich der Aufwand und vor allem eine moegliche Fehlersuche etwas in Grenzen.

Um den Schutz meines Clients zu verbessern mache ich mir keine Gedanken ueber eine lokale Firewall. Da setze ich lieber an sinnvolleren Stellen an. Der Einsatz einer Personal Firewall war ja eine zeitlang extrem beliebt und wurde und wird in verschiedenen Publikationen auch immer wieder empfohlen. Das Problem ist hier nur, dass fuer einen moeglichen sinnvollen Einsatz auch ein sehr gesundes Wissen ueber Netzwerke und das eigene System mitgebracht werden sollten. Denn Meldungen wie „Der Prozess ’ssh:25738′ versucht von Adresse 192.168.100.110, Port 54721 auf die Adresse 192.168.100.1, Port 22 zuzugreifen“ muessen auch verstanden werden. Und dieses Beispiel war ja nun relativ leicht.

Vor allem am Anfang der Konfiguration solch einer Personal Firewall wird man im Zweifel mit so vielen Meldungen konfrontiert, dass bei vielen Benutzern die Gefahr besteht, im Verlauf einfach nur noch alles zu verbieten oder zu erlauben. Ersteres fuehrt dazu, dass damit bestimmte Dinge vielleicht nicht (mehr) funktionieren. Zweiteres fuehrt dazu, dass ich eventuell einen Regeleintrag habe, der nicht gewuenscht war. Hat man es dann doch geschafft ein, wie man meint, gutes Regelwerk zu erstellen, hat man den Schutz der eigenen Maschine im Zweifel aber nicht derart verbessert, dass sich der Aufwand gelohnt hat. In allen Personal Firewalls, die ich bisher so gesehen habe, gab es einen Weg nach draussen, obwohl dieser eigentlich nicht gestattet sein sollte. Ein Beispiel, welches schon was aelter ist, findet man in meinem Blog.

Interessant ist eine Personal Firewall, wenn ich schauen moechte was mein System eigentlich so macht. Da kommt man mit einer zentralen Firewall oft nicht weit, da hier der Zusammenhang zwischen den Sessions und dem Ausloeser (sprich, der Anwendung) nicht immer klar ist.

Um etwas ueber das eigene Netzwerk zu erfahren ist eine Firewall, egal ob lokal oder zentral, oft nicht der passende Ansatz. Grund ist, dass ich in der Regel nur Informationen ueber erlaubte/verbotene Sitzungen bekomme. Und sowas wie…

firewall-> get session
alloc 2/max 2064, alloc failed 0, mcast alloc 0, di alloc failed 0
total reserved 0, free sessions in shared pool 2062
id 1675/s**,vsys 0,flag 00000040/0080/0021,policy 320002,time 180, dip 0 module 0
if 2(nspflag 800601):192.168.100.15/52285->192.168.100.1/22,6,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1,wsf 0
if 3(nspflag 2002010):192.168.100.15/52285<-192.168.100.1/22,6,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0,wsf 0
id 1769/s**,vsys 0,flag 00000000/0000/0001,policy 1,time 6, dip 2 module 0
if 2(nspflag 800801):192.168.100.15/57327->188.40.57.208/1194,17,000ea62db238,sess token 3,vlan 0,tun 0,vsd 0,route 1
if 1(nspflag 10800800):192.168.0.2/1711<-188.40.57.208/1194,17,00150c73228c,sess token 4,vlan 0,tun 0,vsd 0,route 5
Total 2 sessions shown

…ist mal nett, wenn es ein Problem gibt. Aber so richtig lernen tut man da nichts. Da wuerde ich eher mal den Einsatz von tcpdump oder Wireshark empfehlen. Ich kann dann wirklich etwas vom Netzwerk und darauf befindlichen Protokollen sehen.

So oder so sollte man sich im klaren sein, dass der Einsatz einer Firewall durchaus auch Aufwand und spaetere Pflege noetig macht. Im Normalfall sind Firewallsysteme erst mal keine „Fire-and-Forget“-Systeme. Wer, wie im obigen Beispiel, eine Firewall einrichtet, da http(s) freigibt und meint, das war’s, wird schnell merken, dass Netzwerk/Internet mehr als nur Port 80 und 443 ist.

Fazit:
Mit einer Firewall alleine gewinnt man noch lange keinen Blumentopf. Vor allem in Geschaeftsumfeld sollte es meiner Meinung nach kaum noch ein Unternehmen geben, dass sensible Maschinen, die aus dem Internet erreichbar sein muessen, ausschliesslich durch eine Firewall schuetzt. Fuer jede Anwendung, bzw. Anwendungsgruppe, sollte es Vorgaben geben, wie diese abzusichern sind. Da zaehlt dann aber nicht nur alleine der Einsatz einer Firewall. Da kommen dann, je nach Auspraegung, auch so Dinge wie Patch-Management, Web Application Firewall, IDS, IPS oder auch die Beschreibung des Notfalls (Einbruch) hinzu.

Auch im privaten Umfeld ist die klassische Firewall nur eine moegliche Ergaenzung zu weiteren Punkten um den Schutz der eigenen Infrastruktur zu verbessern. Und eines muss klar sein. Es gibt nicht *die Sicherheit*. Man kann versuchen den Schutz zu verbessern, wird aber im Regelfall keine 100% Sicherheit erreichen.

Ergaenzung:
Wenn zwei Personen sich unterhalten passiert es schnell, dass beide etwas anderes bei der Begrifflichkeit „Firewall“ meinen. Umgangssprachlich ist mit Firewall oft die Komponente gemeint, die den Schutz eines Systems oder einer Umgebung zum Ziel hat. Korrekter ist jedoch, dass Firewall auch mit ein Konzept meint, in dem nicht nur die Frage nach der Hardware geklaert wird.

Mailserver testen

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Vor laengerer Zeit gab es hier ja mal einen Beitrag der sich um das rudimentaere Testen eines Webservers via telnet und openssl drehte. Da war es nur konsequent, dass dem auch mal ein Beitrag folgt, der sich um das Thema Mail dreht.

Fangen wir erst mal einfach an und schauen, ob wir uns via SMTP mit unserem Mailserver verbinden und testweise mal eine Mail verschicken koennen.

ramon@client:~$ telnet 192.168.100.25 25
Trying 192.168.100.25…
Connected to mailserver.
Escape character is ‚^]‘.
ehlo client
220 mailserver NuNu 3.3(18) ipop3d (Amiga)
250-mailserver Hello client ([192.168.100.25]), pleased to meet you
250-HELP
250-SIZE 20971520
250 PIPELINING
MAIL FROM:ramon@kukla.info
250 ramon@kukla.info… Sender OK
RCPT TO:ramon@kukla.info
250 ramon@kukla.info… Recipient OK
DATA
354 Enter message, end with „.“ on a line by itself
SUBJECT:testmail
testmail
.
250 Message accepted for delivery
quit
221 mailserver SMTP Service closing transmission channel
Connection closed by foreign host.

Hat alles geklappt haben wir anschliessend eine Mail in unserem Zielpostkorb. Jetzt haben wir einen Server, der es erfordert sich vorab als berechtigter Benutzer zu authentifizieren. Da wir unsere Authentifizierung nicht unverschluesselt ueber das Netz schicken werden wir uns nun via SSL mit dem Mailserver verbinden.

Vorab noch ein Hinweis. Bei der Nutzung von openssl im folgenden Beispiel passiert es, dass bei Kommandos, wo das erste Zeichen ein R ist, ein Regonitiation initiiert wird. Das wuerde uns dann also spaetestens beim „RCPT TO:“ zum Verhaengnis werden. Daher rufen wir openssl mit der Option -ign_eof auf.

ramon@client:~$ openssl s_client -connect mailserver:465 -ign_eof
CONNECTED(00000003)
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
verify return:1

Certificate chain
0 s:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
i:/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver

Server certificate
—–BEGIN CERTIFICATE—–
MIIDnDCCAwWgAwIBAgIJAJLLd/ciGa54MA0GCSqGSIb3DQEBBQUAMIGRMQswCQYD
VQQGEwJERTEQMA4GA1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4x
DTALBgNVBAoTBHB0bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQD
Ewtmb28ucHRseC5kZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTAeFw0x
MTAyMjAxMzMxMzVaFw0yMTAyMTcxMzMxMzVaMIGRMQswCQYDVQQGEwJERTEQMA4G
A1UECBMHU2F4b25pYTEUMBIGA1UEBxMLRmFsa2Vuc3RlaW4xDTALBgNVBAoTBHB0
bHgxFzAVBgNVBAsTDkFkbWluaXN0cmF0aW9uMRQwEgYDVQQDEwtmb28ucHRseC5k
ZTEcMBoGCSqGSIb3DQEJARYNYWRtaW5AcHRseC5kZTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEA1VqGIqHj1sH8MAO8+kA2JPzb4dmEvRcnRMOvS0eCpmLsN+GX
Tz+RUZLu5/2tfB7ntggU/R0P/LozFbUsFDqckKrzTuzus21/EJGfN51p9pixpGBi
GyiXlUJ2hg3zwwckCwxEuoY+By/KlEH6sN7vGpycYj2rmaf0nBTuoL+DGoMCAwEA
AaOB+TCB9jAdBgNVHQ4EFgQUpSWQtdmGGGMs8yYIWQZbtRQbJCswgcYGA1UdIwSB
vjCBu4AUpSWQtdmGGGMs8yYIWQZbtRQbJCuhgZekgZQwgZExCzAJBgNVBAYTAkRF
MRAwDgYDVQQIEwdTYXhvbmlhMRQwEgYDVQQHEwtGYWxrZW5zdGVpbjENMAsGA1UE
ChMEcHRseDEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFDASBgNVBAMTC2Zvby5w
dGx4LmRlMRwwGgYJKoZIhvcNAQkBFg1hZG1pbkBwdGx4LmRlggkAkst39yIZrngw
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCQAvHWM1QUAw447V/l+1X+
R8+ATWJJUsj1dCtSrkrCuS9hS1mxnnLlWa/Jpe+ipRcHLdvYQ7g+iaWupujeZv8B
PqpipLSPyuaSlIlCJe38fUKbXuPbSLkx6RA8PrY6O3y32T23Rmc13HV5gwbf+8zI
/A3WXwxoOTYz/GzIA2+VMg==
—–END CERTIFICATE—–
subject=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver
issuer=/C=DE/ST=Saxonia/L=Falkenstein/O=ptlx/OU=Administration/CN=mailserver/emailAddress=admin@mailserver

No client certificate CA names sent

SSL handshake has read 1499 bytes and written 319 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 6CFEC94B29AEFC1099D87B785F58631DF6D328F135B2CA75D5368566C1D3C19D
Session-ID-ctx:
Master-Key: 330430753D0F29C93467334FA9D0C43700C0B5DE6F8AD2F9D606B0A4ACD565FC9012F49DD7EEE2F7BE04AF2E0FC9137F
Key-Arg : None
Start Time: 1318419830
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

220 mailserver NuNu 3.3(18) ipop3d (Amiga)
ehlo client
250-mailserver
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Jetzt kommt der interessantere Teil, die Authentifizierung. Diese erfolgt via AUTH LOGIN oder AUTH PLAIN. Der Unterschied zwischen den beiden Methoden ist, dass bei ersterer (AUTH LOGIN) Benutzername und Kennwort getrennt uebertragen werden, wohingegen bei AUTH PLAIN Benutzername und Kennwort „am Stueck“ uebertragen werden. Allerdings werden Benutzername und Kennwort nicht im Klartext sondern Base64-kodiert uebermittelt. Um einen solchen kodierten String zu erhalten kann man entweder einen der diversen Online-Konverter nutzen, oder ein lokales Perl mit dem MIME::Base-Modul.

amon@client:~$ perl -MMIME::Base64 -e ‚print encode_base64(„meinpasswort“);‘
bWVpbnBhc3N3b3J0
ramon@client:~$ perl -MMIME::Base64 -e ‚print encode_base64(„ramon@kukla.info“);‘
cmFtb25Aa3VrbGEuaW5mbw==

Mit Hilfe der generierten Werte koennen wir uns nun also Authentifizieren und unsere Mail senden.

AUTH LOGIN
334 VXNlcm5hbWU6
cmFtb25Aa3VrbGEuaW5mbw==
334 UGFzc3dvcmQ6
bWVpbnBhc3N3b3J0
235 2.7.0 Authentication successful
MAIL FROM:ramon@kukla.info
250 2.1.0 Ok
RCPT TO:ramon@kukla.info
250 2.1.5 Ok
DATA
SUBJECT:testmail
354 End data with .
testmail
.
250 2.0.0 Ok: queued as BAA9C19EFD6E
quit
221 2.0.0 Bye
read:errno=0

Soweit so prima. Jetzt moechten wir natuerlich noch mal schauen, wie es sich mit IMAP darstellt. Bei IMAP ist wichtig zu wissen, dass alle Kommandos von einem sogenannten Identifier angefuehrt werden muessen.

ramon@client:~$ openssl s_client -connect mailserver:993
CONNECTED(00000003)
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify error:num=18:self signed certificate
verify return:1
depth=0 /O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
verify return:1

Certificate chain
0 s:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
i:/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver

Server certificate
—–BEGIN CERTIFICATE—–
MIIDJTCCAo6gAwIBAgIJAO3v57G3iscCMA0GCSqGSIb3DQEBBQUAMGsxHDAaBgNV
BAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQw
EgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRs
eC5kZTAeFw0xMTAyMjAxMDQzNTBaFw0xMjAyMjAxMDQzNTBaMGsxHDAaBgNVBAoT
E0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5wdGx4LmRlMRQwEgYD
VQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9vdEBmb28ucHRseC5k
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7CqNuyJwyDYfkhjOYsBdLouu
tLDx/QjVulAyisf+YMWwRr/ZMI5dZCoB2+VYVk+px4pP0asNjtiMD7/aKgPs3SJH
LmcaPIfXayBYVVpwi1jEFhSNowCcQjmoPHAM0PrNJNz9qVGpxJkk/kwpXd8kPdBk
Eq1b/41Xb7NDbTLZ/GUCAwEAAaOB0DCBzTAdBgNVHQ4EFgQU6q65YYtCAUMqLMDi
crAg+zYxfSIwgZ0GA1UdIwSBlTCBkoAU6q65YYtCAUMqLMDicrAg+zYxfSKhb6Rt
MGsxHDAaBgNVBAoTE0RvdmVjb3QgbWFpbCBzZXJ2ZXIxFDASBgNVBAsTC2Zvby5w
dGx4LmRlMRQwEgYDVQQDEwtmb28ucHRseC5kZTEfMB0GCSqGSIb3DQEJARYQcm9v
dEBmb28ucHRseC5kZYIJAO3v57G3iscCMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN
AQEFBQADgYEARNxqxB3K++zRyB1mdaSU/P52yXEb03tqqaV+58lf75hfsBUHnz/8
1GUM2I98HM6r7nsqxG9WjCuNgDfvuZZ4A+5T3O1TPdJViTBZG/zAi4lvIHfalF5f
3ZmLUye2qLFlBScxCGdsvZ3RAOg/tskbJDgeKr/HaWAxqRlmcAxO1h8=
—–END CERTIFICATE—–
subject=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver
issuer=/O=Dovecot mail server/OU=mailserver/CN=mailserver/emailAddress=root@mailserver

No client certificate CA names sent

SSL handshake has read 1380 bytes and written 319 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 7DA8529181D88B345F6DF5771AA502682D534C7816F9036265D69F22A958AA50
Session-ID-ctx:
Master-Key: 4112D1CB2EE9357F5DF0226395E1D007C1C6401FD8F8EDC4D0C4E1CE0A98A3AA91BEB23165974633A8E60EAC349D2981
Key-Arg : None
Start Time: 1318426371
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a0001 LOGIN ramon@kukla.info meinpasswort
a0001 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in
a0003 EXAMINE INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft $label1 $label2 $label3 $label4 $label5 $Forwarded)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 23 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1249171322] UIDs valid
* OK [UIDNEXT 25979] Predicted next UID
* OK [HIGHESTMODSEQ 10887] Highest
a0003 OK [READ-ONLY] Select completed.
a0004 FETCH 14 BODY[]
* 14 FETCH (BODY[] {1467}
Return-Path: <ramon@kukla.info>
Delivered-To: ramon@kukla.info
Received: from localhost (localhost [127.0.0.1])
by mailserver NuNu 3.3(18) ipop3d (Amiga) with ESMTP id 21D0E141E0A4;
Tue, 11 Oct 2011 22:45:38 +0200 (CEST)
From: Ramon Kukla <ramon@kukla.info>
To: ramon@kukla.info
Subject: testmail
User-Agent: Yet Another Mailer (YAM) (2.6p1)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline</ramon@kukla.info></ramon@kukla.info>

testmail

Blog: http://ramon.kukla.info – http://adminstories.de
Software failure! Press left mouse button to continue.
Guru Meditation #8100000A.000FEA00

)
a0004 OK Fetch completed.
a0005 LOGOUT
* BYE Logging out
a0005 OK Logout completed.
closed

Soweit, so fertig. Wer nicht nur einen, sondern mehrfach Tests mit (s)einem SMTP-Server durchfuehren muss, dem sei swaks (Swiss Army Knife SMTP) empfohlen. Das erleichtert einem ungemein die Arbeit mit dem ganzen getippe.

OpenVPN

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute, liebe Kinder, wollen wir euch erklaeren, wie ihr einen Tunnel baut 🙂

Eine Einrichtung, die keine grosse Huerde ist, aber die man oft auch nicht „mal eben“ macht, ist die Installation und Konfiguration eines OpenVPN-Tunnels. OpenVPN biete die Moeglichkeit eine gesicherte Verbindung zwischen Partnern aufzubauen. In unserem Fall werden das ein Server und ein Client sein.

Was ist der Vorteil an solch einem Tunnel?

Wenn wir Daten ueber ein „unsicheres Protokoll“ (FTP beispielsweise) uebertragen wollen oder muessen, hilft uns der Tunnel diese vor neugierigen Augen/Maschinen zu verstecken. Verstecken ist in dem Zusammenhang nicht ganz das richtige Wort, da es ja nicht in erster Linie um das Verheimlichen, sondern um das gesicherte Uebertragen geht. Hierfuer wird von OpenVPN TLS genutzt, was einige vermutlich aus dem s von https kennen.

OpenVPN an sich bietet viele tolle Dinge, wir wollen uns aber erst mal auf eine einfachen Tunnel im Routing-Modus zwischen Server und Client beschraenken.

Wie so oft schauen wir erst mal, dass die Software auf unser System kommt. Ich, als Nutzer von Debian/Ubuntu-basierenden Systemen, mache das also via aptitude install openvpn. Da wir zur Authentifizierung Zertifikate nutzen wollen, muessen wir nun noch einiges vorbereiten. Erst einmal kopieren wir ein paar Scripte nach /etc/openvpn

root@server ~ $ cd /etc/openvpn/
root@server /etc/openvpn $ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/
root@server /etc/openvpn $ cd easy-rsa/

Nun editieren wir die Datei vars. Im Speziellen geht es darum einige Werte zu „personalisieren“. Dies sind…

export KEY_COUNTRY=““
export KEY_PROVINCE=““
export KEY_CITY=““
export KEY_ORG=““
export KEY_EMAIL=““

Wenn alles soweit fertig ist, koennen wir endlich ein Serverzertifikat erstellen. Mit allem drumherum sieht das dann wie folgt aus.

root@server /etc/openvpn/easy-rsa $ source vars
root@server /etc/openvpn/easy-rsa $ ./clean-all # Initialisiere $KEY_DIR
root@server /etc/openvpn/easy-rsa $ ./build-dh # Erzeuge Diffie-Hellman Parameter
root@server /etc/openvpn/easy-rsa $ ./pkitool –initca # Erzeuge root CA
root@server /etc/openvpn/easy-rsa $ ./pkitool –server server # Erzeuge Server Zertifikat

Anschliessend erstellen wir noch ein Secret-Key und kopieren dann alles wichtige nach /etc/openvpn.

root@server /etc/openvpn/easy-rsa $ cd keys
root@server /etc/openvpn/easy-rsa/keys $ openvpn –genkey –secret ta.key
root@server /etc/openvpn/easy-rsa/keys $ cp server.crt server.key ca.crt dh1024.pem ta.key /etc/openvpn/

Damit nun alles ordentlich laeuft, muss natuerlich noch die Konfiguration angepasst werden. Eine Standardkonfiguration findet sich in /usr/share/doc/openvpn/examples/sample-config-files/ und nennt sich dort server.conf.gz. Diese kann man also nach /etc/openvpn bringen, dort entpacken und dann anpassen.

local 192.168.100.150
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

Im Grunde also keine Aenderung gegenueber der Standardkonfiguration. Nun kann der OpenVPN-Server auch schon gestartet werden. Fehlt nun noch der Client. Fuer den muessen wir natuerlich auch erst mal ein Zertifikat erstellen.

root@server /etc/openvpn/easy-rsa $ source vars
root@server /etc/openvpn/easy-rsa $ ./pkitool client

Und nun koennen wir das Zertifikat, und einige weitere benoetigte Dateien, auf den Client bringen. Im Detail brauchen wir folgende Dateien auf dem Client in /etc/openvpn: /etc/openvpn/ca.crt, /etc/openvpn/ta.key, /etc/openvpn/easy-rsa/keys/bar.crt und /etc/openvpn/easy-rsa/keys/bar.key

Jetzt kopieren wir uns noch die Default-Konfiguration /usr/share/doc/openvpn/examples/sample-config-files/client.conf nach /etc/openvpn und passen einige wenige Details an.

remote 188.40.57.208 1194
user nobody
group nogroup
cert client.crt
key client.key

Den Rest koennen wir belassen. Das war es schon und wir koennen unseren Tunnel aufbauen indem wir auf dem Client auch den OpenVPN-Daemon starten. Wenn wir in /var/log/syslog eine Meldung Initialization Sequence Completed sehen und ein ifconfig ein Interface mit dem Bezeichner tun0 anzeigt, schaut es schon mal gut aus. Ein Ping auf die OpenVPN-IP des Server sollte somit auch entsprechend durch gehen. Da wir keine Anpassung diesbezueglich gemacht hatten sind die beiden Peers im Netz 10.8.0.0/24.

ramon@client ~ $ ping -c 2 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=25.5 ms
64 bytes from 10.8.0.1: icmp_req=2 ttl=64 time=25.2 ms

— 10.8.0.1 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 25.231/25.386/25.542/0.222 ms

Was kann noch schief laufen?

Natuerlich ist das hier nur eine einfache Konfiguration und bei wachsenden Anspruchen kann es auch zu fantastischen Fehlern kommen. Zu Anfang passiert es schon mal, dass der Versuch ein Clientzertifikat via pkitool eine Fehlermeldung (TXT_DB error number 2) erzeugt. Ein Ausloser kann sein, dass man bereits ein Zertifikat erzeugt hat. Das muss dann nicht nur in /etc/openvpn/easy-rsa/keys geloescht werden, sondern es muss auch der entsprechende Eintrag in der index.txt im selben Ordner geloescht werden.

Pruefen, ob das Clientzertifikat zum Serverzertifikat passt, kann man uebrigens auf dem Client mit einem beherzten openssl verify -CAfile ca.cert -purpose sslclient client.crt.

strace

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Ist schon wieder Freitag? Ja tatsaechlich, ist es. Also los…

Es gibt ja verschiedene Wege mit Problemen umzugehen. Hat man bei Problemen entsprechende Logs oder Rueckmeldungen, kann man damit beispielsweise die Suchmaschine seiner Wahl bemuehen. Oder die Meldung ist schon so eindeutig, dass man gleich weiss wo man dran ist.

Es passiert aber auch immer wieder, dass ein Tool nicht tut was man erwartet, man aber auch keine Rueckmeldung bekommt. Fuer mich ist das oft der Punkt an dem ich aus einer von zwei Moeglichkeiten waehle. Ist das Tool neu und nicht wichtig genug, fliegt es wieder vom Rechner. Nutze ich das Tool aber schon laenger, oder ist es wichtig, bzw. gibt es keine sinnvolle Alternative, nehme ich gerne strace zur Hand.

Die man-Page von strace sagt, dass man „system calls und signals“ verfolgen kann. Und das trifft es auch ganz gut soweit. So kann man beispielsweise einfach mal ein strace whoami absetzen und schauen was (gekuerzt) raus kommt.

execve(„/usr/bin/whoami“, [„whoami“], [/ 47 vars /]) = 0
brk(0) = 0x9707000
access(„/etc/ld.so.nohwcap“, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb781e000
access(„/etc/ld.so.preload“, R_OK) = -1 ENOENT (No such file or directory)
open(„/etc/ld.so.cache“, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=64435, …}) = 0
mmap2(NULL, 64435, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb780e000
close(3) = 0
access(„/etc/ld.so.nohwcap“, F_OK) = -1 ENOENT (No such file or directory)
open(„/lib/i386-linux-gnu/libc.so.6“, O_RDONLY) = 3
read(3, „\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220o\1\0004\0\0\0″…, 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1434180, …}) = 0
mmap2(NULL, 1444360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x110000
mprotect(0x26a000, 4096, PROT_NONE) = 0
mmap2(0x26b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15a) = 0x26b000
mmap2(0x26e000, 10760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x26e000

write(1, „ramon\n“, 6ramon
) = 6
close(1) = 0
munmap(0xb781c000, 4096) = 0
close(2) = 0
exit_group(0) = ?

Die Ausgabe von strace ist auch schon im Standard relativ umfangreich. Wobei man sich nicht von der schieren Menge erschrecken lassen sollte. Man wird viele Eintraege sehen, die beinahe selbst erklaerend sind. Ein Teil „open“, „close“, „read“ oder „exit“. Natuerlich hat man auch Eintraege, die nicht auf den ersten Blick klar sind. Da hilft dann ein dezener Blick in „syscalls – Linux system calls“ auf kernel.org (was hoffentlich bald mal wieder erreichbar ist).

Ein haeufiger Fehler ist, dass eine Datei nicht gefunden oder geoeffnet (z.B. Berechtigung) werden kann. Wird eine Datei nicht gefunden kann das in einem strace etwa wie folgt ausschauen.

open(„/lib/libgcrypt.so.11“, O_RDONLY) = -1 ENOENT (No such file or directory)

Hier wird die Datei libgcrypt.so.11 nicht gefunden. Fairerweise muss gesagt werden, dass es nicht immer reicht den Fehler zu kennen. Denn… Ich sehe zwar, dass die Datei nicht gefunden wird, muss mich aber zumindest noch schlau machen wie ich diese nun auf mein System bekomme. Ist aber ein anderes Thema.

strace hat, wie so viele tolle Kommandos, umfangreiche Optionen. Eine sehr interessante Option, die einem schon mal zeigt was auf einen zukommt, ist -c.

ramon@bullfrog ~ $ strace -c whoami
ramon
% time seconds usecs/call calls errors syscall
—— ———– ———– ——— ——— —————-
-nan 0.000000 0 9 read
-nan 0.000000 0 1 write
-nan 0.000000 0 38 13 open
-nan 0.000000 0 29 close
-nan 0.000000 0 1 execve
-nan 0.000000 0 7 7 access
-nan 0.000000 0 3 brk
-nan 0.000000 0 7 munmap
-nan 0.000000 0 8 mprotect
-nan 0.000000 0 2 _llseek
-nan 0.000000 0 34 mmap2
-nan 0.000000 0 26 fstat64
-nan 0.000000 0 1 geteuid32
-nan 0.000000 0 1 fcntl64
-nan 0.000000 0 1 set_thread_area
-nan 0.000000 0 2 socket
-nan 0.000000 0 2 2 connect
—— ———– ———– ——— ——— —————-
100.00 0.000000 172 22 total

Auch interessant, wenn es noch tiefer gehen soll, ist die Option -f. Hierbei wird dann auch den Kinderprozessen gefolgt. Hier mal, gekuerzt, was strace -c sh -c ‚for i in $(cat dupes_*); do echo $i; done ausgibt…

% time seconds usecs/call calls errors syscall
—— ———– ———– ——— ——— —————-
84.22 0.004093 0 83870 write
15.25 0.000741 0 26798 read
0.53 0.000026 26 1 wait4

0.00 0.000000 0 1 set_thread_area
—— ———– ———– ——— ——— —————-
100.00 0.004860 110717 3 total

…und nachfolgend strace -f -c sh -c ‚for i in $(cat dupes_*); do echo $i; done (also mit Kinderprozessen).

% time seconds usecs/call calls errors syscall
—— ———– ———– ——— ——— —————-
85.34 0.007601 0 83980 write
14.35 0.001278 0 26923 read
0.31 0.000028 28 1 wait4

0.00 0.000000 0 2 set_thread_area
—— ———– ———– ——— ——— —————-
100.00 0.008907 111103 24 total

Man sieht, mit strace kann man viel Spass haben. Aber neben dem Spass hilft es in der Tat durchaus Problemen auf den Grund zu gehen. Man kann strace uebrigens auch an laufende Prozesse anhaengen. Allerdings habe ich schon mal gesehen, dass beim Beenden von strace auch der Prozess abgeschmiert ist. Das ist, meine ich, nicht normal, sollte man aber im Hinterkopf behalten. Vor allem wenn man ein Prozess auf einem produktiven Server mit 500 Benutzern untersuchen will.

Jobwechsel

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute mal zwei Beitraege. Nicht jeder freut sich ueber „nichttechnische“ Beitraege, daher eben heute eine kleine Anpassung 😉

Erstes Thema dreht sich um den Jobwechsel. Es gibt einige gute Buecher die sich im Hinblick auf IT mit Karriere und der Entwicklung beschaeftigen. Eines der Buecher, dass ich sehr lesenswert fand, war „Das IT-Karrierehandbuch“ von Martina Diel (danke an Dirk fuer die Leihgabe).

Bei einem Jobwechsel sollte man, aus meiner Sicht, einige Punkte beachten und beherzigen. Grob kann man das vielleicht mit „Ende ohne Aerger“ und „Start mit Erfolg/Freude“ umschreiben. Erst mal zum „Ende ohne Aerger“.

Es gibt viele Gruende das Unternehmen zu verlassen und zu wechseln. Vielleicht ist man zufrieden, bekommt aber ein Angebot, dass einfach so fantastisch zu sein scheint, dass man deshalb den Arbeitgeber wechselt. Realistischer ist aber, dass man im aktuellen Job nicht mehr zufrieden ist. Vielleicht gibt es keine weiteren Entwicklungsmoeglichkeiten (Gehalt, Position, Arbeitsgebiet) oder die Arbeitssituation hat sich verschlechtert. Also geht man auf die Suche, oder nimmt dann doch auch mal erste Angebote von Headhuntern wahr. Irgendwann hat man dann endlich das gewuenschte gefunden und es ist klar, es wird gewechselt. Wie geht es nun weiter?

• Arbeite, soweit moeglich, wie gewohnt bis zum letzten Tag
• Verhalte dich gegenueber den Kollegen wie gewohnt
• Ergaenze oder erstelle fehlende Dokumentation
• Hinterlasse einen aufgeraeumten Arbeitsplatz
• Mach eine Uebergabe an den Kollegen/Nachfolger
• Hinterlasse keine verbrannte Erde

Das sind einige Punkte und vermutlich kann man diese auch noch hier und da ergaenzen. Die Punkte zeigen aber schon wo es lang geht. Letztlich fasst der letzte Punkt die vorherigen auch ein Stueck weit zusammen. Auch wenn klar ist, dass ihr demnaechst woanders arbeitet, solltet ihr in den letzten Wochen weiterhin gewohnte Qualitaet abliefern. Natuerlich kann man einen Wechsel auch als Chance sehen, endlich mal durchzuladen und dem Chef fein einzuschenken. Aber mir sind nur Gruende bekannt, die dagegen sprechen sowas zu machen. Alleine schon, dass man sich immer zweimal im Leben sieht und man natuerlich auch gerne ein ordentliches Zeugnis haben moechte. Dirk wuerde das ganze sogar noch etwas kuerzer, aber dafuer nicht weniger korrekt, darstellen.

• Arbeit gut machen bis zum Schluss
• So aufhoeren, dass man wieder dort anfangen darf

Etwas schwieriger wird es bei „Start mit Erfolg/Freude“. Das liegt zum Teil auch daran, dass man auf viele Dinge anfaenglich keinen Einfluss hat. Entweder, weil im neuen Unternehmen die entsprechenden Prozesse fehlen oder weil man die Struktur (natuerlich) noch nicht kennt. Glueck hat, wer gleich zu Anfang in den wichtigsten Abteilungen den Kollegen vorgestellt wird. Natuerlich wird man sich nicht alle Namen merken koennen. Aber die Kollegen merken sich in der Regel das neue Gesicht und den dazugehoerigen Namen. Und auch wenn Kleidung noch lange keinen guten Mitarbeiter ausmacht. Aber oft ist der erste Eindruck, ob zu Recht oder Unrecht, besser, wenn man beispielsweise mir ordentlicher Hose und Hemd erscheint.

Was man sich immer vor Augen halten sollte ist, dass es zu Anfang ausgepraegte Phasen der Langeweile und des Stress geben wird. Und vor allem bei den Langeweile-Phasen wird es manchmal hart, da man auch noch fuer das Nichtstun bezahlt wird. Je nach Groesse des Umfeldes, in dem man nun arbeitet, kann man nicht erwarten, dass man nach zwei Wochen alle Prozesse, Zusammenhaenge und Organisationsdetails kennt. In meinem Fall hat man mir am Anfang gleich gesagt, dass man nicht damit rechnet, dass ich vor Ablauf von sechs Monaten „richtig“ arbeiten werde. Natuerlich kann man nach einiger Zeit die Kollegen bereits unterstuetzen. Aber wirklich alles zu lernen und kennen zu lernen, was fuer den aktuellen Job wichtig ist, dauert. Und dieses Entwicklung ist ja auch nicht immer von einem selbst kontrollierbar. Es wird auch immer wieder passieren, dass der Kollege oder „Ausbilder“ nicht immer Zeit fuer einen hat. Darueber muss man sich klar sein und sollte nicht frustriert sein, wenn man mal ein paar Tage lang keine Entwicklung sieht.

Und dann noch ein abschliessender Punkt, der aus eigener Erfahrung auch gerne unterbewertet wird. Im Rahmen der Einarbeitung wird man nicht nur viel lernen, sondern auch viele neue Eindruecke mitnehmen muessen und duerfen. Das alles fuehrt dazu, dass man fuer andere Dinge oft nicht mehr aufnahmefaehig ist oder schlicht einfach keine Lust mehr hat. Bei mir betrifft das beispielsweise unter anderem die Betreuung unserer Server, die nun etwas leidet, weil ich einfach oft keinen freien Kopf mehr habe, wenn ich nach Hause komme.

Flags von aptitude

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

So, und jetzt der zweite Beitrag. Noch eine Uebersicht verschiedener Flags fuer „aptitude“. Die hatte ich mir mal notiert, bzw. rausgesucht, da ich immer wieder mal Flags angezeigt bekommen hatte, die mir nicht so praesent waren.

Values of the „current state“ flag

i – the package is installed and all its dependencies are satisfied.
c – the package was removed, but its configuration files are still present.
p – the package and all its configuration files were removed, or the package was never installed.
v – the package is virtual.
B – the package has broken dependencies.
u – the package has been unpacked but not configured.
C – half-configured: the package’s configuration was interrupted.
H – half-installed: the package’s installation was interrupted.

Values of the „action“ flag

i – the package will be installed.
u – the package will be upgraded.
d – the package will be deleted: it will be removed, but its configuration files will remain on the system.
p – the package will be purged: it and its configuration files will be removed.
h – the package will be held back: it will be kept at its current version, even if a newer version becomes available, until the hold is cancelled.
F – An upgrade of the package has been forbidden.
r – the package will be reinstalled.
B – the package is „broken“: some of its dependencies will not be satisfied. aptitude will not allow you to install, remove, or upgrade anything while you have broken packages

Blackholes identifizieren

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Nein, wir bleiben im weiten Feld der EDV und wechseln nicht in die Astronomie. Obwohl Schwarze Loecher durchaus interessant sind. Aktuell geht es aber um sogenannte Blackholes in Netzen.

Wer sich ein wenig mit Netzwerken beschaeftigt wird wissen, dass Daten nicht am Stueck, sondern in Pakete verteilt, uebertragen werden. Bei TCP/IP sind das in einem Ethernet 1500 Byte. Die 1500 Byte sind natuerlich nicht der Bereich, der fuer Nutzdaten verwendet werden kann. Hier gehen dann noch die sogenannten Headerinformationen fuer IP (Source Address, Destination Address, Protocol, etc.) und TCP (Source Port, Destination Port, Flags, etc.) ab, so dass spaeter entsprechend weniger Platz fuer die Daten bleibt. Im Normalfall haben wir 20 Byte fuer IP und noch mal 20 Byte fuer TCP, womit dann 1460 Byte fuer weiter oben liegende Protokolle ueber bleiben.

Wenn nun einer der beteiligten Router nicht in der Lage ist ein Paket mit gesetztem DF-Bit (Don’t Fragment) ohne Fragmentierung zu uebertragen und keine entsprechende Meldung abgibt, dann haben wir ein Problem. Denn die beteiligten Hosts gehen davon aus, dass sie Pakete in der Groesse X versenden koennen, die gehen aber nicht ueber die Leitung, da der Router diese verwirft. Die Effekte koennen nun von Abbruechen der Verbindungen bis hin zu einfachen Aussetzern und Performanceproblemen fuehren. Was also tun, wenn man ein Blackhole vermutet?

Am einfachsten ist hier der Einstieg mit Ping. Unter Linux waere beispielsweise ein ping -c 1 -M do -s 1472 $ZIEL ein guter Ansatz. Mit -c 1 definieren wir, dass nur ein Paket geschickt wird. Das -M do bedeutet soviel wie Don’t fragment. Mit -s 1472 wird die Anzahl der Daten-Bytes festgelegt und mit $ZIEL, kaum ueberraschend, das Ziel. Das mit dem -c 1 (oder einem anderen sinnvollen kleineren Wert) sollte man machen. Andernfalls kann es passieren, dass einem nachher ewig viele Frag needed and DF set -Meldungen durch die Shell rauschen.

Die maximale Groesse der MTU (Maximum Transmission Unit) in unserem Beispiel (mal so ein „normales“ Ethernet angenommen) ist 1500 Bytes. Da ziehen wir dann noch 20 Bytes fuer IP und 8 Bytes fuer ICMP ab. Hier mal ein Beispiel.

ramon@superfrog ~ $ ping -c 1 -M do -s 1473 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1473(1501) bytes of data.
From 192.168.150.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)

— 192.168.0.1 ping statistics —
0 packets transmitted, 0 received, +1 errors

Hier sehen wir, dass es Probleme gibt, da die MTU 1500 Bytes gross ist. Wir wollten aber, zusaetzlich zu den 20 Bytes fuer IP und den 8 Bytes fuer ICMP, noch 1473 Bytes an Daten uebertragen. Und das ohne zu fragmentieren. Da wir in Summe mehr als 1500 Bytes haben, gibt es eine entsprechende Meldung. Als Vergleich noch ein Beispiel, in der das Paket ueber das Netz geht.

ramon@superfrog ~ $ ping -c 1 -M do -s 1472 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1472(1500) bytes of data.
1480 bytes from 192.168.0.1: icmp_req=1 ttl=62 time=5.51 ms

— 192.168.0.1 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.515/5.515/5.515/0.000 ms

Soweit so gut. Moechte man nun allerdings den Hop identifizieren, der Probleme macht, ist man nur mit der Ping-Methode nicht auf der sicheren Seite. Denn, wir erinnern uns, der „boese“ Router meldet ja nichts zurueck. Also nehmen wir uns traceroute als Werkzeug zur Hilfe. Fuer den Anfang machen wir erst einmal ein einfachen traceroute auf das Ziel via traceroute $ZIEL. Anschliessend kann man sich dann durch die Tabelle durcharbeiten. Der traceroute-Befehl von Windows und Linux unterscheiden sich allerdings, nicht nur in den Parametern, ein Stueck weit. Verwendet tracert unter Windows ICMP, so haben wir mit traceroute unter Linux im Standard UDP-Pakete.

ramon@superfrog ~ $ traceroute -n 192.168.0.1
traceroute to 192.168.121.254 (192.168.121.254), 30 hops max, 60 byte packets
1 192.168.150.1 0.341 ms 0.368 ms 0.411 ms
2 192.168.100.1 0.343 ms 0.362 ms 0.409 ms
3 192.168.0.1 18.310 ms

Nun haben wir eine Liste der beteiligten Stationen und koennen diese nun einzeln mit einem ping -f -l $PAKETGROESSE $ZIEL (um auch dem Windows-Ping mal eine Chance zu geben) testen.

Kleine Ergaenzung. Ich konnte nicht durchgaengig originale Ausgaben der Befehle verwenden, da der WLAN-Router in meinem Netzwerk beim Testen, vor allem mit zu grossen Paketen und dem gesetzten DF, aus dem Tritt kam und neu gestartet werden musste. *huestel*

Sollte es Fragen oder Unklarheiten geben, koennt ihr mich gerne ansprechen!

Welches System

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Eine hauefige Frage, vor allem beim Arbeiten mit verschiedenen Linux-Distributionen, ist die Frage nach der genau eingesetzten Version des Systems. Fuer folgende Systeme haben sich nachfolgende Wege bewaehrt:

• AIX: oslevel -r
• Fedora: cat /etc/fedora-release
• FreeBSD: uname -a
• HP-UX: uname -r
• NetBSD: uname -mrs
• OpenBSD: uname -a
• open-SUSE: cat /etc/issue oder cat /etc/SuSE-release
• RedHat: cat /etc/redhat-release
• Solaris: cat /etc/release
• Ubuntu: lsb_release -a oder cat /etc/issue

Sollte das alles nicht helfen kann, je nach System, ein Blick in das Bootmenue, beispielsweise /boot/grub/grub.conf, oder in dmesg einen Hinweis geben.

Entscheidungen

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Wieder mal ein weniger technischer Beitrag. Aber das wird sich sicher bald wieder aendern.

Ein Thema, mit dem sich Administratoren immer wieder beschaeftigen muessen ist das herbeifuehren von Entscheidungen. Sei es, weil, der Kunde im Rahmen eines Projektes Anforderungen hat oder weil es die eigene Infrastruktur zu verbessern gilt.

In der Regel ist es so, dass der Aufbau einer sogenannten Entscheidungsvorlage aufwaendiger wird, je groesser das Unternehmen ist. Wo man in einem Betrieb mit 20 Mitarbeitern eine Entscheidung im Gespraech mit dem Chef herbeifuehren kann, wird in groesseren Unternehmen ein Dokument mit mehreren Alternativen und belastbarem Zahlenmaterial erwartet. Gerne natuerlich als Word/PDF und fuer den schnellen Ueberblick noch ein paar Folien, die die wichtigsten Punkte gegenueber stellen. Das erfordert natuerlich einiges an Zeit, keine Frage. Aber die sollte man sich nehmen. Die Entscheidungsvorlage sollte beim ersten mal fehlerfrei und verstaendlich sein. Eine dem Vorstand vorgelegte Entscheidungsvorlage mit noch so kleinen Rechenfehlern oder einer Mischung aus Brutto und Nettopreisen macht gleich einen schlechten Eindruck und verringert die Chance auf Erfolg. Weitere Punkte, auf die man achten sollte, sind so Dinge wie Rechtschreibung, korrekte Verwendung von Satzzeichen und einheitliche sowie durchgaengig Formatierung.

Ein, aus meiner Sicht, extrem wichtiger Punkt ist das Akzeptieren der Entscheidung! Natuerlich wuerde man sich all den Aufwand nicht machen, wenn man nicht die Notwendigkeit zum Kauf neuer Hardwaere saehe. Denn wir sind als Administratoren natuerlich auch ein Stueck weit veranwortlich dafuer, dass das Geld, soweit wir das beeinflussen koennen, nicht zum Fenster rausgeworfen wird. Aber auch wenn der Server, schaut man sich alle Argumente an, im Grunde schon so gut wie bestellt sein muesste, kann es passieren, dass der Kauf abgelehnt wird. Das kann diverse Gruende haben. Vielleicht gibt es neue Plaene und Ziele, die wir nicht kennen, den Server aber kurzfristig ueberfluessig machen? Vielleicht arbeitet man aber auch nach Artikel 3 des Koelsche Grundgesetzes (Et haet noch immer joot jejange.). Moeglicherweise war die Entscheidungsvorlage einfach nicht gut, sprich fehlerhaft, oder ueberzeugend genug. Egal was der Grund war, den man durchaus auch oft nicht erfaehrt, es hilft nichts aus dem Hemd zu springen.

Sicherlich kann man sich aergern und fragen, warum der so wichtige Invest abgelehnt wurde. Alle Gruende sprechen im Rahmen meiner Kentnisse doch dafuer, die Hardware zu bestellen. Aber wer beim Chef, Abteilungsleiter oder Vorstand ins Buero platzt um mal mit dem Schuh auf den Tisch zu kloppen, der wird nicht nur nichts an der Entscheidung aendern. Im Gegenteil kann es dann sogar sein, dass man es sich damit zukuenftig schwerer macht. Wir sind halt nicht in einem Hollywood-Film, in dem wir als Helden mit Einsatz von ausreichend Schimpfwoerten, schlagkraeftigen Argumenten und, wenn alles nichts hilft, dem 45er Colt doch noch alles zum Guten wenden.

In den Bereichen „ueber uns“ wird oft anderes gerechnet und argumentiert. Und es halten sich tatsaechlich auch Geruechte, dass Vorgesetzte keine Entscheidungen treffen wollen. Denn… Wer ist letzlich verantwortlich? Und wem werden unangenehme Fragen gestellt, wenn sich der Kauf als Fehlkauf rausgestellt hat? Und jetzt stelle man sich vor, der Entscheider hat kein Rueckgrat. Gut, das gibt es nur in der Theorie. Aber wenn…?

Vielleicht, weil es kein technischer Beitrag war, noch eine nette kleine Geschichte. Cisco hat bei seinem IOS (Betriebssystem fuer Netzwerkhardware wie Switche) einen Sprung von Version 12 auf Version 15 gemacht. Hintergrund ist, dass die 13 in der westlichen Kultur als Unglueckszahl gilt. Und die 14 steht im Asiatischen Raum fuer „Unfall“ oder „Wird sterben“.

Lesen von Quelltext

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute mal was ohne grosse Scripte. Eine Sache, die meiner Meinung nach auf fuer einen „normalen“ Administrator hilfreich ist, ist die Faehigkeit Code zu lesen und zu verstehen.

Vor einigen Wochen hatte ich mich gefragt, wie snaplen fuer tcpdump eingestellt ist. Snaplen ist der Wert, der definiert wieviel Bytes an Daten je Packet mitgeschnitten werden. Ich hatte im Kopf, dass der Standard-Wert hier bei 68 Bytes stand. Allerdings war dann waehrend des Mitschnitts capture size 96 bytes zu lesen. Das Widersprach zum einem dem was ich noch im Kopf hatte und zusaetzlich auch den Angaben in der man-Page. Was also macht man? Man liest den Quellcode.

Ich habe den Effekt in der Version 4.0.0 von tcpdump gehabt und habe mir daher den Quellcode von http://www.tcpdump.org/release/tcpdump-4.0.0.tar.gz runter geladen. Ein ersten Blick habe ich in tcpdump.c geworfen. Dort ist unter anderem auch der Teil zu sehen (ab Zeile 743), wo snaplen ueber den Parameter „-s“ gesetzt werden kann.

case ’s‘: {
char *end;
snaplen = strtol(optarg, &end, 0);
if (optarg == end || *end != ‚\0‘
|| snaplen < 0 || snaplen > 65535)
error(„invalid snaplen %s“, optarg);
else if (snaplen == 0)
snaplen = 65535;
break;
}

Vorab ist, in Zeile 517, aber auch zu sehen, dass es auch einen Defaultwert zu geben scheint. DEFAULT_SNAPLEN wiederum wird in der Datei interface.h definiert.

#ifndef INET6
#define DEFAULT_SNAPLEN 68 / ether + IPv4 + TCP + 14 /
#else
#define DEFAULT_SNAPLEN 96 / ether + IPv6 + TCP + 22 /
#endif

Wenn also INET6 gesetzt ist, dann wird als Defaultwert fuer Snaplen 96 Bytes definiert. Und INET6 kann im Rahmen des Kompiliervorganges ueber den Schalter –enable-ipv6 gesetzt werden. Siehe hierzu auch die Datei configure ab Zeile 4644.

{ echo „$as_me:$LINENO: checking whether to enable ipv6“ >&5
echo $ECHO_N „checking whether to enable ipv6… $ECHO_C“ >&6; }
# Check whether –enable-ipv6 was given.
if test „${enable_ipv6+set}“ = set; then
enableval=$enable_ipv6; case „$enableval“ in
yes) { echo „$as_me:$LINENO: result: yes“ >&5
echo „${ECHO_T}yes“ >&6; }
LOCALSRC=“print-ip6.c print-ip6opts.c print-mobility.c print-ripng.c print-icmp6.c \
print-frag6.c print-rt6.c print-ospf6.c print-dhcp6.c $LOCALSRC“
cat >>confdefs.h <<_ACEOF
#define INET6 1

Offensichtlich wurde tcpdump in der von mir verwendeten Umgebung also gleich mit –enable-ipv6 kompliliert, weshalb 96 Bytes, statt wie von mir erwartet 68 Bytes, mitgeschnitten wurden.

Das hier ist nur ein Beispiel, warum das Lesen von Code hilfreich und auch sinnvoll sein kann. Das Beispiel ist vermutlich nicht das Beste. Aber ich habe schon oefter Probleme loesen oder Funktionen verstehen koennen (wie funktioniert das beispielsweise mit der wpad.dat im Firefox?), nachdem ich den Code der Anwendung, wenn verfuegbar, gelesen hatte. Wichtig zu wissen ist auch, dass ich tatsaechlich meine „Code lesen“, nicht „Code schreiben“. Obwohl es oft auch hilft wenn man in der Lage ist eigenen Code zu schreibe, so ist es fuer die Fehlersuche oft ausreichend den Code nur lesen und verstehen zu koennen. Es gibt auch viele, die koennen Englisch verstehen oder lesen, tun sich aber schwer eigene Saetze zu formulieren.

Und ein weiterer Grund, manchmal Code zu lesen ist, dass es Spass macht.

« Ältere Beiträge Neuere Beiträge »

© 2025 Software Failure

Theme von Anders NorénHoch ↑