1
Vraag
2
Reacties
rb10

Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

Bridge mode en DDOS

Ik heb de modem in bridge mode staan met daarachter een eigen firewall. Ik heb een paar port forwards staan naar interne servers waaronder een RDP port op een alternatieve poort (1988). Natuurlijk hebben ze (de hackers) met een portscan deze service gevonden, en zie ik van 6 wisselende IP adressen connects & login attempts naar de rdp server. Ik heb in mijn firewall aangegeven dat een IP adres maar 2 keer mag proberen en daarna wordt dat IP adres geblokt voor een kwartier. Je zou verwachten dat de connect (syn pakket) van de hacker dan geen antwoord krijgt, dus die zal dat verzoek timeout-en en dan hoop ik dat de hackers iemand anders gaan vervelen. Wat blijkt nu, dat als ik (als firewall geen antwoord geef op de SYN van poort 1988, dan gaat de bridge antwoord (met het mac adres van mijn firewall) geven met een RST pakketje, waardoor de hackers direct daarna een volgende poging kunnen doen.

dit lijkt mij een firmware probleempje in de bridge code...

Oplossing

Geaccepteerde oplossingen
rb10
Topicstarter
Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

Problem solved… het ligt aan mijn firewall die wel drop regels had voor intern naar publiek en omgekeerd, maar niet voor inbound op de wan port naar local, waardoor de FW zelf ging reageren. Doordat een van de hackers een ip adres dat heel dicht bij het ziggo adres lag heb ik zijn pakketje gezien als het ziggo modem pakketje. sorry voor het verspillen van jullie tijd, maar wel bedankt voor de hulp.

Bekijk in context

13 Reacties 13
efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

Hmm. Welk modem heb je en hoe heb je vastgesteld dat het modem een RST geeft? Weet je zeker dat je Firewall op “Drop” staat en niet op “Deny”?

Je zegt dat het pakketje van het MAC adres van je firewall komt.

rb10
Topicstarter
Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

Hoi efok, ik heb de witte connectbox en aan die modem hangt dan mijn VMware infra zodoende kan ik met een van de vm’s die modem kabel capturen. de firewall is ook een vm en daar heb ik drop regels staan. Als je de modem opstart (power off/on) en dan monitor, dan zie ik een paar arps langs komen  (wat te verwachten is). Als de firewall dan een dhcp verzoek doet, dan leert de bridge het mac adres. dan zie ik de hackers connecteren. (alles zoals het hoort network wise). Omdat de RST’s van mijn FW mac adres zijn is het moeilijk te bepalen wie het pakketje stuurt. Als ik dan de fw uitzet of afkoppel, dan gaat het RST reply “feest” gewoon door. Het lijkt alsof de bridge bij de eerste connect controleert of er een responder op de LAN kabel zit (mijn firewall). reageert die niet, dan stuurt de moden RST… handig voor snelle discovery van services, maar niet zo gewenst bij DDOS

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

@rb10  Flinke setup Even nadenken, ik vat hem nog niet helemaal:

Je captured dus pakketten met een vm, achter je modem. Een van je VMs is je Firewall, dus die pakt het externe WAN IP, right?
Als je die FW afkoppelt, dan monitort een andere VM nog steeds pakketjes vanaf je modem, ook al is je interface met WAN IP plat? Begrijp ik dat goed?

Kun je iets laten zien van waar/hoe en wat je afvangt?

 

(Er is wel eens eerder geconstateerd dat de bridge modus van de connectbox niet helemaal transparant is, dus ik kijk nergens van op, dus dit vind ik wel weer boeiend)

 

rb10
Topicstarter
Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

mijn ziggo netwerk voer ik als een vlan naar de esx server en komt daar als een trunk met meerdere vlans op de vswitch die ik in “promisqious mode=accept” heb staan. dat betekent dat alle pakketjes die op het vlan gestuurd worden naar alle vm’s die op dat vlan zitten. (in mijn geval dus de capture vm en de FW vm). Normaal zou esx de pakketjes filteren voor de vm die het dest mac adres heeft. de capture vm is een win10 host met IPv4 en ipv6 uitgeschakeld (zodat hij geen pakketjes met zijn mac adres kan versturen, met daarop wireshark. Omdat de pakketjes het mac adres van de FW hebben verwacht je dat het antwoorden zijn van mijn eigen FW, maar als ik die afkoppel van het VLAN (dus hij kan niks meer horen of zien), dan zie ik nog steeds RST pakketjes.. en dat kan niet anders dan de bridge zijn.

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

Okee. Dus als je firewall dropt (in geval van meerdere connectie pogingen) of offline is zeg jij dat je dan toch RST pakketjes ziet op je Wireshark met het MAC van je Firewall.
Het is wel zo dat mijn gebridgde Ziggo modem (=geen connectbox) maar 1 keer een WAN IP uitdeelt aan een aangesloten apparaat. Koppel ik iets anders, dan moet ik het modem resetten, wan tanders krijgt dat apparaat geen IP. Bridge modus doet dus wel iets met het gekoppelde MAC adres. Waarschijnlijk is dat voor mijn modem en jouw Connectbox niet helemaal vergelijkbaar.

Gezien je setup lijk je gelijk te hebben, maar dat vind ik ook echt heel merkwaardig.
 

hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes

Ik vind dit nogal ingewikkeld. Waarlijk een bijzondere setup.
De kwestie is m.i of dat RST Packet (waar niks mis mee is) het Modem verlaat ie via TCP/IP het internet op gaat.
Als dat niet zo is, dan kan de hacker dat niet zien, vlgs mij. Als niet hacker, dat moet ik toegeven.

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes
hanh wrote:

Ik vind dit nogal ingewikkeld. Waarlijk een bijzondere setup.
De kwestie is m.i of dat RST Packet (waar niks mis mee is) het Modem verlaat ie via TCP/IP het internet op gaat.
Als dat niet zo is, dan kan de hacker dat niet zien, vlgs mij. Als niet hacker, dat moet ik toegeven.

Goed punt denk ik. Voor TCP/IP heb je een verzendend IP adres nodig. Hoe zit dat hier?

hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes

Inderdaad, dat bedoel ik. Mac address transmission zit een andere Layer dan IP transmission. Om maar eens deftig te doen. Interne MAC only transmission, zoals ARP en RST, gaat niet naar buiten. Dat ziet niemand van buitenaf. Zoiets dus.

rb10
Topicstarter
Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

Ik heb het over een tcp packet waarvan het src IP adres mijn publieke adres is en op ethernet niveau het mac adres van mijn FW. Met SYN of RST bedoel ik de flags in het optie veld van de TCP header. De hacker stuurt een SYN (immers hij wil connectie met mij), en dat stuur ik in het normale geval een ACK. Heeft een host geen listening process op die gevraagde port, dan stuurt de host een tcp pakketje met de RST vlag aan. heb je er een firewall ertussen, en de firewall is in drop mode voor deze port, dan zal de firewall niet antwoorden en dus zal de hacker tegen een connect timeout aanlopen. (normaal 30sec). Maar doordat de bridge antwoord geeft naar de hacker, wordt zijn connect direct gecanceld, en kan hij de volgende poging doen (dus na 1 round trip delay komt de volgende poging. Als de modem niet zou reageren, dan zou de hacker maar eens in de 30 sec connecteren… (er vanuit gaan dat hij een standard TCP stack gebruikt).

 

Het is misschien een bijzondere setup, maar het zorgt er wel voor dat ik kan zien wat op alle wan/LAN verbindingen kan monitoren. Het alternatief zou zijn een switch met een mirror port die tussen de FW en de modem te hangen en dan op die mirror port te capturen.

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

@rb10 Ik weet hoe TCP/IP connecties werken, en wat er zou moeten gebeuren als je firewall een pakket dropt. Ik begrijp jouw geval echter niet helemaal. Een RST pakket komt uit de TCP laag. Zoals jij het beschrijft: een RST vanaf alleen MAC adres (zonder IP adres?), ik vraag me af of dat wel kan kloppen? Heb je een stukje wireshark-capture?
En hoe zit het met de rest van je poorten? Ik bedoel je zult het meeste niet gewenste verkeer op andere poorten by default droppen. Komt op al die poorten dan ook een RST terug?

rb10
Topicstarter
Level 1
  • 5Posts
  • 1Oplossingen
  • 0Likes

Problem solved… het ligt aan mijn firewall die wel drop regels had voor intern naar publiek en omgekeerd, maar niet voor inbound op de wan port naar local, waardoor de FW zelf ging reageren. Doordat een van de hackers een ip adres dat heel dicht bij het ziggo adres lag heb ik zijn pakketje gezien als het ziggo modem pakketje. sorry voor het verspillen van jullie tijd, maar wel bedankt voor de hulp.

hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes

Nee, niks sorry! Ik vond het wel interessant en lastig.
Anders had ik me er niet mee bemoeid. Ik denk efok idem.
Ik vind zoiets de moeite waard, als er inzicht in een oplossing komt. En anders ook wel, maar iets minder.

------------------------------------------------------------------------------------

Anekdote. Vroeger was ik betrokken bij software ontwikkeling.
Als er een probleem is, dan doe je samen met de ontwikkelaar aan code reviewing.
Deze oude rot raakte door onoplettendheid het spoor soms snel bijster. Opeens zei de ontwikkelaar dan: bedankt, ik heb het gevonden! Je loopt dan beduust weg en vraagt je af: ben ik, behalve als praatpaal, nog ergens anders goed voor?

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes
rb10 wrote:

Problem solved… het ligt aan mijn firewall die wel drop regels had voor intern naar publiek en omgekeerd, maar niet voor inbound op de wan port naar local, waardoor de FW zelf ging reageren. Doordat een van de hackers een ip adres dat heel dicht bij het ziggo adres lag heb ik zijn pakketje gezien als het ziggo modem pakketje. sorry voor het verspillen van jullie tijd, maar wel bedankt voor de hulp.


Kiek dan, mystery solved .

E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic