[Denial of Service] UDP flood door Remote Desktop

[One_Gandalf]

Situatie-schets :

• Maken van een VPN-verbinding met mijn CISCO-client
• Extern bureaublad (remote desktop) naar de PC op mijn werk

OS op het werk : Windows 7 Enterprise
OS thuis : Windows 7 Home Premium
Router thuis : Draytek Vigor2920 (dus geen toevoegingen) Dual-WAN

Ik heb ontdekt dat de verbinding via remote desktop wordt verbroken als ik in mijn router thuis de controle op een UDP flood aanzet. Zet ik die controle uit in mijn router dan kan ik werken op mijn remote desktop. Als ik de standaard-drempel van 150 UDP-packets per seconde instel dan wordt de verbinding met de remote desktop verbroken; de VPN-verbinding is dan gewoon nog actief en ik kan pingen.

Mijn vraag is nu hoe ik kan bepalen hoeveel UDP-packets er per seconde binnen komen wanneer ik remote desktop opstart. Ik heb de volgende software geïnstalleerd: syslog van Draytek en WireShark.

Gaarne geen advies om de controle uit te zetten. Ik wil graag weten op welke drempel-waarde ik de controle kan handhaven en tegelijkertijd goed kan blijven werken met remote desktop.

[ChaserBoZ_]

Wireshark starten, RDP sessie starten, Wireshark stoppen en tellen

Via statistics kun je dit soort dingen inzien. Anders even googlen op 'wireshark count udp bladiebladiebla'

[Kabouterplop01]

Is die UDP "flood" van je VPN of van je RDP sessie? Misschien moet je even in de specs van zo'n VPN protocol kijken en dan tellen.
RDP is nl TCP/3389, dus wel frappant dat je VPN dan toch actief blijft.

[ Voor 15% gewijzigd door Kabouterplop01 op 09-06-2012 21:57 ]

[One_Gandalf]

ChaserBoZ_ schreef op zaterdag 09 juni 2012 @ 17:32:
Wireshark starten, RDP sessie starten, Wireshark stoppen en tellen

Via statistics kun je dit soort dingen inzien. Anders even googlen op 'wireshark count udp bladiebladiebla'

Kabouterplop01 schreef op zaterdag 09 juni 2012 @ 21:55:
Is die UDP "flood" van je VPN of van je RDP sessie? Misschien moet je even in de specs van zo'n VPN protocol kijken en dan tellen.
RDP is nl TCP/3389, dus wel frappant dat je VPN dan toch actief blijft.

Ik ben een newbie met wireshark dus het is even puzzelen. Ik zie twee verbindingen : mijn normale netwerkverbinding en de VPN-verbinding. Ik neem aan dat ik een capture moet doen voor de VPN-verbinding. Als ik de packets bekijk na ongeveer een minuut dan heb ik nog moeite met het bepalen van het aantal packets per seconde.

Ik heb ook gegoogled op het tellen van UDP-packets per seconde maar kon hier niet iets vinden waar ik iets mee kon; buiten het handmatig tellen van packets.

Voor zover ik weet is mijn VPN-verbinding ingesteld op het UDP-protocol er staat in de CISCO-client onder het kopje 'Transport' IPSec/UDP. Mogelijk gebruikt de VPN-verbinding twee protocollen? Ik weet nog niet wat welk(e) protocol(len) precies gebruikt.

Update 12:39 uur

Ik heb een capturefile gemaakt vanaf het maken van een VPN-verbinding tot en met het beëindigen van een RDP-sessie. De capture-file heeft betrekking op de VPN-verbinding.

Wat me opvalt is dat ik onder het kopje Protocol vaak TCP en TPKT zie staan, maar geen enkele keer UDP.

Ik heb alle packets geteld waarvoor de tijd begint met 11:47:32. Dit waren 1125 packets. Voor zover ik heb gezien was dit ongeveer de drukste seconde. Echter ik denk dat ik hierbinnen nog moet filteren op de source (namelijk het IP-adres van de PC op mijn werk). Als ik sorteer op source dan wordt het tellen lastig omdat de teller onder de kolom 'No.' niet aangepast wordt na het sorteren waardoor de teller niet meer aansluit.

Ga ik grosso mode uit van de helft heen en de helft terug dan kom ik al op 562 packets. Bijna alle packets hebben als source het IP-adres van de PC op mijn werk. Dus er komen ongeveer 1125 packets binnen in die seconde. Op mijn router heb ik de drempel voor de UDP-flood ingesteld op 800 packets per seconde (wat ik niet voor elkaar krijg is dat de router een e-mail stuurt als er een drempel wordt overschreden maar dat is een ander punt lijkt me).

Waarom zie ik de protocollen TCP en TPKT en hoe kan ik de inkomende packets het beste tellen?

Ik heb net een wiki-pagina betreffende RDP gevonden : http://wiki.wireshark.org/RDP

[ Voor 76% gewijzigd door One_Gandalf op 10-06-2012 12:42 ]

[Zoetjuh]

Als het gaat om een IPSec over UDP. Ik meen dat dit voor de 'oude' Cisco VPN-client ook de default setting is; daar staat meen ik: IPSec over UDP (NAT/PAT); en dan klinkt het vrij logisch.

Wanneer je via VPN verbonden bent, maar er gaan weinig verkeer over je VPN-connectie, dan lopen er dus ook weinig UDP-pakketjes door je router.
Zodra je er meer verkeer over gooit (bijv, door flink te Remote Desktoppen), dan nemen de hoeveelheid UDP-pakketjes ook toe.

Zelf gebruik ik een ASA icm met de Cisco AnyConnect client en maak ik een SSL VPN-verbinding; ofwel, over HTTPS (TCP/443), dan hebben routers/firewall een stuk minder door

[Olaf van der Spek]

One_Gandalf schreef op zaterdag 09 juni 2012 @ 10:49:
Gaarne geen afvies om de controle uit te zetten. Ik wil graag weten op welke drempel-waarde ik de controle kan handhaven en tegelijkertijd goed kan blijven werken met remote desktop.

Waarom niet? Die controle is toch sowieso nutteloos?

[One_Gandalf]

Zoetjuh schreef op zondag 10 juni 2012 @ 11:36:
Zelf gebruik ik een ASA icm met de Cisco AnyConnect client en maak ik een SSL VPN-verbinding; ofwel, over HTTPS (TCP/443), dan hebben routers/firewall een stuk minder door

Het type verbinding heb ik zelf niet in de hand dat wordt bepaald door de 'technische afdeling' van mijn bedrijf. Maar het klinkt wel slim wat je zegt. Ik neem dan voor het gemak aan dat ik als client niet zelf het protocol kan bepalen.

Olaf van der Spek schreef op maandag 11 juni 2012 @ 00:21:
[...]

Waarom niet? Die controle is toch sowieso nutteloos?

Waarom is die controle nutteloos? Ik neem aan dat de optie om je te verdedigen tegen een denial of service aanval niet voor niets aanwezig is op mijn router.

[ Voor 43% gewijzigd door One_Gandalf op 17-06-2012 10:43 ]

[Olaf van der Spek]

One_Gandalf schreef op zondag 17 juni 2012 @ 10:40:
Waarom is die controle nutteloos? Ik neem aan dat de optie om je te verdedigen tegen een denial of service aanval niet voor niets aanwezig is op mijn router.

Klopt, het is weer een vinkje extra in de features lijst. Tegen een (goede) denial of service attack valt nauwelijks te verdedigen.

[ Voor 10% gewijzigd door Olaf van der Spek op 17-06-2012 21:10 ]

[Zoetjuh]

One_Gandalf schreef op zondag 17 juni 2012 @ 10:40:
Het type verbinding heb ik zelf niet in de hand dat wordt bepaald door de 'technische afdeling' van mijn bedrijf. Maar het klinkt wel slim wat je zegt. Ik neem dan voor het gemak aan dat ik als client niet zelf het protocol kan bepalen.

Helaas.. dat is inderdaad zoals de technische afdeling het heeft ingericht. Wie weet hebben ze het toevallig wel ingesteld; wie weet.

[alt-92]

One_Gandalf schreef op zondag 17 juni 2012 @ 10:40:

Waarom is die controle nutteloos? Ik neem aan dat de optie om je te verdedigen tegen een denial of service aanval niet voor niets aanwezig is op mijn router.

Het (on)nut van die 'beveiliging' blijkt al uit het feit dat je Cisco VPN client die limiet volgooit waardoor je niet kan werken.
Et voilá: een Denial of Service.