Verbruik op 1 dag, 23x het gemiddelde

[RBeun]

Dag mede WHT-leden,

Na een blik op het dataverbruik van een van onze servers bleek dat deze 230GB op 1 dag heeft verstookt waar normaal het gemiddelde rond de 10GB per dag ligt. Hierna was het verbruik weer gemiddeld.

Voor een 100/100mbit geen moeite uiteraard, maar wel vreemd.

Na wat onderzoek ben ik erachter gekomen dat het dataverkeer over één ip-adres naar buiten is gegaan (dus vanaf de server). Een ip-adres dat niet wordt gebruikt door klanten (zitten allemaal op een ander ip).

Er draait DirectAdmin op. Nu weet ik dat standaard bijv. e-mail via het "hoofd" ip-adres van de server naar buiten gaat en dus niet mee telt met het dataverkeer van de gebruikers. Lijkt mij dat dit wel geldt voor al het verkeer dat gedownload wordt van een user.

Het verbruik via DirectAdmin ziet er goed uit, geen uitschieters en elke user heeft een limiet.

Ik heb de log bestanden bekeken van apache voor mogelijk veel requests in die tijd, maar dit is lastig ivm logrotate (verbruik is afgelopen vrijdag geweest). Deze maakt namelijk per domein een .tar.gz(nr.) aan, en dat zijn er nogal wat

Maken overigens gebruik van CSF, en er is geen melding geweest van processen die hoge load veroorzaken of langdurig draaide.

Iemand tips over mogelijk meer onderzoek? Een scriptje via een corrupte WP is altijd mogelijk, maar dan hadden er logs moeten zijn..

Mocht er meer informatie nodig zijn, verneem ik dit graag

Voorbaat dank!

[joriz]

Anders je klanten even scannen met CXS op mogelijke exploits/scripts: http://configserver.com/cp/cxs.html

Niet al het verkeer wordt door controlepanelen zoals Direct Admin gemonitord. Zoals database verkeer naar externe database door een script wordt meestal niet mee geteld. Al gaat dat meestal om een verwaarloosbare hoeveelheid. Kan het zijn dat iemand een backup heeft gemaakt vanuit Direct Admin?
Heb je nog iets als Munin draaien of een andere processenmonitor service waaruit je kan afleiden hoe het verkeer eruit ziet en waar het ongeveer vandaan komt?

[RBeun]

Back-up wordt door ons gedaan (automatisch) en het verkeer op de back-up server is normaal gebleven evenals de hoeveelheid aan back-up van die dag.

Gebruikers hebben geen toegang tot DirectAdmin, dit gaat via ons CMS. Tevens geen back-up mogelijkheid voor de gebruiker zelf.

Heb verder niks draaien als in Munin, ben wel van plan zoiets te installeren om herhaling te voorkomen (herhaling van veel zoeken).

Cacti en MRTG zien er ook goed uit. Maar dat is voor de volgende keer, zoek nu de oorzaak met bestaande middelen.

[t.bloo]

ff snel het programma "atop" installeren (apt-get install atop) en je kunt met atop -r altijd terugkijken wat er aan programma's hebben gedraaid en wat de load en verkeer enzovoorts was

[RBeun]

zeker handig, maar begrijp uit de documentatie dat dit pas werkt nadat atop geinstalleerd is (en elke dag is opgestart, of maakt dat niet uit voor de raw files?)

[The-BosS]

Je zou splunk kunnen installeren en je bestaande files importeren, dat zal je alvast wat helpen met het doorzoeken van je log files.

[RBeun]

Je zou splunk kunnen installeren en je bestaande files importeren, dat zal je alvast wat helpen met het doorzoeken van je log files.

Handige tool, kan nu makkelijker door de bestanden gaan. Lijkt echter weinig tot niks aan de hand te zijn. Geen herhalende RETR wat het enorme verbruik kan verklaren.

Iemand een idee waar verder te kijken? Of wat mogelijk een oorzaak kon zijn.

Overigens was er die ervoor dag een ddos aanval binnen het netwerk. Later ook een vanuit het netwerk richting Facebook. Echter niks gemerkt op de server. Ik zou direct denken aan een ddos scriptje (CXS gaat er sowieso overheen). Maar dat had ik dan toch moeten merken?

[visser]

Handige tool, kan nu makkelijker door de bestanden gaan. Lijkt echter weinig tot niks aan de hand te zijn. Geen herhalende RETR wat het enorme verbruik kan verklaren.

Iemand een idee waar verder te kijken? Of wat mogelijk een oorzaak kon zijn.

Overigens was er die ervoor dag een ddos aanval binnen het netwerk. Later ook een vanuit het netwerk richting Facebook. Echter niks gemerkt op de server. Ik zou direct denken aan een ddos scriptje (CXS gaat er sowieso overheen). Maar dat had ik dan toch moeten merken?

230GB is ca 20 Mbit gedurende 24 uur. Dat hoef je dus niet te merken.
Of 60 Mbit gedurende 8 uur, ook niet heel merkbaar als het geen verkeer is wat veel resources vraagt om te genereren.

Was het inkomend of uitgaand ?
Het hoeft natuurlijk geen http te zijn.

FTP warez ?
Mogelijk heeft je provider netflow in het netwerk draaien, (en voldoende gedetailleerd om een stroompje van 20M te zien), dan kun je vragen wat voor soort verkeer.

[RBeun]

230GB is ca 20 Mbit gedurende 24 uur. Dat hoef je dus niet te merken.
Of 60 Mbit gedurende 8 uur, ook niet heel merkbaar als het geen verkeer is wat veel resources vraagt om te genereren.

Was het inkomend of uitgaand ?
Het hoeft natuurlijk geen http te zijn.

FTP warez ?
Mogelijk heeft je provider netflow in het netwerk draaien, (en voldoende gedetailleerd om een stroompje van 20M te zien), dan kun je vragen wat voor soort verkeer.

Bedankt voor je bericht. Het was uitgaand verkeer. FTP warez lijkt mij niet mogelijk. CSF had dan vast iets laten horen. Met name logins en processen die niet toegestaan zijn.

Ik heb het aan de provider gevraagd en die zegt dat ze dat niet meten. Zal morgen nog eens bellen om te kijken wat ze nog meer kunnen aanleveren.

[The-BosS]

Bedankt voor je bericht. Het was uitgaand verkeer. FTP warez lijkt mij niet mogelijk. CSF had dan vast iets laten horen. Met name logins en processen die niet toegestaan zijn.

Ik heb het aan de provider gevraagd en die zegt dat ze dat niet meten. Zal morgen nog eens bellen om te kijken wat ze nog meer kunnen aanleveren.

Hou er wel even rekening mee dat als je van switch perspectief kijkt dat uitgaand op de switchpoort, eigenlijk inkomend is op je server en omgekeerd. En dat logs files niet echt een beeld geven over het trafiek verbruik en al zeker niet als het iets is dat vanuit de cli uitgevoerd wordt. Zoals visser zegt, vraag eens na bij de provider (of indien je dit zelf kan inzien) hoeveel trafiek er in welke tijdspanne gebruikt is.

[visser]

Bedankt voor je bericht. Het was uitgaand verkeer. FTP warez lijkt mij niet mogelijk. CSF had dan vast iets laten horen. Met name logins en processen die niet toegestaan zijn.

Verkeer wat door een client gestart wordt (http get etc) zal als source het adres hebben waarop de connectie binnenkwam.
Verkeer waarbij de server de sessie opzet (of niet-sessie, zoals udp/icmp) zal als source het 'hoofd' ip adres krijgen.
Of meer precies, het IP adres van het interface waarlangs de beste route naar buiten loopt.
Als er gewoon secondary/aliassen op een enkel interface staan zal dat dus het primary ip adres zijn.

Een programma (of iptables setup) kan daar alleen met enige moeite wat aan doen en de computer dwingen een andere source te nemen.

Als je min of meer zegt dat op het adres waar het verkeer vandaan kwam geen webserver draait (?), begint dat te wijzen op een situatie waarbij een programma op de server het verkeer gestart heeft.
Dan ga je toch denken aan een botje.

Ik heb het aan de provider gevraagd en die zegt dat ze dat niet meten. Zal morgen nog eens bellen om te kijken wat ze nog meer kunnen aanleveren.

[RBeun]

Bedankt voor jullie reacties.

Hou er wel even rekening mee dat als je van switch perspectief kijkt dat uitgaand op de switchpoort, eigenlijk inkomend is op je server en omgekeerd. En dat logs files niet echt een beeld geven over het trafiek verbruik en al zeker niet als het iets is dat vanuit de cli uitgevoerd wordt. Zoals visser zegt, vraag eens na bij de provider (of indien je dit zelf kan inzien) hoeveel trafiek er in welke tijdspanne gebruikt is.

Goed punt, nu ben ik ook een beetje confused wat/wie er bedoeld wordt met uitgaande trafiek. Ik hoop dat ik daar morgenochtend meer uitsluitsel over krijg.

Verkeer wat door een client gestart wordt (http get etc) zal als source het adres hebben waarop de connectie binnenkwam.
Verkeer waarbij de server de sessie opzet (of niet-sessie, zoals udp/icmp) zal als source het 'hoofd' ip adres krijgen.
Of meer precies, het IP adres van het interface waarlangs de beste route naar buiten loopt.
Als er gewoon secondary/aliassen op een enkel interface staan zal dat dus het primary ip adres zijn.

Een programma (of iptables setup) kan daar alleen met enige moeite wat aan doen en de computer dwingen een andere source te nemen.

Als je min of meer zegt dat op het adres waar het verkeer vandaan kwam geen webserver draait (?), begint dat te wijzen op een situatie waarbij een programma op de server het verkeer gestart heeft.
Dan ga je toch denken aan een botje.

Dat zou een ernstige uitkomst zijn. als dat zo is, hoop ik daar informatie over te kunnen vinden. Vooralsnog duidt niks daarop. De grootste bestanden zijn onaangetast, en er is geen duidelijke groei in log bestanden.

Inhoudelijk heb ik de logbestanden ook gecontroleerd in dat tijdspad. Niks opvallends.


Zou er een effect kunnen zijn op de statistieken/routers nadat ze een aantal ddos aanvallen hebben moeten weerstaan in dat tijdspad? Het netwerk bedoel ik dan.

[visser]

Bedankt voor jullie reacties.



Goed punt, nu ben ik ook een beetje confused wat/wie er bedoeld wordt met uitgaande trafiek. Ik hoop dat ik daar morgenochtend meer uitsluitsel over krijg.



Dat zou een ernstige uitkomst zijn. als dat zo is, hoop ik daar informatie over te kunnen vinden. Vooralsnog duidt niks daarop. De grootste bestanden zijn onaangetast, en er is geen duidelijke groei in log bestanden.

Inhoudelijk heb ik de logbestanden ook gecontroleerd in dat tijdspad. Niks opvallends.


Zou er een effect kunnen zijn op de statistieken/routers nadat ze een aantal ddos aanvallen hebben moeten weerstaan in dat tijdspad? Het netwerk bedoel ik dan.

Bedenk wel dat ik een behoorlijk aantal speculaties gedaan heb, waar jij naar moet kijken of de voorwaarden kloppen.
-als- het verkeer echt uitging van de server (goed punt van The-Boss), en uitging met source adres waar geen server op draait en die source is het hoofd IP van de server, dan is een redelijke kans dat de server het verkeer gestart heeft.
Nu kun met een vrij simpel programma makkelijk 20-60M verkeer maken, en afhankelijk van het soort logging hoef je daar weinig van te zien.

Het vervoeren van een DDos zal op zich niet enorm veel invloed op de verkeersmetingen (dwz: kwaliteit ervan) hoeven hebben. Natuurlijk telt dat verkeer mee in de grafieken van interfaces waar het langs gaat.
Het enige effect wat ik kan bedenken is als de provider toch al ietwat laksig meet (namelijk 32 bit counters op 100M+ interfaces gebruiken en vijf minuten polling), is dat de counter gewrapped heeft bij een hoog verkeersvolume. Dat zie je als een heel rare en onmogelijk hoge sprong.
(je hoort de 64 bit counters te gebruiken).

In deze context zou je alleen denken dat jouw server misschien ook bronnetje geweest is, met 100 x 20M heb je wel 2G verkeer, een heel behoorlijke DDos.

[RBeun]

Goedemorgen,

Nieuwe dag, nieuwe mogelijkheden om navraag te doen. Overigens draaien wij geen Plesk en is onderstaand bericht van Tweakers.net niet van toepassing op onze situatie:

http://tweakers.net/nieuws/80462/hac...plesk-lek.html

Na een gesprek met de technische support kwam het volgende aan het licht:

Waarschijnlijk zijn er die dag verkeerde metingen verricht. Support heeft meerdere "onjuiste" grafiekmetingen doorgekregen van klanten. Ze gaan hier intern achteraan en laten klanten weten wat hier uitgekomen is.

Over de bit-counters konden ze weinig zeggen. Wel kon ik ze vertellen dat de metingen van gister er vandaag anders uitzien! 2 maart: 218gb verstookt zoals gister te lezen, vandaag is er op 2 maart 220gb verstookt!

Dit nemen ze mee bij de interne bespreking, en zou het feit bekrachtigen dat de metingen niet kloppen.

Uiteraard laat ik het weten als er meer nieuws is, de klopjacht is vooralsnog wat bedaart omdat dit de oorzaak lijkt te zijn. zoals The-BoSS aangaf, is er inderdaad weinig af te lezen in de logbestanden aan trafiek verbruik. Hierop nemen wij zelf maatregelen om dit verbruik scherper in de gaten te kunnen houden.

[visser]

Goedemorgen,

[..]

Waarschijnlijk zijn er die dag verkeerde metingen verricht. Support heeft meerdere "onjuiste" grafiekmetingen doorgekregen van klanten. Ze gaan hier intern achteraan en laten klanten weten wat hier uitgekomen is.

Over de bit-counters konden ze weinig zeggen. Wel kon ik ze vertellen dat de metingen van gister er vandaag anders uitzien! 2 maart: 218gb verstookt zoals gister te lezen, vandaag is er op 2 maart 220gb verstookt!

Hm, met zoveel vaagheid is het eerst maar even afwachten wat er uit komt voordat je je verder zorgen gaat maken inderdaad.
Ik zou dan wel op je eigen server ook simpel volumes gaan loggen.
(de interface counters, eventueel via snmp vanaf een ander systeem uitlezen, of een paar iptables regels die je als counter gebruikt. Met iptables kun je meteen een grove verdeling maken van soort verkeer en volumes. (bv tcp/80, tcp/443, tcp overig, udp, icmp , ip overig)

Het antwoord dat je van support kreeg doet me denken dat "32 bit snmp counters" niet zo'n "ja duh dat weet toch iedereen" geval is als ik dacht.
Ik zeg niet dat dit het probleem is, maar in elk geval iets om te weten :

Verkeersvolume op netwerk apparatuur wordt ongeveer altijd gemeten door met SNMP interface counters uit te lezen.
De octet (byte) counter die je uit kunt lezen is een 32 bits getal, waarmee dus 4GB aan volume uitgelezen kan worden. Als de maximale waarde bereikt is, begint de counter weer op nul.
De uitlees programma's gaan ervan uit dat in het meet-interval (meestal vijf minuten) de counter niet volledig klokje-rond kan gaan. Echter, 4GB in vijf minuten kan best op een 100 Mbit interface.

Daarom is er nog een extra MIB variable bij gekomen, en dat zijn de HC (high capacity) counters, die 64 bit zijn.
Die moeten met SNMPv2c (of v3) uitgelezen worden, omdat SNMPv1 geen 64 bit waarden kan uitlezen.

Dit 'issue' is niet bepaald nieuw (de rfc met 64 bit snmp counters is uit 1997), maar goed, als er ergens nog defaults met snmpv1 staan kan iemand er weer tegen aan lopen.

Linkjee naar een cisco pagina met uitleg , het meeste is algemeen van toepassing, afgezien natuurlijk van de hw/sw versies van cisco apparatuur :
http://www.cisco.com/en/US/tech/tk64...800b69ac.shtml

Dit nemen ze mee bij de interne bespreking, en zou het feit bekrachtigen dat de metingen niet kloppen.

Uiteraard laat ik het weten als er meer nieuws is, de klopjacht is vooralsnog wat bedaart omdat dit de oorzaak lijkt te zijn. zoals The-BoSS aangaf, is er inderdaad weinig af te lezen in de logbestanden aan trafiek verbruik. Hierop nemen wij zelf maatregelen om dit verbruik scherper in de gaten te kunnen houden.