SYN flood aanval: server onbereikbaar en router traag

Mijn server reageert niet meer, mijn router is traag en mijn router log toont SYN flood aanvragen. Wat moet ik nu doen? Hoe los ik dit op?

Recentelijk ben ik in aanraking gekomen met een DOS aanval. Een SYN flood aanval. Interessant gegeven. Als particulier het slachtoffer worden van een DOS aanval. De eerste vraag die je dan stelt is: Waarom? Hoe kan dat nu? Zo interessant ben ik toch niet? Ik ben maar een enkele particuliere gebruiker? Wat maakt het interessant om mij aan te vallen? Wie mag mij niet?

Eerst een stukje context. Het viel me op dat ik mijn cloudserver niet meer kon bereiken. Toen ben ik gaan kijken of ik gekke dingen kon vinden op mijn server. Kan ik nog inloggen via ssh? Zijn alle updates gedraaid? Is mijn webserver nog ‘up’. Wat zeggen de logs? Toen ik had vastgesteld dat er niets bijzonders aan de hand leek te zijn met mijn server, heb ik updates gedraaid en mijn server herstart. Dit loste het probleem niet op. Toen ben ik gaan kijken op mijn router. De router gaf aan dat er ‘syn flood’ aanvragen vanuit verschillende IP’s richting mijn IP adres zijn gestuurd. Toen ging ik zoeken naar wat SYN Flood is. En dit bleek een DoS (Denial of Service) aanval te zijn.

Een SYN FLOOD aanval zorgt (zoals hier te lezen) ervoor dat er meerdere (synchronous) verbindingsaanvragen worden gestuurd naar een server. Deze aanvraag wordt gedaan vanuit een ‘niet bestaand’ of ‘gespoofed’ IP adres. De server reageert hierop en wacht op antwoord. Dit antwoord komt niet en dus wacht de server een time out periode. In de tussentijd reserveert de server ruimte en wanneer alle ruimte gebruikt is, reageert de server niet meer op andere aanvragen. Vervolgens krijgt de server weer een aanvraag. Het gevolg van dit soort aanvallen is dat de server niet meer bereikbaar is voor ‘legitieme’ aanvragen.

Na nog iets verder zoeken lijkt het erop dat dit niet zozeer een gerichte aanval op mijn server is, danwel een gerichte aanval op IP adressen behorende bij mijn ISP (internet service provider). De aanval was ook gericht op meerdere poorten van mijn router en mijn server op slechts op (een) enkele poort(en) open staat.

Nu ik dacht te weten wat het probleem was, wat kan ik dan doen?

  1. Het eerste wat ik heb geprobeerd was ‘googlen’ wat hieraan te doen is. Op linux zijn er mogelijkheden om SYN FLOOD attacks tegen te gaan. Bijvoorbeeld door de time out periode te verkleinen, wellicht beter nog het commando “echo -n 1 > /proc/sys/net/ipv4/tcp_syncookies” zoals aangegeven in deze ’thread’. Dit is op mijn eigen linux server mogelijk, maar op een Router van een ISP helaas niet altijd.
  2. Toen herstartte ik mijn router van mijn ISP en poef … alles werkte weer. De syn flood aanval(len) leken ook meteen gestopt.  Het probleem was dus opgelost nadat ik mijn router had herstart.
  3. Ergens ook wel jammer, want nu kan ik niet meer testen of die andere oplossing werkt. Dus voor de volgende keer …

ownCloud log in Logwatch deel 2

Wanneer je ownCloud gebruikt als eigen cloud zul je er ook snel achter komen dat je nog steeds moet inloggen om de ownCloud log te bekijken. Daarvoor is deze post. Het geeft antwoord op de vraag: “Hoe zorg ik dat het ownCloud log in Logwatch wordt opgenomen?”.

Het antwoord is uiteindelijk vrij simpel, maar ik heb het volledige antwoord nog nergens kunnen vinden. Daarom deze instructie. Omwille van de lengte is deze in twee delen opgesplitst. Het eerste deel gaat over het inrichten van ownCloud. Het tweede deel gaat over het inrichten van Logwatch zodanig dat deze het ownCloud log meeneemt. Dit is deel 2, deze gaat er vanuit dat je ownCloud log in Logwatch deel 1 reeds doorlopen hebt.

Deel 2: ownCloud log in Logwatch opnemen

Hier wordt ervan uitgegaan dat de ownCloud server draait op Raspbian, zijn deze instructies ook daar primair voor bedoeld. Waarom? De Raspberry kost maar 30 euro en draait op 5 Watt. Reken wel mee dat je een of meer SD kaarten, een voeding, een kastje en waarschijnlijk een harde schijf nodig hebt, dus kom je in totaal op meer uit. Maar hoe krijg je nu die ownCloud log in Logwatch?

Logwatch leest de scripts uit in /usr/share/logwatch/scripts/services/. Als je hierin een bestand plaatst met de naam owncloud en met een juist script erin, dan wordt deze opgenomen in de email. Simpel! Kopieer een bestaand script en pas deze aan zodat het ownCloud log wordt uitegelezen en in Logwatch wordt uitgespuugt.

2a. waar staat het script?

nano /etc/logwatch/conf/logfiles/owncloud.conf

# The LogFile path is relative to /var/log by default.
# You can change the default by setting LogDir.
LogFile = /var/log/owncloud/*.log

# This enables searching through zipped archives as well.
Archive = /var/log/owncloud/*.gz

# Expand the repeats (actually just removes them now).
*ExpandRepeats

2b. wat moet in de email?

nano /etc/logwatch/conf/services/owncloud.conf

# The title shown in the report.
Title = “ownCloud”

# The name of the log file group (file name).
LogFile = owncloud

2c. welke regels wil je zien?

Hier is een eenvoudig voorbeeld voor een script dat het volledige log van de voorgaande dag in de email opneemt:

#!/usr/bin/perl

#ownCloud standard environment variables
$DateRange = $ENV{‘LOGWATCH_DATE_RANGE’} || yesterday;

if ($DateRange =~ /yesterday/) {
$epoc = time();
$epoc = $epoc – 24 * 60 * 60; # one day before of current date.
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($epoc);
$DateString = sprintf(“%04d-%02d-%02d”, $year+1900, $mon+1, $mday);
$DateString = $DateString.”T”;
}

while (defined($ThisLine = <STDIN>)) {
$ThisLine =~ s/\\//g;
$ThisLine =~ s/%20/ /g;
$FullLog{$ThisLine}++;

#filter for datarange yesterday
if ( ($DataRange = yesterday) and ($ThisLine !~ /$DateString/) ) {
#don’t care about these
}
else {
# Report any unmatched entries…
chomp($ThisLine);
$Unmatched{$ThisLine}++;
}
}

if (keys %Unmatched) {
print “\n**Unmatched Entries**\n”;
foreach $ThisOne (keys %Unmatched) {
print ” $Unmatched{$ThisOne} Time(s): $ThisOne\n”;
}
}

exit(0);

Nu heb je het ownCloud log in Logwatch opgenomen. Maar het kan nog beter toch?

2d. maak het leesbaar

Het script in kale vorm plaatsen is een relatief simpel klusje. Als je simpelweg het gehele log wilt laten uitspugen, dan is dit gelukkig niet moeilijk. Het bovenstaande script laat het volledige log in de email meesturen en haalt een aantal ‘onleesbare’ tekens eruit (de \ en de%20) en vervangt deze.  Echter om de gegevens in een beter interpreteerbare vorm te krijgen zul je nog wat moeten tweaken. Dit is nog ‘work in progress’.

Hierbij kunnen de volgende linux instructies van pas komen:

Test het script:

cat /owncloud/owncloud.log | perl /usr/share/logwatch/scripts/services/owncloud

Test logwatch:

logwatch –detail high –mailto name@domain.com –service all –range yesterday

 

 

ownCloud log in Logwatch deel 1

Wanneer je ownCloud gebruikt als eigen cloud zul je er snel achter komen dat je nog steeds moet inloggen om het ownCloud log te bekijken. Daarvoor is deze post. Het geeft antwoord op de vraag:

“Hoe zorg ik dat het ownCloud log in Logwatch worden opgenomen?”.

Het antwoord is uiteindelijk vrij simpel, maar ik heb het volledige antwoord nog nergens kunnen vinden. Daarom deze instructie. Omwille van de lengte is deze in twee delen opgesplitst. Dit eerste deel gaat over het inrichten van ownCloud. Het tweede deel gaat over het inrichten van Logwatch zodanig dat deze het ownCloud log meeneemt. Lees het vervolg in ownCloud log in Logwatch deel 2!

Voorwaarde: een server met ownCloud en Logwatch

Over het bouwen van een ownCloud server en het installeren en configureren van Logwatch is veel informatie te vinden op het internet. Maar niet hoe je het ownCloud log in Logwatch opneemt. Daarom wordt hier niet ingegaan op bouwen van een server met ownCloud en Logwatch. Dit is de basis, als je dit kunt, dan is het configureren van Logwatch wat hierna wordt behandeld zeker binnen bereik.

Deel 1: ownCloud log directory

In ownCloud kun je op twee manieren de logs laten wegschrijven. Standaard worden deze in een afzonderlijke directory geplaatst (data directory). Maar het is ook mogelijk om deze in het systeemlog op te laten nemen. In dit geval wordt ervan uitgegaan dat het logbestand in een afzonderlijke directory worden geplaatst, /owncloud/owncloud.log

Stap 1a: zet de rechten goed

Zorg dat je webserver bij het owncloud log kan.

chown www-data:www-data /owncloud

chmod 770 /owncloud

chmod 660 /owncloud/owncloud.log

Stap 1a: owncloud.conf

Voeg de locatie van je log toe in het owncloud configuratie bestand.

nano /var/www/owncloud/config/owncloud.conf

‘logfile’ => ‘/owncloud/owncloud.log’,

Stap 1c: log rotatie

Omdat het roteren van logs door het programma logrotate specifieke rechten vereist, heb ik ervoor gekozen een cronjob aan te maken waarin het log dagelijks wordt geroteerd:

nano /etc/cron.daily/00logwatch

#!/bin/sh
DATE=`date +%Y%m%d`
logwatch –detail high –mailto name@domain.com –service all –range yesterday
mv /var/log/owncloud/owncloud.log /var/log/owncloud/owncloud$DATE.log
gzip /var/log/owncloud/owncloud$DATE.log