Of weer allerlei IoT besmet met een nieuwe mirai-in-ontwikkeling?
Want mirai "schreeuwt" wel om belangstelling tegenwoordig, en is in staat om het m.b.v. GRE te doen.
https://cyberx-labs.com/en/blog/cyberx-reveals-gre-evidence-krebs-iot-based-attack-largest-ddos-internet-ever-seen/

Je weet het heus zelf wel, getuige de laatste zin van je betoog.
De Taiwanese hacker basis is geduchter dan de Chinese equivalent, vergis je niet.

Het wordt het Chinese jaar van de Haan, een jaar van diep denkende hackers!

Monocultuur op de infrastructuur voornamelijk, dat wel, maar niet wrak of brak
en ....... zeer geslepen in de eenvoud van opzet. Sterke IoT Kung-Fu!

Gericht op onbeheerde DNS exploiteerbare servers voor DNS reflectie aanvallen.
GRE laat twee peers data delen.

Dit zijn IoT gebaseerde botnet aanvallen, als Lizekebab, BASHLITE, "torlus" etc.
en dus voor zwaar ddos werk bedoeld.

IoT net als BigData aanval worden nog een dreiging, waar we voorlopig niet van af zijn.

Hard aanpezen wordt het vooral voor de technici bij Akamai
en cdn consorten om de aanvallen te kunnen migreren.

Brian Kreb's website was al eerder slachtoffer van een dergelijke aanval....

Groetjes, nog bedankt voor je bericht & een fijn uiteinde & goed begin gewenst.

Ik vemoed Mirai, zie bijv. https://f5.com/about-us/news/articles/mirai-the-iot-bot-that-took-down-krebs-and-launched-a-tbps-ddos-attack-on-ovh-21937 (bron, Google: gre random udp)

Advies: meld dit op https://isc.sans.edu/contact.html, bij voorkeur met pakketjes, daar zitten mensen (o.a. docenten) die dol zijn op dit soort dingen. Als het een nieuw fenomeen is, is de kans groot dat er vervolgens een "diary entry" (dagboek pagina) van wordt gemaakt (vaak met een "got packets"? vraag aan anderen).

Hou je ons op de hoogte?

Een adres boven de 240.0.0.0 is een multicast adres... het zou ook onschuldige audio of video kunnen zijn naar een dood(?) tunneleindpunt.

Neen dat is het niet. Multicast is 224.0.0.0-239.255.255.255

Ik hoef geen dissertatie over Taiwanese routers, ik wil graag weten waarom er ineens GRE pakketjes gestuurd worden
en ik vraag me af waarom er geen doelgerichte content is. Ik kan me goed voorstellen dat als er een bug in een router
zit waardoor hij ieder GRE pakketje accepteert en uitpakt en het resultaat forward alsof het een LAN pakket is, je hier
mee "leuke" dingen zou kunnen doen. Maar dan verwacht je dat de content bijvoorbeeld een DNS lookup of SNMP
query is, maar dat is het dus niet, het is gewoon random.
En de frekwentie is niet zodanig dat die random rommel al een attack is.

Mijn eerste reactie is: zie je ook tcp/1723, want dan zou een pptp tunnel aan de orde zijn?

Dus, wat zie je nog meer dan de gre pakketten?

Misschien is die er wel, maar valt deze niet op door alle random rommel (mogelijk bedoeld om jou op dit dwaalspoor te zetten)?

"Restrict GRE to only service SPP" beschermt met FortiDDos -> https://blog.fortinet.com/2016/10/24/mirai-botnet-protect-your-infrastructure-with-fortiddos

Debuggen van het GRE protocol door NAT heen is een groot drama. Laat je router het überhaupt door?

Nog wat opfrist over GRE IP Sec VPN configuraties ->: http://www.techexams.net/forums/ccnp/48692-gre-ipsec-vpn-acl-question.html

De GRE tunnel dient eerst opgezet te worden en dan wordt ipsec gebruikt om de content van de tunnel te encrypten.
Ik vermoed toch dat we bij het voorbeeld dat je meldt te maken hebben met VP tunnel manipulatie.
Iemand hier met meer relevant inzicht aangaande VPN vanaf een Windows Client?

https://en.wikipedia.org/wiki/Multicast_address#AD-HOC_block

Denk aan routers die frituurpannen en rijstkokers doorlaten met IoT.

Nog een keer lezen dus. Ik zei "boven de 240.0.0.0". Geen Multicast dus, ook geen AD-HOC.

Er komt niet heel veel binnen, het is een steady stroompje van misschien 20 packets per uur op een systeem wat
luistert op een stuk of 30 adressen. Maar het valt op omdat dit systeem ook GRE doet op die adressen, de peer
adressen in een firewall adreslijst staan, GRE verkeer buiten die lijst gelogd wordt, en sinds een paar dagen komt
daar ineens regelmatig verkeer in terwijl dat voorheen nooit zo was. Ik ben toen gaan kijken wat voor verkeer dit is
omdat het meestal fouten van de legitieme gebruikers zijn, bijvoorbeeld hun adres is veranderd terwijl ze dat (nog)
niet doorgegeven hebben. Tot nu toe zag ik misschien 1-2 verdwaalde GRE pakketjes per week en keek ik even
waar ze vandaan kwamen, is het een "research" systeem of iets ala shodan.io dan gaat ie in de permanente blocklist
op IP adres en is het een kabelmodempje ofzo dan laat ik het maar zo.
Maar nu is er dus ineens een piek. Dwz we weten nog niet of het een piek is, misschien is het gewoon het nieuwe
ruisnivo. Zoals dat op wel meer plekken het geval is (telnet, ssh, replies op spoofed requests, etc)

Omdat ik me wel realiseer dat je met tunneling protocollen, waaronder GRE ook valt, soms firewalls die niet
helemaal goed zijn zou kunnen misleiden ben ik dat nader gaan onderzoeken. Maar dat levert dus (nog) niet
veel op.

Hier een voorbeeld, dat is afkomstig van 220.128.119.155 dus weer zo'n adres bij de Taiwanese provider HINET.
De GRE inhoud daarvan is:

Generic Routing Encapsulation (IP)
Flags and Version: 0x0000
0... .... .... .... = Checksum Bit: No
.0.. .... .... .... = Routing Bit: No
..0. .... .... .... = Key Bit: No
...0 .... .... .... = Sequence Number Bit: No
.... 0... .... .... = Strict Source Route Bit: No
.... .000 .... .... = Recursion control: 0
.... .... 0000 0... = Flags (Reserved): 0
.... .... .... .000 = Version: GRE (0)
Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 45.131.239.48 (45.131.239.48), Dst: 197.70.74.239 (197.70.74.239)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 28
Identification: 0xa567 (42343)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Source: 45.131.239.48 (45.131.239.48)
Destination: 197.70.74.239 (197.70.74.239)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 41650 (41650), Dst Port: 23243 (23243)
Source Port: 41650 (41650)
Destination Port: 23243 (23243)
Length: 8

In dit geval zijn de adressen in de payload wel geloofwaardig, maar ik heb daar dus in andere gevallen ook dingen
als 246.123.213.122 in zien staan. Dat geeft me het idee dat het random rommel is. Ook bij de UDP poort nummers
komen niet regelmatig de usual suspects zoals 53 123 161 enzo voor.
Ik vraag me af wat het voor zin heeft om dit soort GRE pakketjes naar allerlei adressen op internet te sturen, en hoe
het komt dat het grootste deel uit Taiwan komt. Tweede en derde zijn overigens Israel en Brazilie.

Er is nu een item over in https://isc.sans.edu/forums/diary/Increase+in+Protocol+47+denys/21865/.

Wat je (Anoniem vandaag 18:04) beschrijft lijkt inderdaad nergens zinvol voor, maar in zo'n situatie vallen na enkele weken de puzzelstukjes vaak op hun plaats. Ervaringen delen met anderen die (ongeveer) hetzelfde zien, leidt meestal tot nieuwe inzichten.

Laten we eens een speculatie wagen en kijken in hoeverre dit overeenkomt met wat er zich afspeelde?

- De aanvallen lijken gericht tegen Wimax clients op cross web server en een recent gevonden kwetsbaarheid in 70 CCTV DVR terug te herleiden naar een Chinese firma, die niet reageerde op de melding van de vulnerability.

Service Info: Device: media device - In het voorbeeld kwam een de cross-dvr aanvallen uit Tel Aviv en richtte tegen -wimax-client.yota.rui n Moskou.

Daniel Cid van Sucuri's beschrijft het hier (zie link) en 24% van de aanvallen stammen uit Taiwan en 12% uit de V.S.
-> https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-ddos-attacks.html

Daarom kom ik er hier ook mee, ik heb er zelf niet echt last van (nouja even dan maar dat is zo weer weggefilterd)
maar ik dacht wieweet is het anderen ook opgevallen.
Kennelijk wel, inderdaad. Maar die URL werkt hier niet, error 502 bad gateway. Daar had ik graag wilen kijken.

O wacht die isc.sans.edu was kennelijk tijdelijk plat maar nu niet meer, en mijn waarneming klopt exact met
wat die Rick en Anonymous daar schrijven, inclusief die rare >240.0.0.0 IP adressen (zie je wel!!).
Maar bij mij is dat dus niet bij alle gevallen zo, er komen ook geldige adressen voor en die vormen zelfs de
meerderheid, het lijkt er op dat het adres gewoon een random getal is en dus 1/15 van de adressen >240 is.
En het moment dat dit ineens begon terwijl het daarvoor nooit zo was.

Dat is dan wat anders want dit komt voor 80% uit Taiwan en de rest verdeelt zich over een paar andere landen.
Hoewel het gaandeweg steeds meer divers wordt.
De theorie dat het uit een router komt die door de Taiwanese ISP HINET gebruikt wordt en ook door ISP's in
Israel, Brazilie e.d. lijkt me aannemelijk.
Alleen, als je het een "aanval" wilt noemen dan zou ik wel willen zien wat er nou precies de aanval aan is.
Er is verkeer, maar het is nogan onspecifiek. Dat is soms het geval als het DDoS is maar daarvoor is het volume
te laag. Dus wat is het dan?

Gaat het om aanvallen op camera's of een camera botnet?

Op het Taiwanese adres draait:
22/tcp open ssh?
80/tcp open http Cross DVR httpd
|_http-title: DVR Components Download
Service Info: Device: media device

Hier nog wat meer info over een (andere) cross dvr aanval:
http://www.kerneronsec.com/2016/02/remote-code-execution-in-cctv-dvrs-of.html

123 IP adressen die zich bezighouden met divers misbruik vanuit (maar ook op/via)
dit Taiwanese autonome systeem, zie: http://sitevet.com/db/asn/AS3462

Maar de moeilijke analyse kan ook vanwege diverse "clutter"zijn,
mede omdat het debuggen van GRE verkeer om diverse redenen zo'n opgave is.
Dat blijkt wel in dit geval.

Het zou interessant zijn om het random generator algoritme te kennen,
dan kan het beoogde aanvalsdoel de dreiging ook voor de toekomst beter mitigeren.
l IP-Sec door GRE tunnelen lijkt een optie.

Wat ik zo interessant aan deze draad vind, is dat afwijkingen in het verkeer tot bepaalde verdenkingen leidt
en later misschien tot een detectie van iets. Men heeft een niet te herleiden anomalie in het verkeer
en deze kan later aanleiding zijn voor een detectie. Hoogst interessant allemaal.

Mijn verdenking is dat er weer eens misbruik wordt gemaakt van Chinese of Taiwanese junk.
Ben benieuwd wat jullie verder allemaal boven water krijgen?

Nu ook een item hier: https://isc.sans.edu/forums/diary/Increase+in+Protocol+47+denys/21865/
en https://isc.sans.edu/forums/diary/More+on+Protocol+47+denys/21867/

Re: http://fetch.scritch.org/%2Bfetch/?url=http%3A%2F%2F220.128.119.155%2FWebClient.html&useragent=Fetch+useragent&accept_encoding=

Ik heb eens een lijst gemaakt van de IP adressen waar dit vandaan komt. Over een periode van een half uur gemeten
op een /16 subnet en ik heb 1767 verschillende adressen waarvan alleen al 1335 met een reverse DNS van
*.HINET-IP.hinet.net en nog een aantal met een .tw domein. Dus Taiwan heeft nog steeds een groot aandeel.

Ik heb er eens een paar geprobeerd in de browser te plakken en ze komen allemaal terug met een pagina van een
DVR, waar nergens de merknaam van deze DVR op staat. Het is kennelijk geen HikVision (ook een beruchte) want
die heeft een heel andere pagina waar wel die naam op staat.

Dus kennelijk toch iets met een DVR niet met een router. Maar wat nou precies de reden is om dit verkeer te sturen
daar snap ik nog steeds niks van. Iets anders ermee besmetten dat niet volgens mij, en als het een DDoS moet voorstellen
zou ik denk ik een wat grotere payload gebruikt hebben (het zijn bijna allemaal lege UDP packets, soms een van 512)
en een target uitgekozen hebben. Het gaat nu zo te zien gelijkelijk verdeeld naar het hele internet, ik kom het overal
waar ik kan kijken in gelijke mate tegen.