Zitat von dp.falko |
Der Server ist embeded und wird automatisch mit installiert. |
|
Der Server vor Ort läuft auf embeded Hardware oder mit dem Firmwareupdate und Settingsfile wird ein HTTP Server mit aufgespielt? (Ich gehe von ersterem aus)
Zitat von dp.falko |
Die möglichkeiten sich logs anzuschauen sind sehr begrenzt, und Presales kann mir keine Infos liefern. Deswegen dachte ich, mach ich den Streßtest einfach selber. Die Anfragen wäre alle aus dem lokalen LAN des Kunden. Danke für euren Input.
|
|
Das klingt ja nach ner Eiersuche. Ich würd auf jedenfall den Admin vor Ort zuerst anhauen ob der ne Idee hat ob da irgendeine Filtereinheit abfischt (unwahrscheinlich wenn es wie du sagst ein LAN ist), aber der kennt sein Netz nunmal und kann dir da vielleicht schon weiterhelfen.
Der Pentest bringt dich in dem Fall aber nur bedingt weiter. Du willst ja wissen wo der leak ist (kommt das Packet an, krieg ich ne Bestätigung vom Server, verschluckt sich die Hardware bei zuvielen Anfragen, etc. pp).
Mit dem Pentest weißt du dann zwar DAS es nicht klappt aber WAS ist damit immer noch nicht geklärt.
Simpelste Variante ist, du bringst den Server mit nur einem Client ohne (oder wenns denns ein muss mit möglichst wenig) Netzstrucktur zusammen. Im bestenfall einfach mit nem Crossover-Patchkabel.
Der Client startet nun ganz gemütlich die Anfrage an den Server und die schneidest du mit
Wireshark komplett mit.
Jetzt hast du den "Fingerabdruck" einer Funktionierenden Verbindung (Client Request, Server Response, End of Transmission).
So soll es aussehen und so soll es immer aussehen. Jetzt bringst du den Pentest ins Spiel und schneidest auch hier mit Wireshark mit.
Wenn dann die beklannten Probleme auftauchen ist ein wenig Dedektivarbeit beim durchforsten des Mitschnitts gefragt. Die miesten Pentools werden dir aber nen genauen Timestemp zu jedem Paket geben (bspw. 2014-08-25:13:37:00 Requested ... 2014-08-25:13:37:10 Timed out) und dann ist es relativ einfach in Wireshark den Anfang zu finden wo du suchen musst.
Z.B. könnte es sein das du im Wireshark siehst das der Request raus ist, der Empfang des Pakets womöglich auch noch mit einem Paket quitiert wird, danach aber keine Verbindungsinitialisierung vom Server mehr stattfindet (das wäre dann z.B. ein Hinweis nach den maximalen Verbindungen im HHTP Server zu gucken, ist aber nicht eindeutig! Kann auch sein das er das acknowledgement noch bearbeitet kriegt, für den Rest aebr die Luft fehlt).
Die Wahrscheinlichere Variante ist aber das auf den Request gar nichts mehr zurück kommt, das wäre dann ->
Mein Tipp ist relativ banal: Der Server hat nicht mehr genug Hardwarekapazität alle eingehenden Anfragen (in Zeit) abzuarbeiten, zum Absturz reicht es aber
noch nicht aus. Die Clients bekommen entweder gar keine Antwort auf ihre Anfrage oder die Bearbeitung der Anfrage dauert so lange, dass der Client Timeout schon überschritten ist (da hilft dir dann wieder Wireshark um rauszufinden ob was kommt, wenn ja nach welcher Zeit -> Serverconfig checken, Pakete älter alx X können auch direkt vom Server verworfen werde, dann siehst du im Shark natürlich nichts).
Evt. könnte man das Problem dann sogar lösen indem man einfach den Timeout der Clients hochschraubt, dass kommt dann aber wieder auf den HTTP Server an, der eine legt sich kurz nach dem er Stottert die Karten, andere sind soweit auf Stabilität ausgelegt, dass sie zwar langsam werden aber Ihren Betrieb aufrecht erhalten (auch dabei gehen aber sehr schnell Daten verloren, da der Server Requests nicht länger Cashen "kann" als der Client ein acknowledgement aktzeptiert , also bei Standarteinstellungen minimal bis gar nicht).
Wie dem auch sei, sollte dein Pentest mit direkter Verbindung ergeben, dass es (in dem Umfang wie er normalerweise beballert wird) nicht am Server liegt, kannst du wieder zurück zum Netzwerkhansel und ihn mit deinen Ergebnissen um Hilfe bei der Suche nach dem schwarzen Schaaf bitten.