Traffic shaping mei iptables en tc

Gearfetting

Ferline moanne krige ik in automatysk alarm oer tefolle bânbreedtegebrûk, meastal in teken fan problemen. As dat bart, moatst do in standert incidintproseduere folgje en besykje de boarne fan it ferkear te isolearjen eardat do it ôfslutst. De oarsaak fan dit incident wie lykwols net wat ik ferwachte... en frege om in oare oanpak as in ienfâldige blokkade.

Folsleine tekst

Alarm foar tefolle bânbreedte

As do servers beheare, fernimst do dat ynternetferkear meastal foarkomt yn foarsisbere patroanen. Krekt as echt ferkear op de dyk binne der fêste tiden dat it drok is en rêstich.

Troch it foarsisbere patroan is it mooglik om anomalyen automatysk te detektearjen. Krekt as in file op de snelwei op in ûngewoane tiid it gefolch fan in ûngelok wêze kin, kinne ûnferwachte útslaggen yn ynternetferkear in oanwizing wêze foar in incident yn cyberspace.

De boarne isolearje

It earste wat do dwaan moatst is de boarne fan it probleem fine. Dat dochst do troch de anomaly te analysearjen mei:

• Bepale oft it ekstra ferkear ynkommend of útgeand is (up- of download?)
• De byhearrende boarne- en doel-IP-adressen bepale (hokker server is rekke? Wêr giet it ferkear hinne of wêr komt it wei?)
• De soarte ferkear bepale (e-mail, web of wat oars?)

Hjirfoar moatst do ferkearsgrafiken ynspektearje, dy litte meastal in dúdlik ûnderskied tusken ynfier en útfier sjen. Dan moatst do besykje de rekke IP-adressen te finen. Dat kin betsjutte dat do nei mear (yndividuele server)grafiken en statistiken yn switches, routers en servers sjen moatst. Sjoch dan nei CPU-gebrûk en logbestannen om te bepalen hokker applikaasje rekke is, lykas mail of web. Hoe grutter de anomaly is, hoe makliker er te finen is.

Do wurdst miskien ferliede om de anomaly te deadzjen sadree't do him fûn hast, en daliks it byhearrende ferkear stop te setten. Mar do moatst him echt (op syn minst noch efkes) libje litte om safolle mooglik fan him te learen.

Brûk in ark as iftop om in realtime oersjoch te sjen fan it bânbreedtegebrûk per ferbûn IP-adres. It is tige nuttich om grip te krijen op wat der bart, benammen yn kombinaasje mei logbestannen (dy't it IP-adres oan yndividuele akkounts keppelje).

Ûngewoane oarsaak

De server dy't it tefolle bânbreedtegebrûk produsearre, wie in mailserver. Dy wurde faak troch hackers it doel makke om se yn in spamrelay-server te feroarjen. Dat kin op ferskate wizen barre, meastal troch dat de spammers in jildige oanmelding yn hannen krije. Dat soarget foar in soad útgeand ferkear, want de spammers drukke in soad e-mails út. As der spam op dyn server útstjoerd wurdt, sjochst do dat wierskynlik yn de logs, want spamberjochten komme faak werom, wêrtroch't de mailwachtrijen gau fol rekke. It wurdt gau rommelich, mar op dizze server wie sa'n rommel der net - gewoan in soad ûngewoan bânbreedtegebrûk.

Mail (en spam) wurdt ferstjoerd mei it SMTP-protokol, mar it ferkear op de SMTP-poarte fan dizze server wie hiel normaal. Dat wie tige ûngewoan, want it betsjutte dat it tefolle ferkear fan wat oars kaam. Mar wat? Nei it analysearjen fan ferskate logbestannen op de mailserver stelde ik fêst dat it skuldige protokol IMAP wie. Op ien of oare wize feroarsake in klant dy't mei IMAP ferbûn wie mei de mailserver in ûnbidige hoemannichte netwurkferkear. IMAP is in protokol dat brûkt wurdt om e-mail te lêzen, net om it te ferstjoeren, wêrtroch't anomalyen mei IMAP tige seldsum binne.

Doe't ik it log fan de mailserver analysearre, fûn ik de brûker dy't it ferkear feroarsake. Ik naam kontakt op mei de klant om te freegjen oft er oan syn kant wat raars fernommen hie. Net ferrassend fernaam er dat syn kompjûter de lêste tiid wat traach oanfielde.

Synkronisaasjelus yn Microsoft Outlook

Nei wat besykjen en mislearjen oer de tillefoan stelden wy fêst dat wat feroarsake dat Microsoft Outlook IMAP-mappen yn in lus bleau synkronisearjen. Dêrtroch downloade syn kompjûter de hiele ynhâld fan syn postfek oer en wer! Om't syn postfek mear as 40 gigabyte grut wie, soarge dit foar it flinke ferkear. Blykber wurdt dit feroarsake troch in bug yn Microsoft Outlook, spitigernôch is der gjin maklike oplossing foar.

Fersachtsje troch traffic shaping

Ik stie foar de lestige kar om de (normale, legitime) klant dy't gewoan betellet te blokkearjen of it tefolle ferkear troch te litten gean (wat de netwurkprovider serieuze kosten kostet). Legitime brûkers dy't har bedriuw mei e-mail dogge blokkearje is in tige minne idee, mar it tefolle ferkear trochgean litte is ek min. Gelokkich fûn ik in alternatyf om it tefolle ferkear te ferminderjen wylst de klant noch tagong hie ta syn mail (mei syn betroubere, mar gebrekkige Outlook-app).

Traffic shaping

As technyk foar bânbreedtebehear kinst do traffic shaping brûke om guon (of alle) datapakketten te fertragen om se yn oerienstimming te bringen mei in winske ferkearsprofyl. As men it tapast, jout men - letterlik - foarm oan de ferkearsgrafiken, dêrom de namme.

Dizze technyk is net sûnder diskusje, want it is it tsjinoerstelde fan it faak ferhearlike prinsipe fan "net neutrality". Mei traffic shaping kinst do opsetlik bepaalde soarten ferkear blokkearje of fertrage (of ekstra jild foar freegje). Út prinsipe bin ik tsjin alles wat netneutraliteit skea docht, mar foar dizze bepaalde situaasje hie ik gjin wurkber alternatyf. Ik moast it e-mailferkear foar dizze klant serieus fertrage, de hoemannichte bânbreedte ferminderje wylst er tagong hâlde koe ta syn akkount.

Traffic shaping ynfiere

Om ferkear te foarmjen moatst do twa dingen dwaan:

• ferkear markearje: Do wolst allinnich bepaald netwurkferkear beynfloedzje, yn dit gefal IMAP-tagong foar in bepaalde klant. Oar ferkear moat net rekke wurde. Dit docht men troch pakketten te markearjen dy't oan bepaalde skaaimerken foldogge, lykas it IP fan de klant of poartenûmers
• it foarmbelied hanthavenje: Mei traffic control-ark as 'tc' hanthavenest do dan it foarmbelied op it markearre ferkear. Dêr binne ferskillende wizen foar, mar in gongbere is wurkje mei saneamde "Hierarchy Token Buckets" of HTB's.

Hierarchy Token Buckets (HTB's)

In token bucket is yn prinsipe fergelykber mei it beheinen fan it oantal passazjiers yn in treinrit troch mar in fêst oantal beskikbere tokens út te dielen. As passazjiers (of datapakketten) yn de trein (of it netwurk) stappe, nimme se in token. As se útstappe (of har bestimming berikke), wurdt it token weromjûn. Mei it token bucket-prinsipe kinst do de hoemannichte tagelyk ferkear yn in systeem kontrolearje.

Dit prinsipe kinst do ymplemintearje mei de netwurkark "tc" (foar traffic control) yn kombinaasje mei "iptables". Do kinst in skript brûke om de regels foar markearjen en hanthavenjen yn te stellen. Do kinst online ferskate foarbylden fine, ik brûkte dizze ien fan Julien Vehent.

Konklúzje

Somtiden binne netwurkanomalyen net wat do ferwachtest, dêrom moatst do altyd de tiid nimme om se te ûndersykjen! Ferkear sûnder nei te tinken blokkearje is rûch, soms moatst do dyn metoaden ferfine om problemen te fersachtsjen.

Unortodokse filtertechniken tapasse is net wat ik moai fyn, mar soms binne se it iennige middel ta it doel. Witte wat do dochst en wêrom do it dochst is tige wichtich!