DOS aanval?

[Keeper of the Keys]

Ok ik heb een beetje een raar verhaal, ik beheer een server voor mijn oude school (en hun netwerk), op dit moment ben ik in een ander land en ik werd vandaag gebeld dat ze problemen hadden dus dook ik in de SSH en toe ontvouwde zich een interessante situatie die ik graag ook door anderen laat beoordelen voor ik te drastische maatregelen neem (zeker ook omdat ik nu ver van de server ben).

Het gaat hier om een Debian/lenny server, het IP adres is dynamisch.

Op de server waren enkele services die in /var moeten kunnen schrijven omgevallen nadat /var helemaal was opgevuld met logbestanden van 1.7GB per stuk.

Een computer in Beijing bleek gedurende ruim 2 uur met ca. 150kB/s, ca. 1400-1500 UDP pakketjes per seconde op mijn server (of eigenlijk het IP-adres waar de server nu op zat), resulterend in ruim 8.7 miljoen regels zoals de volgende:

code:

Mar 26 10:22:06 fanta kernel: [779452.245192] RULE 9 -- DENY IN=ppp0 OUT= MAC= SRC=120.32.144.31 DST=87.68.32.xxx LEN=64 TOS=0x00 PREC=0x60 TTL=50 ID=36900 PROTO=UDP SPT=14259 DPT=57471 LEN=44

Het lijkt erop dat de hele tijd dezelfde poorten bron en doel waren, de aanval begint onmiddellijk als om 10:22 de verbinding wordt ingesteld (de eerste pakketjes worden al gemeld voordat pppd de tijd heeft om überhaupt te melden dat het toegewezen IP adres 87.68.32.xxx is) en gaat onverminderd door tot 12:34 om welke tijd er een nieuw IP-adres wordt toegewezen.

Het is mijn indruk dat het hier gaat om een aanval of iets van die Chinese server tegen het IP-adres dat ik toevallig kreeg en niet een specifiek tegen mijn school gerichte aanval.

Ook wijst zoeken in andere logs niet op pogingen om via SSH binnen te komen of andere manieren van benaderen (apache etc.) vanaf het Chinese IP-adres.

Zit ik er heel erg naast of klopt deze analyze wel, en in het laatste geval moet ik dan nog andere actie ondernemen dan ruimte vrijmaken (logs naar een andere partitie verplaatst) en de services weer overeind zetten (wat ik al heb gedaan)?

[lordgandalf]

Ik zou de logs nog even in de gaten houden de komende dagen just in case.
Komt het weer terug dan is het tegen de school zo niet dan is het een toevals treffer.

[LuckY]

Als het een dynamisch ip adres is en je draait geen cruciale services binnen school zoals web/mail/ftp kan je altijd proberen je ip veranderd te krijgen.

Tevens zou je naar een fail2ban of een andere flooder/ddos preventer te kijken.
Volgens mij kan je zelf met een bruteforce detection aan de slag.

[Verwijderd]

Je kan in het vervolg toegang vanaf chinese, japanse en andere foreign-adressen by default blokkeren, tenzij je zelf vanuit zo'n land toegang tot je server wilt hebben. De oplossing is vrij simpel, weer gewoon elk land wat niets met jouw server moet

_bron

code:

<Files *>
order deny,allow

# Chinese IP addresses follow:
deny from 58.20.0.0/16 58.21.0.0/16 58.22.0.0/15 58.56.0.0/15 58.58.0.0/16 58.59.0.0/17 58.60.0.0/14 58.82.0.0/15 58.208.0.0/12 58.246.0.0/15 58.248.0.0/13 59.32.0.0/13 59.40.0.0/15 59.42.0.0/16 59.56.0.0/13 59.108.0.0/15 60.12.0.0/16 60.28.0.0/15 60.160.0.0/11 60.194.0.0/15 60.208.0.0/13 60.216.0.0/15 61.4.64.0/20 61.48.0.0/13 61.128.0.0/10 61.135.0.0/16 61.145.73.208/28 61.162.0.0/15 61.164.0.0/16 61.179.0.0/16 61.183.0.0/16 61.184.0.0/16 61.185.219.232/29 61.188.0.0/16 61.232.0.0/14 61.236.0.0/15 116.76.0.0/15 116.208.0.0/14 117.21.0.0/16 118.132.0.0/14 118.144.0.0/14 119.18.192.0/20 121.8.0.0/13 121.16.0.0/12 121.32.0.0/14 122.51.128.0/17 122.198.0.0/16 122.200.64.0/18 123.4.0.0/14 123.97.128.0/17 123.100.0.0/19 123.128.0.0/13 124.42.64.0/18 124.236.0.0/14 125.40.0.0/13 159.226.0.0/16 202.66.0.0/16 202.96.0.0/12 202.96.128.0/18 202.108.0.0/16 202.114.64.0/20 203.69.0.0/16 203.93.0.0/16 203.169.160.0/19 210.5.0.0/19 210.14.128.0/19 210.21.0.0/16 210.51.0.0/16 210.52.0.0/15 210.192.96.0/19 211.76.96.0/20 211.78.208.0/20 211.90.0.0/15 211.136.0.0/13 211.233.70.0/24 211.144.12.0/22 211.144.160.0/20 211.152.14.0/24 211.154.128.0/19 211.157.32.0/19 211.161.24.128/26 218.0.0.0/11 218.56.0.0/13 218.64.0.0/11 218.88.0.0/13 218.96.0.0/14 218.102.0.0/16 218.104.0.0/14 218.194.80.0/20 218.242.0.0/16 219.128.0.0/11 219.232.0.0/19 220.160.0.0/11 220.181.0.0/16 220.192.0.0/12 220.228.70.0/24 220.248.0.0/14 220.250.0.0/19 220.252.0.0/16 221.10.0.0/16 221.11.0.0/16 221.122.0.0/15 221.192.0.0/14 221.200.0.0/14 221.208.0.0/14 221.212.0.0/16 221.216.0.0/13 221.224.0.0/13 221.228.0.0/14 221.238.0.0/15 222.32.0.0/11 222.76.0.0/14 222.80.0.0/12 222.136.0.0/13 222.166.0.0/16 222.168.0.0/15 222.172.222.0/24 222.184.0.0/13

# Hong Kong
deny from 58.65.232.0/21 59.148.0.0/15 123.242.229.0/24 202.69.64.0/19 202.85.128.0/19 202.133.8.0/21 210.176.0.0/19 210.176.48.0/20 210.176.64.0/18 210.176.128.0/17 210.177.0.0/16 218.252.0.0/14 222.166.0.0/16

# Japan (hacking, botnets en spam)
deny from 118.13.128.0/17 118.86.0.0/15 122.208.0.0/12 123.216.0.0/13 150.70.84.41 218.225.179.0/24 219.125.233.0/24 222.144.0.0/13

# Korea IP addresses follow:
deny from 58.72.0.0/13 58.239.0.0/16 58.140.0.0/14 59.0.0.0/11 59.86.192.0/18 59.186.0.0/15 61.96.0.0/12 61.248.0.0/13 113.30.64.0/18 116.40.0.0/16 116.45.176.0/20 116.120.0.0/13 118.32.0.0/11 118.128.0.0/14 118.220.16.0/20 121.128.0.0/10 122.44.112.0/20 122.99.128.0/17 123.111.0.0/16 124.0.0.0/15 124.50.87.161 125.128.0.0/11 125.176.0.0/12 125.240.0.0/13 143.248.0.0/16 202.133.16.0/20 202.179.176.0/21 210.93.0.0/16 210.94.0.0/15 210.118.216.192/26 210.178.0.0/15 210.180.0.0/15 210.205.219.0/24 210.219.0.0/16 211.32.0.0/12 211.48.0.0/15 211.50.0.0/15 211.62.35.0/24 211.104.0.0/13 211.112.0.0/13 211.168.0.0/14 211.172.0.0/14 211.176.0.0/12 211.192.0.0/13 211.211.36.0/23 211.232.0.0/13 211.240.0.0/12 218.36.0.0/14 218.144.138.0/26 218.147.0.0/16 218.232.120.0/25 218.234.18.0/24 219.240.0.0/15 219.248.0.0/13 219.250.88.0/21 220.73.22.160/27 220.95.88.0/24 220.118.0.0/16 220.119.0.0/16 221.128.0.0/12 221.144.0.0/12 221.160.0.0/13 221.168.0.0/16 221.163.46.0/24 222.96.0.0/12 222.112.0.0/13 222.120.0.0/15 222.122.0.0/16

# Buurlanden van Asie:

# Malaysia
deny from 60.48.0.0/14 60.52.0.0/15 60.54.0.0/16 116.206.0.0/16 124.82.0.0/16 124.217.224.0/19 202.58.80.0/20 202.71.96.0/20 202.75.32.0/19 203.223.128.0/19 210.187.49.0/25 218.111.0.0/16 218.208.12.64/27

# Phillipines
deny from 85.92.152.0/21 125.60.128.0/17 202.133.192.0/24 222.127.32.0/19 222.127.64.0/19

# Singapore
deny from 59.189.0.0/16 116.14.0.0/15 121.6.0.0/15 165.21.0.0/16 203.92.64.0/18 218.212.0.0/16 219.74.0.0/16 219.75.0.0/17

# Taiwan
deny from 59.124.0.0/14 203.71.0.0/16 203.72.0.0/16 210.59.0.0/17 211.21.0.0/16 211.23.0.0/16 211.79.32.0/20 218.160.0.0/12

# Thailand
deny from 58.8.0.0/16 58.9.0.0/16 58.137.13.0/24 61.19.64.0/18 117.47.0.0/16 124.120.0.0/16 124.121.0.0/16 124.122.0.0/16 202.28.0.0/15 202.44.135.0/24 202.133.128.0/18 202.143.128.0/18 203.107.142.0/24 203.113.13.0/24 203.144.128.0/17 203.148.128.0/17 203.149.0.0/18 203.150.128.0/17 203.151.38.0/24 203.155.0.0/16 203.158.96.0/19 203.158.128.0/17 203.172.128.0/17 222.123.0.0/16

# Vietnam
deny from 58.186.0.0/16 58.187.112.0/20 116.96.0.0/12 117.0.0.0/13 118.68.0.0/14 123.16.0.0/14 125.234.0.0/15 203.113.128.0/18 203.162.0.0/16 210.245.80.0/21

# Einde chinese en koreaanse lijst

# hier kan je andere IP-adressen of domeinnamen in blacklisten naast bovenstaande users. Je begint met "deny from " zonder aanhalingstekens

# heb je een IP-adres dat in een whitelist moet ? (Dus toegestane IP-adressen) voeg dan het volgende toe: allow from 123.456.789.0

</Files>


# Het volgende voorkomt dat spiders, robots en meer je .htaccess bestand zullen lezen of zien:

<Files .htaccess>
deny from all
</Files>

Maw plemp bovenstaande in een .htaccess en voer wellicht ook de range van dat vreemde IP erbij. Loop ook even na of je geen IP-ranges meeneemt die niet daar horen. Suc6.

[Facer]

Verwijderd schreef op vrijdag 27 maart 2009 @ 09:14:
Je kan in het vervolg toegang vanaf chinese, japanse en andere foreign-adressen by default blokkeren, tenzij je zelf vanuit zo'n land toegang tot je server wilt hebben. De oplossing is vrij simpel, weer gewoon elk land wat niets met jouw server moet

_bron

code:

<Files *>
order deny,allow

...

Maw plemp bovenstaande in een .htaccess en voer wellicht ook de range van dat vreemde IP erbij. Loop ook even na of je geen IP-ranges meeneemt die niet daar horen. Suc6.

Je blokkeert hiermee de toegang tot apache maar daarmee los je niet het "probleem" op waar de TS mee zit. Omdat het daarbij gaat om een IP adres dat UDP pakketten stuurt naar zomaar een port. Een blokkade in de firewall van de server met deze IP adressen zou wel het probleem verminderen.

[soulrider]

en het even melden aan je eigen provider + de provider van de DoS'er dat de school last heeft van die DoS/ping-flood/....
Log meesturen enzo telkens.
Je kan het eventueel ook even melden aan een cert-groep van je provider, of het nationale cert-team.

Je hebt er misschien geen directe schade van, maar het andere (lees: wel gewenste) netwerkverkeer is er wellicht niet blij mee. Mails die niet verzonden geraken of juist niet aankomen bij de school, internet dat wat minder vlot gaat, ... Folders die nu door logs volgeraken waardoor de rest niet meer werkt zoals het hoort.
en de school heeft nu de uren te betalen die jij er aan spendeerde tijdens je vakantie om dit op te lossen.

Kan zijn dat dit een speler is die het niet leuk vond te verliezen op xbox-live of dergelijken en poogde de andere uit het spel te drukken met dit.

offtopic:
ik geef bij de eigen internet-connectie de meeste spam-mails, portscans, DoS'en en hackpogingen door naar de provider waarvan het komt en als het bezig blijft of als het een grotere scam-poging is, mag ook de Belgische fccu zich ermee gaan bezig houden. Sommige providers hebben nu een '3 strikes = out'-policy, dus altijd de moeite om de bel te luiden. ('please stop this spammer/hacker from abusing your service and network' - met dan het bewijs meegeleverd, doet het vaak heel goed) (maar ik heb dan ook een zero policy met zulke dingen, verdomde scriptkiddie's en botnetjes )

logs bijhouden eventueel, mocht ie terugkomen...

en meer dan blokkeren, melden en logs verplaatsen naar andere locatie met meer ruimte (of een 'oude logs'-tape) kan je wellicht niet doen op dit moment.

[ Voor 7% gewijzigd door soulrider op 27-03-2009 09:40 ]

[Keeper of the Keys]

Ik ga denk ik inderdaad contact opnemen met de provider(s), ik heb de logfiles nog maar ik kan denk ik beter een uittreksel geven want niemand zit te wachten op 8.7 miljoen regels waar alleen de timestamp en het volgnummer verschilt.

Op dit moment log ik elk pakketje dat door de firewall wordt geblokkeerd als ik dat niet zou doen zou dit ook niet zijn gebeurt, maar voor mijn gevoel krijg ik toch veel nuttige informatie uit die logs (al wordt het nu wel 3x gelogd en dat is overdreven, kern.log syslog en messages), iemand suggereerde dat ik dat niet echt nodig heb (en dus logging voor de blokkeer regel uit te zetten)...

Iets anders dat werd gesuggereerd is dat ik logrotate scherper af moet stellen, dat zou denk ik helpen onder normale omstandigheden maar ik vermoed dat het nu alleen uitstel van executie zou hebben gegeven?

[Verwijderd]

De meningen hierover verschillen, maar persoonlijk laat ik firewalls nooit loggen aan gezien ik teveel volgelopen partities heb gezien door logfiles en daarnaast zie ik er niet echt een meerwaarde van in. Maar goed over dit onderwerp verschillen de meningen onder sysadmins sterk.

[berties]

Ik zou het loggen in ieder geval niet uitzetten, dan heb je namelijk helemaal geen zicht meer op wat er gebeurd.
Je kunt wel wat doen om te voorkomen dat je schijf vol loopt door een hard groeiende /var/log. Zet je logrotate niet alleen op het roteren op een vaste datum/tijd maar ook op een bereikte omvang van de logfile. Als je dan aangeeft dat je maar max 10 logfiles wil en je zet de rotate bij 10Mb (eventueel mailen van verlopen logfiles) dan kun je het vollopen van je schijf redelijk tegen gaan.

[_lasher_]

Het nadeel van logrotate instellen op een vaste filesize is wel dat je na zo'n aanval ook echt alleen nog maar die paketten terug gaat vinden in je log. De rest van de gelogde informatie (misschien ook wel zinvol) wordt al verwijderd voordat je het kan lezen.
Maar ja, hoe vaak lees je je log?

En over het mailen van die log: als je zo veel informatie hebt, maar het is steeds grotendeels hetzelfde, dan is dat erg goed te comprimeren. Volgens mij moet dit gezipt geen probleem zijn om te versturen.

[Jaap-Jan]

berties schreef op vrijdag 27 maart 2009 @ 11:25:
Ik zou het loggen in ieder geval niet uitzetten, dan heb je namelijk helemaal geen zicht meer op wat er gebeurd.
Je kunt wel wat doen om te voorkomen dat je schijf vol loopt door een hard groeiende /var/log. Zet je logrotate niet alleen op het roteren op een vaste datum/tijd maar ook op een bereikte omvang van de logfile. Als je dan aangeeft dat je maar max 10 logfiles wil en je zet de rotate bij 10Mb (eventueel mailen van verlopen logfiles) dan kun je het vollopen van je schijf redelijk tegen gaan.

Alleen heb je zo nogal nutteloze logs. Als iemand probeert te verbinden met een service op een bekende poort, zoals http, smtp, ldap, pop, imap, dns enzovoort, zou ik dat wel willen weten. Maar om álle willekeurige pakketjes op álle poorten te loggen is nogal loos, imho.

[berties]

Jaap-Jan schreef op vrijdag 27 maart 2009 @ 11:50:
[...]


Alleen heb je zo nogal nutteloze logs. Als iemand probeert te verbinden met een service op een bekende poort, zoals http, smtp, ldap, pop, imap, dns enzovoort, zou ik dat wel willen weten. Maar om álle willekeurige pakketjes op álle poorten te loggen is nogal loos, imho.

Alle iptables acties loggen lijkt me ook niet zinvol maar als je alles wat gedropt of gereject wordt niet logt zie je ook dit soort aanvallen niet meer in je logs. Verder onderzoek en actie wordt dan wel moeilijk. Ik heb liever een log met 1000 gelijke regels met alleen een andere timestamp dan geen enkele regel. Bij die 1000 gelijke heb je in ieder geval snel gezien dat er wat mis is en wat er mis is en wat er is gebeurd.
Je moet alleen voldoende ruimte hebben of je logrotate goed ingesteld, en er redelijk snel bij zijn. Heb je een drukke server en een dos aanval en je wacht 1 week dan wil ik niet weten hoeveel die bak moet loggen...
fail2ban oid kan dan ook een uitkomst zijn, maar dan moet je wel weer loggen....

[Keeper of the Keys]

Mijn algemene gevoel is op dit moment ook dat als ik logrotate strikter had gehad of geen iptables drops logte ik ook geen idee zou hebben gehad waar het verkeer vandaan kwam.

Aan de andere kant zou ik in dat geval geen services hebben gehad die waren omgevallen (misschien ook wel bij betere logrotate omdat de load van het gzippen van de ~13MB log die per minuut werd gegenereerd de machine dan wel plat had getrokken) door gebrek aan ruimte.

Waar ik nu naar aan het kijken ben is het configureren van syslogd om iptables berichten in een bestand op een andere partitie op te slaan...
Het vervelende daar is dat de berichten voor zover syslog kan zien kern.level zijn dus of ik splits alle berichten van een bepaald niveau naar een ander bestand wat ook niet ideaal is...
Wat ik denk ik ga proberen is een greppende pijp als doel...

en als ik dat al aan het doen ben dan kan ik meteen ook iets doen dat veel pakketen van hetzelfde ip adres herkent en dan de log regels aanpast... etc... mijn brein gaat aan de haal...

[H!GHGuY]

iptables heeft ook hashlimit en limit matches.
Zie http://iptables-tutorial....orial.html#HASHLIMITMATCH bvb.
bovendien kan je aan het LOG target nog wel wat extra info meegeven.

Logrotate kan je ook instellen om logs te zippen. Je kan, zeker met dit soort logs, een zeer hoge compression rate behalen, dus dan heb je niet zo snel een disk vol.

Je kan bvb ook een script draaien dat het aantal logs van het laatste halfuur in de gaten houdt en bij een te harde stijging een administrator mailt.

code:

TIMESTAMP=/var/log/.timestamp
while true;
do
  touch $TIMESTAMP
  sleep $((30*60*60))
  COUNT=$(find /var/log -newer $TIMESTAMP -a -name "iptables.log" | wc -c)
  if [ "$COUNT" -gt "10" ]
  then
    sendmail ....
  fi
done

[deadinspace]

Over dat logging/diskspace verhaal:

Waarschijnlijk kun je iptables/klogd wel zover krijgen om iptables messages naar een aparte file te loggen. Dan zou je die file op een eigen partitie kunnen zetten, of van een gebruiker met disk quota kunnen maken, zodat je iptables logs nooit je /var in gevaar brengen. Ook heb je op die manier geen flood van iptables messages door je andere logs staan (waardoor andere potentieel interessante meldingen niet zo opvallen).

Ik vind het loggen van iptables rejects niet zo nuttig meestal. Het geeft problemen met logs (zoals in dit topic), en meestal heb je er niks aan.

[Rainmaker]

deadinspace schreef op zaterdag 28 maart 2009 @ 17:37:
Over dat logging/diskspace verhaal:

Waarschijnlijk kun je iptables/klogd wel zover krijgen om iptables messages naar een aparte file te loggen. Dan zou je die file op een eigen partitie kunnen zetten, of van een gebruiker met disk quota kunnen maken, zodat je iptables logs nooit je /var in gevaar brengen. Ook heb je op die manier geen flood van iptables messages door je andere logs staan (waardoor andere potentieel interessante meldingen niet zo opvallen).

Ik vind het loggen van iptables rejects niet zo nuttig meestal. Het geeft problemen met logs (zoals in dit topic), en meestal heb je er niks aan.

Eigenlijk is dat loggen van iptables naar een aparte file nog vrij lastig.

Het gebruikt gewoon de kernel logging, dus je moet een eigen "niveau" voor iptables gaan maken.

Je geeft in je iptables rule --log-level 4 mee, en vangt dan alles wat kern.warning binnenkomt op syslogd af. Is niet echt een geweldige workaround, omdat er geen enkele garantie is dat alles wat kern.warn is, ook daadwerkelijk van iptables afkomt.

Je kunt helaas (bij mijn weten) geen eigen logfile opgeven...

[igmar]

Rainmaker schreef op maandag 30 maart 2009 @ 01:52:
Je kunt helaas (bij mijn weten) geen eigen logfile opgeven...

De oplossing daarvoor heet ulog.