Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Man-in-the-middle op klein bedrijfsnetwerk

Pagina: 1
Acties:

  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
Ik heb te maken met iets dat lijkt op een man-in-the-middle attack op een klein bedrijfsnetwerk. Het netwerk bestaat uit een Cisco Small Business router, type RV130 VPN Firewall (nieuw, kort geleden geplaatst), 2 Debian Wheezy servers en een hoop Windows 7 computers en wat telefoons e.d.

Nu was ik er laatst en zag ik dat 2 computers SSL-waarschuwingen gaven bij bezoek aan Google. Certificaten niet geldig voor Google en soms verlopen. Ik vermoedde dat deze computers wat opgelopen hadden, dus heb ze beiden geformatteerd. Andere systemen leken nergens last van te hebben.

Echter, nu krijg ik te horen dat het weer voorkomt. Dus ik ben naar binnen geVPN'd en samen zijn we gaan testen. Voor een periode kreeg zowel ik (Debian Jessie) als een lokale Windows 7 computer een ongeldig certificaat voor https://www.google.nl:
The certificate is only valid for the following names: rumors.automobilemag.com, www.rumors.automobilemag.com
We hebben toen alle andere Windows PCs (naast dat testsysteem) uitgezet. Het leek toen even goed te gaan, behalve dat we voor https://support.mozilla.org/en-US/questions/749035 opeens een certificaat voor https://bugzilla.mozilla.org kregen.

Ook hebben we traceroutes uitgevoerd. Zowel voordat ik certifiaatwaarschuwingen kreeg als na zag ik daar niets bijzonders aan (identiek). Vanaf het win7 systeem:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
C:\Users\xxx>tracert www.google.nl

Tracing route to www.google.nl [173.194.112.184]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  x.solcon.nl [192.168.1.1]
  2    <1 ms    <1 ms    <1 ms  x.network.solcon.net [x]

  3     1 ms     1 ms     1 ms  rf-wholesale.ars01.ams2.network.solcon.net [212.
45.33.221]
  4     1 ms     1 ms     1 ms  rf-wholesale.ars01.ams2.network.solcon.net [212.
45.33.221]
  5     1 ms     1 ms     1 ms  te1-2.crs1.ams2.network.solcon.net [212.45.45.10
9]
  6     2 ms     2 ms     2 ms  core2.ams.net.google.com [80.249.209.100]
  7     2 ms     3 ms     2 ms  209.85.254.95
  8     3 ms     3 ms     2 ms  209.85.143.77
  9     9 ms    10 ms    10 ms  209.85.246.41
 10    10 ms    10 ms    10 ms  209.85.251.247
 11    10 ms    11 ms     9 ms  72.14.238.57
 12    10 ms    10 ms    10 ms  fra07s32-in-f24.1e100.net [173.194.112.184]

Trace complete.


En vanaf Debian (via VPN, vandaar de 10.9.8.1):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
xxx@xxx-desktop:~$ traceroute google.com
traceroute to google.com (173.194.112.132), 30 hops max, 60 byte packets
 1  10.9.8.1 (10.9.8.1)  29.566 ms  60.896 ms  60.897 ms
 2  x.solcon.nl (192.168.1.1)  60.894 ms  60.889 ms  60.885 ms
 3  x.network.solcon.net (x)  60.880 ms  60.876 ms  60.870 ms
 4  rf-wholesale.ars01.ams2.network.solcon.net (212.45.33.221)  60.866 ms  60.861 ms  60.855 ms
 5  rf-wholesale.ars01.ams2.network.solcon.net (212.45.33.221)  60.851 ms  60.846 ms  92.052 ms
 6  te1-2.crs1.ams2.network.solcon.net (212.45.45.109)  92.052 ms  52.150 ms  32.430 ms
 7  core2.ams.net.google.com (80.249.209.100)  46.224 ms  46.217 ms  46.217 ms
 8  209.85.254.90 (209.85.254.90)  46.220 ms  46.212 ms  46.227 ms
 9  209.85.143.75 (209.85.143.75)  46.204 ms  46.205 ms 209.85.253.249 (209.85.253.249)  46.205 ms
10  209.85.241.229 (209.85.241.229)  46.208 ms  46.209 ms 209.85.240.143 (209.85.240.143)  62.468 ms
11  72.14.234.234 (72.14.234.234)  62.454 ms  93.505 ms 209.85.250.142 (209.85.250.142)  93.500 ms
12  72.14.236.223 (72.14.236.223)  132.408 ms  41.502 ms  154.947 ms
13  fra07s31-in-f4.1e100.net (173.194.112.132)  154.939 ms  154.923 ms  84.882 ms


Ik heb even een paar stukken informatie weggehaald uit privacyoverwegingen uiteraard. Maar daar lijkt niets mis te zijn.

Verder, surfen naar https://192.168.1.1/ (de Cisco router) geeft een certificaat dat wel voor het apparaat is en claimt getekend te zijn door Cisco Systems, Inc., maar is self-signed. Lijkt me ook vreemd voor een dergelijk apparaat.

Mis ik iets? Wat is hier aan de hand? Heb ik een NSA-gemodificeerd apparaat gekregen soms? :X

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Dat cisco apparaat dat heeft meestal een self-signed certificate.

Cisco weet niet van te voren wat jouw domeinnaam gaat zijn (en heeft geen bevoegdheid om zelf certificaten uit te delen voor solcon.nl).

Dus ongeacht wat voor apparaat het is, vanaf fabriek heeft dat ding niets anders dan een self-signed certificate aan boord, jij zal zelf het echte certificaat moeten toekennen.

  • Biersteker
  • Registratie: Juni 2009
  • Laatst online: 29-11 12:57
Als je in cmd arp -a doet, staat dan het goede macaddres bij de router?

Originally, a hacker was someone who makes furniture with an axe.


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 28-11 14:19

CAPSLOCK2000

zie teletekst pagina 888

Dat mozilla certificaat lijkt me onschuldig maar het Google certificaat klinkt als foute boel.
Controleer eens of er geen gekke dingen met DNS gebeuren. Misschien heb je wel last van DNS-cache poisoning. Welke DNS-servers gebruik je? Iets op je eigen netwerk, zoals bv die Cisco? Schakel DNSSEC in als je kan.

[ Voor 5% gewijzigd door CAPSLOCK2000 op 02-02-2015 23:55 ]

This post is warranted for the full amount you paid me for it.


  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
Dank voor de suggesties. De aanval gebeurt sporadisch maar grofweg dagelijks. Hier alvast een ARP table vanaf het win7 systeem wanneer de aanval niet plaatsvindt (en een hoop andere systemen in het gebouw aanstaan want werkuren):

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
C:\Users\xxx>arp -a

Interface: 192.168.1.133 --- 0xb
  Internet Address      Physical Address      Type
  192.168.1.1           3c-ce-73-8e-42-a7     dynamic
  192.168.1.103         00-17-c4-9d-62-c6     dynamic
  192.168.1.105         10-1f-74-f6-8e-53     dynamic
  192.168.1.106         00-80-77-0e-66-70     dynamic
  192.168.1.109         00-25-22-85-fd-f7     dynamic
  192.168.1.120         00-1a-73-5f-43-66     dynamic
  192.168.1.121         00-1b-a9-52-f2-78     dynamic
  192.168.1.122         bc-5f-f4-58-75-79     dynamic
  192.168.1.126         00-25-22-6e-22-6f     dynamic
  192.168.1.127         00-25-22-44-b1-c6     dynamic
  192.168.1.129         00-1b-a9-61-81-7f     dynamic
  192.168.1.135         00-c0-ee-39-96-39     dynamic
  192.168.1.136         00-1e-68-8b-00-2d     dynamic
  192.168.1.137         fc-aa-14-28-3c-fe     dynamic
  192.168.1.141         24-0a-64-02-08-97     dynamic
  192.168.1.255         ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.252           01-00-5e-00-00-fc     static
  224.0.0.253           01-00-5e-00-00-fd     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static

  • GleNnoS_
  • Registratie: Juni 2003
  • Laatst online: 28-11 23:06
Hier een ARP vanaf het win7 systeem wanneer de aanval plaatsvindt:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
C:\Users\xxx>arp -a

Interface: 192.168.1.133 --- 0xb
  Internet Address      Physical Address      Type
  192.168.1.1           3c-ce-73-8e-42-a7     dynamic
  192.168.1.103         00-17-c4-9d-62-c6     dynamic
  192.168.1.105         10-1f-74-f6-8e-53     dynamic
  192.168.1.106         00-80-77-0e-66-70     dynamic
  192.168.1.109         00-25-22-85-fd-f7     dynamic
  192.168.1.120         00-1a-73-5f-43-66     dynamic
  192.168.1.121         00-1b-a9-52-f2-78     dynamic
  192.168.1.122         bc-5f-f4-58-75-79     dynamic
  192.168.1.126         00-25-22-6e-22-6f     dynamic
  192.168.1.127         00-25-22-44-b1-c6     dynamic
  192.168.1.129         00-1b-a9-61-81-7f     dynamic
  192.168.1.135         00-c0-ee-39-96-39     dynamic
  192.168.1.136         00-1e-68-8b-00-2d     dynamic
  192.168.1.137         fc-aa-14-28-3c-fe     dynamic
  192.168.1.141         24-0a-64-02-08-97     dynamic
  192.168.1.255         ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.252           01-00-5e-00-00-fc     static
  224.0.0.253           01-00-5e-00-00-fd     static
  239.255.255.250       01-00-5e-7f-ff-fa     static
  255.255.255.255       ff-ff-ff-ff-ff-ff     static


Dit keer een ander ongeldig certificaat voor http://www.google.nl:
The certificate is only valid for the following names: www.apple.com, ssl.apple.com
Bij het posten hier op GoT kreeg ik de volgende melding van Mozilla Firefox:
Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. Are you sure you want to continue sending this information.
Wanneer google weer ging werken kon ik hier ook zonder die melding posten.

[ Voor 11% gewijzigd door GleNnoS_ op 03-02-2015 14:49 ]


  • Biersteker
  • Registratie: Juni 2009
  • Laatst online: 29-11 12:57
Ervan uitgaande van dit:
192.168.1.1 3c-ce-73-8e-42-a7 dynamic
de router is.

Klopt dan het macaddress ? Dus heb je een mooie sticker met 3c-ce-73-8e-42-a7 op je router?
Zo niet, heb je waarschijnlijk een grappenmaker die een arp poiseningattack opzet. (Zou je trouwens vrij simpel kunnen zien met Wireshark of NetworkMiner) (Krijg je een hoop: 3c-ce-73-8e-42-a7 is know as etc meldingen??)

Originally, a hacker was someone who makes furniture with an axe.


  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
De sticker gecontroleerd; en inderdaad het MAC adres van de router is gewoon 3c-ce-73-8e-42-a7.

@Biersteker: Vermoed dat je bedoelt 192.168.1.1 is known as ... ipv andersom. Dit hebben we getest; en ik zie geen spoor van ARP poisening. Alleen replies op requests, met altijd 3c-ce-73-8e-42-a7 als reply op 192.168.1.1.

Wat me wel opvalt is dat er in vergelijking met andere machines veel ARP verkeer is tussen de win7 testmachine en de router. Beiden kanten op doen ze ARP requests direct naar elkaar, in plaats van broadcast:

code:
1
2
"17904","1627.385649000","Cisco_8e:42:a7","AsustekC_e4:8b:be","ARP","60","Who has 192.168.1.133?  Tell 192.168.1.1"
"17905","1627.385665000","AsustekC_e4:8b:be","Cisco_8e:42:a7","ARP","42","192.168.1.133 is at 00:1b:fc:e4:8b:be"


En andersom:
code:
1
2
"17841","1621.474226000","AsustekC_e4:8b:be","Cisco_8e:42:a7","ARP","42","Who has 192.168.1.1?  Tell 192.168.1.133"
"17842","1621.474417000","Cisco_8e:42:a7","AsustekC_e4:8b:be","ARP","60","192.168.1.1 is at 3c:ce:73:8e:42:a7"


Is hier een reden voor? Als ze de packet al direct aan het goede apparaat richten weten ze het MAC adres dus al. Ik kan me voorstellen dat dit periodiek geupdate wordt (zoals ik ook van andere machines zie), maar tussen deze twee machines komt het abnormaal vaak voor en als enige gericht i.p.v. broadcast.

Ik ga nu maar eens met DNS aan de gang. Iemand tips hoe dit te doen?

[ Voor 3% gewijzigd door geez op 03-02-2015 20:33 ]


  • ShadowAS1
  • Registratie: September 2010
  • Laatst online: 27-11 12:16

ShadowAS1

IT Security Nerd

Wat in jouw laatste post staat ziet er gewoon uit als normaal..
Om even een kijkje buiten jouw netwerk te nemen:
Als je in je Cisco router kijkt, wat zijn dan je 'routes' naar buiten. Is het dezelfde gateway zowel tijdens als buiten de aanval om?
En is het MAC adres van de gateway ook het zelfde?

(Zo simpel als een ARP request op die gateway doen)

Wat ik ook nog zou doen is twee captures maken van traffic, zowel tijdens als buiten je aanval om. En dan gewoon google bezoeken.

Wijkt er iets af? Zo ja: Is het relevant aan wat je zoekt? Kun je echt niets vinden, dan zou ik toch even contact met je ISP opnemen

Edit: Staat er niet toevallig een setting in je Cisco router? Probeer eens tijdelijk een andere router uit, gewoon om het uit te sluiten

[ Voor 10% gewijzigd door ShadowAS1 op 04-02-2015 02:50 ]

PA-ACE / RHCE / SCE // Any post or advice is provided as is, and comes with no warranty at all.


  • josvane
  • Registratie: Oktober 2002
  • Laatst online: 27-11 15:50
Loopt tijd en datum van de PC goed, dat kan ook zorgen voor valse certificaten.

  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
Met route naar buiten vermoed ik dat je bedoelt een traceroute naar een willekeurige site? Er staan boven al wat traceroutes buiten/tijdens de aanval vanaf meerdere systemen. Dit lijkt me hetzelfde? ARP zouden we even moeten testen (is steeds wachten tot het moment van een aanval).

Wireshark laten lopen tijdens de aanval een idee, ik heb al een capture buiten een aanval om, zal vragen of glennos nog één kan maken tijdens.

Heb ook nog eens helemaal door de router gekeken; staat wat mij betreft allemaal normaal ingesteld. Een andere router proberen is wat lastig tijdens de werkweek maar we gaan het proberen..

Datum/tijd van de PCs staat gewoon goed (NTP), en dat zou alleen verlopen certificaten verklaren, niet certificaten voor andere domeinen.

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Kun je nagaan of alles goed gaat met DNS? Kijk met ipconfig /all op de Windows machine welke DNS server gebruikt wordt. Eventueel statisch een DNS server instellen (8.8.8.8).

Mogelijkerwijs heb je een rogue DHCP server in je netwerk welke een foutieve DNS server adverteert? Kijk eventueel hiernaar met Wireshark, filter op "bootp".

Het lijkt erop dat er geen ARP-poisioning wordt toegepast.

Met openssl s_client kun je eventueel ook verder debuggen wat er precies mis gaat met de SSL connectie. OpenSSL zit native in Linux systemen en binaries zijn eventueel voor Windows te downloaden.

  • AK47
  • Registratie: Juli 2001
  • Laatst online: 04-05-2024
Kijk overigens ook nog even naar eventuele rogue IPv6 SLAAC router-advertisements. Heb je geen IPv6 in je netwerk maar je krijgt toch een IPv6 adres toegewezen dan betekend dit foute boel :)

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 28-11 14:19

CAPSLOCK2000

zie teletekst pagina 888

josvane schreef op woensdag 04 februari 2015 @ 13:18:
Loopt tijd en datum van de PC goed, dat kan ook zorgen voor valse certificaten.
Dat kan zorgen voor verlopen certificaten, maar niet voor certificaten met de verkeerde naam.

This post is warranted for the full amount you paid me for it.


  • p.m.
  • Registratie: April 2007
  • Laatst online: 24-11 11:03
misschien op de machines in kwestie hosts-file checken, DNS, maar ook certificates-stores (mmc, add snapin, certificates etc.). Misschien staan daar wat vage dingen tussen, ook bij de trusted root certs. Misschien is er wel een root cert toegevoegd waarmee malafide certificaten aangemaakt zijn.

Verwijderd

Er staat geen ssl contentscanning op ? Dit zou ook voor vage problemen kunnen zorgen.

  • Gillie
  • Registratie: Juni 2002
  • Niet online
Bij een foutief certificaat, wat geeft het certificaat aan? Bijvoorbeeld de geregistreerde? Of naam van het certificaat aan?

Er zijn zogenoemde SSL intercepting proxy servers. Staan de proxy instellingen van de clients goed? Wel/geen proxy?

  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
Excuus voor de wat verlate reactie, ik ben veel weg geweest en omdat het probleem zo sporadisch optreedt is het lastig testen.
AK47 schreef op donderdag 05 februari 2015 @ 19:39:
Kijk overigens ook nog even naar eventuele rogue IPv6 SLAAC router-advertisements. Heb je geen IPv6 in je netwerk maar je krijgt toch een IPv6 adres toegewezen dan betekend dit foute boel :)
Dat is interessant, hier had ik niet over nagedacht. Een ifconfig op één van de servers levert o.a. dit op:
code:
1
2
3
4
5
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:24:21:de:ad:ee  
          inet addr:192.168.1.123  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fec0::224:21ff:fede:adee/64 Scope:Site
          inet6 addr: fe80::224:21ff:fede:adee/64 Scope:Link

Kun je hier iets mee?
p.m. schreef op dinsdag 10 februari 2015 @ 09:49:
misschien op de machines in kwestie hosts-file checken, DNS, maar ook certificates-stores (mmc, add snapin, certificates etc.). Misschien staan daar wat vage dingen tussen, ook bij de trusted root certs. Misschien is er wel een root cert toegevoegd waarmee malafide certificaten aangemaakt zijn.
Zoals ik noemde treedt het probleem ook op op mijn eigen Debian machine die extern staat en volledig onder mijn controle is, zodra ik via VPN verbind. Tevens een nieuw lokaal aangesloten machine ondervindt het probleem. Hosts files en certificate stores zijn dus uitgesloten. Wat betreft DNS; ik heb geverifieerd dat de DNS server voor elk systeem de router op 192.168.1.1 is (zowel Windows als de Linux servers), zoals verwacht. Ik heb dit nog niet kunnen testen tijdens aanval.
Verwijderd schreef op woensdag 11 februari 2015 @ 08:21:
Er staat geen ssl contentscanning op ? Dit zou ook voor vage problemen kunnen zorgen.
Neen. Ik heb de hele router ook langsgelopen.
Gillie schreef op woensdag 11 februari 2015 @ 19:58:
Bij een foutief certificaat, wat geeft het certificaat aan? Bijvoorbeeld de geregistreerde? Of naam van het certificaat aan?

Er zijn zogenoemde SSL intercepting proxy servers. Staan de proxy instellingen van de clients goed? Wel/geen proxy?
In alle gevallen die ik gezien heb is het domein verkeerd, als in het certificaat is bedoeld voor een compleet ander domein. Verder missen nagenoeg alle velden zoals de issuer. In een paar gevallen was het certificaat ook verlopen. Er staan geen proxies ingesteld op de systemen, en zeker niet op mijn eigen Debian systeem (waarmee ik via OpenVPN met het netwerk verbindt en het probleem ook ondervindt).

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 28-11 14:19

CAPSLOCK2000

zie teletekst pagina 888

geez schreef op dinsdag 10 maart 2015 @ 10:34:

Dat is interessant, hier had ik niet over nagedacht. Een ifconfig op één van de servers levert o.a. dit op:
code:
1
2
3
4
5
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:24:21:de:ad:ee  
          inet addr:192.168.1.123  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fec0::224:21ff:fede:adee/64 Scope:Site
          inet6 addr: fe80::224:21ff:fede:adee/64 Scope:Link
fe80 is normaal. fec0 niet. Als de netwerkbeheerder dat niet heeft ingesteld is het op z'n minst vreemd te noemen. In dat geval worden er waarschijnlijk valse RA's verstuurd. Probeer te achterhalen wie dat doet. Controleer je route tabel en je neighbour tabel met 'ip -6 route show' en 'ip -6 neigh show'
zijn dus uitgesloten. Wat betreft DNS; ik heb geverifieerd dat de DNS server voor elk systeem de router op 192.168.1.1 is (zowel Windows als de Linux servers), zoals verwacht. Ik heb dit nog niet kunnen testen tijdens aanval.
Ik ga er niet van uit dat dit op je clients veranderd. Wel kan het verkeer voor dat ip worden onderschept. Zie wederom de routetabel en neighbourtable, deze keer voor IPv4.

Vertrouw niet te veel op de DNS-server in die route. Die zijn vaak erg makkelijk te vergiftigen met foute informatie. Vergelijk de adressen die je tijdens een storing ontvangt van DNS met een andere bron. Het liefst een onafhankelijk netwerk, bv via je de 3G verbinding van je telefoon (en dus niet via WIFI). Kijk ook naar de IPv6-adressen want daar zou het probleem wel eens kunnen zitten.

Nog beter, installeer een resolver met DNSSEC-support. Unbound is mijn favoriet. Dat voorkomt DNS problemen niet helemaal maar het geeft je in ieder geval een mogelijkheid om het te detecteren. Helaas moeten de domeinen dat wel ondersteunen. Bij .nl domeinen heb je daar een goede kans op, elders niet.

This post is warranted for the full amount you paid me for it.


  • geez
  • Registratie: Juni 2002
  • Laatst online: 25-10 16:40
Ik heb voor de zekerheid even in de router de ipv6 instellingen gecontroleerd; Het ipv6 adres voor de router staat ingesteld als FEC0:0000:0000:0000:0000:0000:0000:0001, maar de dhcp server voor ipv6 staat gewoon uit. Onder Router Advertisement staat wel RADVD aan (http://www.litech.org/radvd/) op unsolicited multicast mode. Zou dit iets doen als de ipv6 dhcp uitstaat? Is het nuttig om met wireshark ipv6 RAs te gaan capturen?

Verder leveren 'ip -6 route show' en 'ip -6 neigh show' dit op:
code:
1
2
3
4
5
# ip -6 route show
fe80::/64 dev eth0  proto kernel  metric 256 
fec0::/64 dev eth0  proto kernel  metric 256  expires 2592156sec
# ip -6 neigh show
fe80::3ece:73ff:fe8e:42a7 dev eth0 lladdr 3c:ce:73:8e:42:a7 router STALE

Waarbij het ipv6 adres onder neigh gelijk is aan wat ik onder system summary van de Cisco als ipv6 LAN adres zie staan:
code:
1
2
LAN IP: fec0::1/64, fe80::3ece:73ff:fe8e:42a7/64
WAN IP: fe80::3ece:73ff:fe8e:42a8/64


Ik zal proberen de routing- en neighbourtables voor ipv4 en ipv6 proberen te controleren zodra de aanval weer plaatsvindt, en het resultaat posten. Als je zegt "Wel kan het verkeer voor dat ip worden onderschept.", dan neem ik aan dat je een ARP cache poisoning aanval bedoelt? Dat is wel gecontroleerd namelijk. Ontvangen DNS records ga ik ook controleren.

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 28-11 14:19

CAPSLOCK2000

zie teletekst pagina 888

geez schreef op woensdag 11 maart 2015 @ 08:10:
Ik heb voor de zekerheid even in de router de ipv6 instellingen gecontroleerd; Het ipv6 adres voor de router staat ingesteld als FEC0:0000:0000:0000:0000:0000:0000:0001, maar de dhcp server voor ipv6 staat gewoon uit. Onder Router Advertisement staat wel RADVD aan (http://www.litech.org/radvd/) op unsolicited multicast mode. Zou dit iets doen als de ipv6 dhcp uitstaat? Is het nuttig om met wireshark ipv6 RAs te gaan capturen?
Dan zitten we blijkbaar op het verkeerde pad en is het blijkbaar de bedoeling dat IPv6 aan staat. RADVD werkt inderdaad ook als DHCPv6 uit staat. Die twee kunnen onafhankelijk van elkaar werken.
Ik zal proberen de routing- en neighbourtables voor ipv4 en ipv6 proberen te controleren zodra de aanval weer plaatsvindt, en het resultaat posten. Als je zegt "Wel kan het verkeer voor dat ip worden onderschept.", dan neem ik aan dat je een ARP cache poisoning aanval bedoelt? Dat is wel gecontroleerd namelijk. Ontvangen DNS records ga ik ook controleren.
Dat is ongeveer wat ik bedoelde maar er zijn nog andere mogelijkheden. Als dat mogelijk is zou je ook kunnen controleren of (al) het verkeer ook op de router aankomt. Het is ook mogelijk dat iemand je mac-adres heeft gekloond. Eerlijk gezegd vind ik dat redelijk onwaarschijnlijk maar als je echt alles wil uitsluiten moet je met een sniffer ook aan de kant van de router controleren.

Doe de volgende keer dat je onder aanvalt bent ook wat DNS-queries, dat is wat mijn onderbuik zegt.

This post is warranted for the full amount you paid me for it.


Verwijderd

heb je ook een mogelijkheid om de poorten op de switch(es) te loggen betreft up/down? mss propt iemand er ergens een hub tussen.

  • Kabouterplop01
  • Registratie: Maart 2002
  • Laatst online: 29-11 11:14

Kabouterplop01

chown -R me base:all

speelt het probleem nog wel?
Pagina: 1