S4Y - Routing zwischen dalta und athen

[Evil.2000]

S4Y - Routing zwischen delta und athen

Hallo!

Seit gestern Abend ca. 23:51 Uhr funktioniert das Routing zwischen der delta und der athen reihe nichtmehr.

Aufgefallen ist mir das weil ich ein VPN zwischen beiden Systemen laufen habe welches gestern um besagte Zeit grundlos abgebrochen ist:

Tue Oct  9 23:00:12 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Oct  9 23:00:12 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct  9 23:00:12 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Oct  9 23:00:12 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct  9 23:00:12 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Oct  9 23:51:29 2007 [s4u] Inactivity timeout (--ping-restart), restarting
Tue Oct  9 23:51:29 2007 TCP/UDP: Closing socket
Tue Oct  9 23:51:29 2007 SIGUSR1[soft,ping-restart] received, process restarting
Tue Oct  9 23:51:29 2007 Restart pause, 5 second(s)
Tue Oct  9 23:51:34 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by
IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Oct  9 23:51:34 2007 Re-using SSL/TLS context
Tue Oct  9 23:51:34 2007 LZO compression initialized
Tue Oct  9 23:51:34 2007 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Tue Oct  9 23:51:34 2007 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Oct  9 23:51:34 2007 Local Options hash (VER=V4): '69109d17'
Tue Oct  9 23:51:34 2007 Expected Remote Options hash (VER=V4): 'c0103fa8'
Tue Oct  9 23:51:34 2007 Attempting to establish TCP connection with 85.25.134.48:54
Tue Oct  9 23:54:43 2007 TCP: connect to 85.25.134.48:54 failed, will try again in 5 seconds: Connection timed out (errno=110)
Tue Oct  9 23:57:57 2007 TCP: connect to 85.25.134.48:54 failed, will try again in 5 seconds: Connection timed out (errno=110)
Wed Oct 10 00:01:11 2007 TCP: connect to 85.25.134.48:54 failed, will try again in 5 seconds: Connection timed out (errno=110)

Meine Routiung-Table stimmt. Laut traceroute auf beiden Maschinen liegt der Fehler im 85.25.255.0er Netz.

athen172 ~ # ping 85.25.134.48
PING 85.25.134.48 (85.25.134.48) 56(84) bytes of data.

--- 85.25.134.48 ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 17998ms

athen172 ~ # traceroute 85.25.134.48
traceroute to delta345 (85.25.134.48), 30 hops max, 38 byte packets
1 static-ip-217-172-180-1.inaddr.intergenia.de (217.172.180.1) 0.494 ms 0.574 ms 0.936 ms
2 * * *
3 FT-SX-02.intergenia.de (85.25.255.222) 1.090 ms 0.665 ms 0.900 ms
4 * * *
5 * * *
6 * * *
7 * * *


delta345 ~ # traceroute 217.172.181.172
traceroute to static-ip-217-172-181-172.inaddr.intergenia.de (217.172.181.172), 30 hops max, 38 byte packets
1 static-ip-85-25-134-1.inaddr.intergenia.de (85.25.134.1) 0.569 ms 0.537 ms 0.483 ms
2 * * *
3 static-ip-85-25-255-50.inaddr.intergenia.de (85.25.255.50) 0.674 ms 0.678 ms 0.691 ms
4 * * *
5 * * *
6 * * *
7 * * *

Wer hat das gleiche Problem oder hat ein System aus der delta oder athen Reihe und kann dieses Phänomen nachvollziehen?
Der Support von S4Y ist trotz angehängten Logfiles von route,traceroute und ping zu blöd zu erkennen, daß das Problem nicht an meinen Systemen liegt sondern an deren routing zwischen den Serverzentren.

Gruß

Evil.2000

P.S.: Wie die mit den Logindaten umgehen ist mir auch ein Rätsel. Die wollen jetzt schon zum zweiten mal mein root-Passwort (welches ich ihnen bis jetzt noch nicht gegeben habe) nur um am Ende festzustellen, daß das Problem doch nicht bei meinen Systemen liegt.

 

[Evil.2000]

So!

Gestern Abend um 18:21 Uhr lief die Verbindung wieder. Natürlich musst ich gleich mal beim Support nachfragen, weil die Herren ja der Meinung waren mein System hat nen Fehler, hah!

Sehr geehrte Herren,

seit heute um 18:21 Uhr funktioniert die Verbindung wieder.
Hatten Sie eine Überprüfung des Netzbereiches veranlasst, oder lag der Fehler an etwas anderem?

MfG

Und heute kam als Antwort:

Sehr geehrter Kunde,

der Fehler wurde an die Netzwerkabteilung weitergegeben und in der letzten Nacht behoben.

Mit freundlichen Grüßen

Aber erstmal die Kunden für dumm verkaufen und darauf beharren das root-Passwort für beide Systeme haben zu wollen weil man Firewall und Routing überprüfen wolle. Obwohl alle nötigen Logs am Fehlerbericht angehangen wurden aus denen erkenntlich ist, daß es nicht an den Systemen selbst liegen kann.
Bin schon ein bissel sauer auf so eine Inkompetenz. >:-(

Und ich war wirklich so naiv und dache im Support arbeiten Profis.

Evil.2000

 

[society]

weil man Firewall und Routing überprüfen wolle

Sorry aber das doch der normale Weg. Wenn ich nen Fehler suche will ich auch erst beim Kunden alle Daten haben bevor ich überhaupt Anfange zu suchen.. einmal um einfach nicht den Zugangsdaten hinterher zu rennen und zweitens um ev. Tests zu fahren. Logfiles bedeuten nicht immer 100% Ausagen obs auch wirklich daran liegt.

 

[Evil.2000]

Ich habe denen zwei mal versichert das es nicht an meinem System liegen kann. allein das traceroute hat deutlich gezeigt, daß meine routen direkt in besagtem Netz abbrechen. Das kann weder etwas mit Firewalleinstellungen zu tun haben, noch mit falschem Routing denn aus dem Log allein war ersichtlich, daß default GW korrekt eingetragen ist. Somit kann man nicht einmal die Firewall verdächtigen, denn die spielt erst dann eine Rolle, wenn die Pakete an der Gegenstelle angekommen sind, was ja schon garnicht der Fall war.

Was ich eigentlich damit sagen will:
Jeder Admin und noch mehr jeder Anwender bekommt gelernt, sein Passwort für sich zu behalten und es niemandem zu sagen bzw. - wenn es sich um Zugänge für Systeme handelt, die auch von anderen Personen gewartet werden müssten - es an einem sicheren Ort aufzubewahren (z.B. im Tresor). Und dort soll ich mein root-Passwort einfach so hinterlegen? Da weiß ich weder wo es gespeichert wird (womöglich im Klartext in irgendeiner MySQL-DB die nichtmal sonderlich gesichert ist) oder es geht an den Support per eMail(!) raus.
Super Sicherheitskonzept, mal ehrlich!?

Und grad bei sowas wo mir der Kunde (also ich) handfeste Beweise vorlegt, daß es nicht an den Systemen liegen kann und man dann ohne darüber nachzudenken nochmal nach dem Passwort verlangt, das ist in meinem Augen Unfähigkeit.

Zugegeben, ich als Supporter hätte auch erstmal genau gefragt und den Kunden verdächtigt daß er was falsch gemacht hat, aber bevor ich das tue les ich mir die Logfiles die er mir mitgeschickt hat durch und denke drüber nach.
Ich war selbst an der Hotline für Lotus Notes damals und hatte mit vielen Leute zu tun wo der Fehler vor dem Rechner saß, aber bevor ich den Kunden um sein Passwort oder ähnliche sensible Daten bitte, schau ich doch, obs nicht auch ohne das geht und ob der Kunde nicht vielleicht doch recht hat mit seiner Vermutung.

Oder irre ich da?

Naja gut .. reg ich mich wieder ab. Ich will hier nicht rumtrollen.

Evil.2000

 

[society]

OT: Lotus Notes AAAAAAARGH ich bekomme wieder das Augenzucken ;-)

Aber es hat sich ja nun zum Guten gewendet und es wurde behoben. Das du natürlich nicht dein Rootpasswort rausgibts ist ja klar das ändert man ja auch vorm Rausgeben und setzt ein anderes sobald das Ticket geschlossen wird.

 

[Evil.2000]

OT: Lotus Notes AAAAAAARGH ich bekomme wieder das Augenzucken ;-)

Jap. Das hatte ich nen halbes Jahr lang. Dannach hab ich zu gesehen, daß ich das Weite suche

[...] das ändert man ja auch vorm Rausgeben und setzt ein anderes sobald das Ticket geschlossen wird.

Viel zu viel Aufwand
Am Ende bekommen die meinen Passwortgenerierungsalgorythmus noch raus

Nee im Ernst: Ich persönlich mag es nicht wenn jemand per root auf der Kiste rumtollt und ich nicht weiß was er genau macht. Vor mir aus nenn' mich paranoid aber schließlich sind sensible Daten auf den Systemen, die nicht jeden etwas angehen. Auch Schäuble nicht!

Evil.2000

 

[LinuxAdmin]

Nee im Ernst: Ich persönlich mag es nicht wenn jemand per root auf der Kiste rumtollt und ich nicht weiß was er genau macht. Vor mir aus nenn' mich paranoid aber schließlich sind sensible Daten auf den Systemen, die nicht jeden etwas angehen.

Dann darfst Du Dir aber auch nicht den Server bei einem Hoster mieten oder einen eigenen in einem Co-Locationcenter unterstellen. Eine alte Weisheit besagt, dass derjenige, der physischen Zugang zum Rechner hat, quasi root-Rechte hat.

Viele Grüße,
LinuxAdmin

 

[Evil.2000]

Dann darfst Du Dir aber auch nicht den Server bei einem Hoster mieten oder einen eigenen in einem Co-Locationcenter unterstellen. Eine alte Weisheit besagt, dass derjenige, der physischen Zugang zum Rechner hat, quasi root-Rechte hat.

Das ist Ausnahmslos korrekt, jedoch hat man nicht immer genug Geld sich seinen eigenen Server-Raum mit AC, 16" Schrank, CO2 Löschanlage und High End Server auf einmal zu kaufen .

Ich will ja auch nicht mekkern. Letztenendes kann jeder der Böses will auch Böses tun wenn er vor Ort ist. Kompromisse muss man dann eben schließen. Aber einen kompetenten Support darf man doch verlangen, oder? Ja ob man den bekommt is ne andere Frage. Und wenn man das root-Passwort nicht mal ab und zu verlangen würde dann könnte man ja auch gar nicht auf die Systeme schauen und neben der eigentlichen Arbeit von den ganzen Saug-Kidz die Pr0ns ziehen die auf den Servern liegen.
Wer hat da grad "böswillige Unterstellung" gerufen?

Sei es wie es sei, ich misstraue eben bevor ich bereitwillig etwas blindlinks tue. In dieser Situation war mein Misstrauen berechtigt. Beim nächsten Mal kann es vielleicht von Vorteil sein wenn der Support mir auf der Kiste als root helfen kann.

Trotzdem sollten die S4Yer etwas mehr auf Sicherheit achten. Grad die athen-Reihe ist in einem sehr unsicheren Netzwerk-Umfeld gelandet.


Evil.2000