Telekom DNS BUG

Hálózatok egyéb

Találtunk IRC-n egy ilyen "érdekességet"

https://808c6e38.unconfigured.pool.telekom.hu/
https://2a0104f81c1e9b330000000000000001.unconfigured.pool.telekom.hu/

Nincsen bug, exploit weboldal nélkül. :)

Hova kéne jelentenem? Nem találok semmit.

[szerk] "unconfigured" helyett "fixip"-vel is megy. dsl-lel is. barmi.pool-lal.

  • 2753 megtekintés

( snitt_ | 2024. 09. 05., cs – 13:29 )

Ez se nem bug, se nem incidens. Persze telekom bekorlatozhatna a sajat tartomanyaira, de meh.. Es persze tobb ilyen szolgaltato is van, pl 128-140-110-56.ip2host.org. is felold ugyanerre az A rekordra.

se SPF, se MX rekord nem fog rad mutatni, szoval alap checkek mar elbuktak.

legnagyobb kockazat max valami xss bug a telekom.hu oldalon amivel egy rosszul scopeolt session cookiet le lehet nyulni. Ezert IS hasznalnak ertelmesebb cegek user contentnek dedikalt domaint, mint pl. a githubusercontent.com, stb.

ezzel max ircen lehet hulyeskedni, mert az A/AAAA es PTR rekordok (amit megint te allitasz) odavissza validak lesznek.

marmint melyik NS... hint: az authoartiv NS-et kerdezd a reverse tartomanynak :) otthon te is azt irkalsz a hosts file-odba meg a dns poisoningedbe, amit akarsz.

 

$ dig +trace -x 9.9.9.9

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +trace -x 9.9.9.9
;; global options: +cmd
.                       85367   IN      NS      m.root-servers.net.
.                       85367   IN      NS      l.root-servers.net.
.                       85367   IN      NS      f.root-servers.net.
.                       85367   IN      NS      g.root-servers.net.
.                       85367   IN      NS      c.root-servers.net.
.                       85367   IN      NS      b.root-servers.net.
.                       85367   IN      NS      i.root-servers.net.
.                       85367   IN      NS      a.root-servers.net.
.                       85367   IN      NS      e.root-servers.net.
.                       85367   IN      NS      k.root-servers.net.
.                       85367   IN      NS      j.root-servers.net.
.                       85367   IN      NS      h.root-servers.net.
.                       85367   IN      NS      d.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 9 ms

in-addr.arpa.           172800  IN      NS      a.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      c.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.           172800  IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.           86400   IN      DS      47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa.           86400   IN      DS      53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa.           86400   IN      DS      54956 8 2 E0E2BF5CFBD66572CA05EC18267D91509BA6A9405AF05C3FD4141DFA 45200C08
in-addr.arpa.           86400   IN      DS      63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa.           86400   IN      RRSIG   DS 8 2 86400 20240918060000 20240905050000 14488 arpa. lYSW8OThAinswdceXW54VyeLcEz3u/yY1dfHbuVhHuKsrR0ngwgsvIjb fPseW8z+mJbCp37WeX4CkuYHa43YphV2XYC6KftVP3I/P1BvDcAv/bND 1uSJtQqQQDuWWzYXhhtK0gsOCgWfiaK8y8jZvxoMROSY3UjANN6XFZiW gzJmTzjLHVwMokBgNntt+S0ZZi6U0UXXcDJvam7ACW8n188AGwMQXHQC DmqPZeLwXeZTf5IPpcsy/NBg5qvC7vSkway2+3Fhw08x6BTTSPa/7Sn5 XmM1OAFOO9QRAHklDLa/5BM/hs3Qt4GmL3H6Lp2EqZZrjMTvZRB29GIa PSx0XA==
;; Received 909 bytes from 2001:7fd::1#53(k.root-servers.net) in 9 ms

9.in-addr.arpa.         86400   IN      NS      x.arin.net.
9.in-addr.arpa.         86400   IN      NS      r.arin.net.
9.in-addr.arpa.         86400   IN      NS      u.arin.net.
9.in-addr.arpa.         86400   IN      NS      arin.authdns.ripe.net.
9.in-addr.arpa.         86400   IN      NS      z.arin.net.
9.in-addr.arpa.         86400   IN      NS      y.arin.net.
9.in-addr.arpa.         86400   IN      DS      24487 8 2 5B55A11CF9B093B15182E1106A67B8FF7FDD33EAD00835A3E91E9DC2 3C72A8C8
9.in-addr.arpa.         86400   IN      RRSIG   DS 8 3 86400 20240912082144 20240822020835 25506 in-addr.arpa. WwmAuSPPFD7EylWD6OgRHy9RwAkZRY63u4RjnjYJ6IPxzaaTaE0dJNlI +HTGv+qpz/L1m50rk9f965d7KeO1evnUytg9/P2IImyFpRrHbW5fstbB Mttz445ge3UUkqD9rQPek2df5Fa6a29ZFvNzwfDIcC4rZsN7dQOGzoqK u1U=
;; Received 406 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 27 ms

9.9.9.in-addr.arpa.     86400   IN      NS      anyns.pch.net.
9.9.9.in-addr.arpa.     86400   IN      NS      ns2.pch.net.
9.9.9.in-addr.arpa.     86400   IN      NS      ns3.pch.net.
9.9.9.in-addr.arpa.     10800   IN      NSEC    9.in-addr.arpa. NS RRSIG NSEC
9.9.9.in-addr.arpa.     10800   IN      RRSIG   NSEC 8 5 10800 20240919042953 20240905032953 21201 9.in-addr.arpa. VQXxv874GjCcs7HoXRe/GU5gYJYM7//v59kc3Wucpi+uFsO+vtbJ2yCK Qs3NNc43w00HReyIb9zwU3M/VYFxGT9GOaiqWrC8ElBfXNpeUbni8ddL IRoK8b5ZFXOYKUhgxzjw84DDjBeRQPYSTyjlbrW4uVd6FKkycdhmSLq+ TRU=
;; Received 350 bytes from 2001:500:f0::63#53(r.arin.net) in 155 ms

9.9.9.9.in-addr.arpa.   172800  IN      PTR     dns9.quad9.net.
9.9.9.9.in-addr.arpa.   172800  IN      RRSIG   PTR 8 6 172800 20240927150000 20240827150000 36546 9.9.9.in-addr.arpa. WEGN8jv1MKugOB05+izkPCslnsg4lR4WHmN/OC12JDtrz/Py/8Gh3h+1 j/Yq++E/ZCXgORK5EcWXZXcSDuXAyFgvJSpTBkU4U9mfzhwKh1L+pGEK +OlTOiTbQQP9npCUpv4khDL0d7nftxiijjNggth+QTvZMsEelzh8NSkd VOwQ4CDWIVArc23YOYXcVIvbUNNuzu3/k7RgV/krhRm4vmnGRDQwyfTZ jBiG/hx6E/WsabUIy7y1+SqKOn7pNRFKZEGpZ+O4r/ys0g01yq7LeM30 ZjccYCM+gi+Rkyy3ZNcVhsts3XoNPS8l6Go/S9XcDV6Fd5TlGiqzSiGz M+Ydkw==
9.9.9.in-addr.arpa.     172800  IN      NS      ns2.pch.net.
9.9.9.in-addr.arpa.     172800  IN      NS      anyns.pch.net.
9.9.9.in-addr.arpa.     172800  IN      NS      ns3.pch.net.
9.9.9.in-addr.arpa.     172800  IN      RRSIG   NS 8 5 172800 20240927150000 20240827150000 36546 9.9.9.in-addr.arpa. dOcyUnaKAmO1A8pz1wmHVrcKKTRa+v8runMRnWmzfIMldZ/a6mjDwnaN Xqk56KS0pItf50YSpquKNeLvr7yglLVR6DLCfYtkAIKpFst/DC3v9lvs 2iNw93zkS7PUObWhgqYGcDmYkI+x8Jk8aEJBj2IPfl4eZc+60fYvdNLy IcsBknQ5o9+ZTG8ze1MZ590gzZaPt0GwAVKpCOYKYfv8cuNST0wv/0Lx /1SPGGwsl+9EEz/TEfkEpQQxvky93Nf2EhXr1uY+HH/hVkgS//PF2iCl /DYyiqg50fide06LtLJdjtE+78U6mZGuKK2xEjPXEWeCBHNRWSqcZl9K fNdA4A==
;; Received 1176 bytes from 2620:0:872::231:3#53(ns3.pch.net) in 153 ms

Mert van egy domain neved, amit bárhol használhatsz bármire, lehet szerver hostnév, tudod használni reverse-re, kérhetsz rá SSL certet, és igazából azt csinálsz vele amit akarsz, úgy hogy másnak a tulajdona.

Aki szerint ez rendben van, az kérem jó messzire húzzon el az IT-tól.

"Sose a gép a hülye."

OTP anno (most is lehet, talan) csekkolta a felado MX rekordokat is. Nemtom mi az elvaras amugy, mert napjainkban 99,9995%-ban nem az MX rekordban levo host (es amogott levo IP) adja fel a kimeno leveleket. De egy egyszeru, van-e MX rekord csekk meg mukodhet. Persze ezesetben szart sem er egy ilyen, mert:
 

09090909.unconfigured.pool.telekom.hu mail is handled by 10 poolmx.telekom.hu.

Igen, és van egy free domain neved amit használhatsz.

És amúgy szerinted egy átlag telekomos user például szerinted mit reagálna, ha küldenél neki egy ilyen telekom.hu-s linket, hogy most azonnal lépjen be a fiókjába és fizesse be a számlát?

"Sose a gép a hülye."

Amíg telekomos poolból van, addig semmi. Ezzel az a probléma, hogy bármilyen IP-re működik.

Próbáld ki, hogy csinálsz egy telekom ügyfélapu megszólalásig kamu oldalt egy ilyen pool.telekom.hu-s domainen küldd el a telekomos ismerőseidnek, és nézd meg hogy hányan fognak rá belépni.

"Sose a gép a hülye."

Szerinted az emberek hány százalékának számít (vagy veszi egyáltalán észre), hogy mondjuk login.telekom.hu, portal.telekom.hu vagy srv1.sso.telekom.hu helyett (amik amúgy teljesen "elfogadottak") mondjuk egy beeffeed.fixip.pool.telekom.hu oldalon lép be?

"Sose a gép a hülye."

ez minden ip-re igaz. meg mindig. a sokrandomkarakter.UNCONFIGURED.pool.domain.hu egyreszt kit erdekel, masreszt ha a kinai jozsi bejut a pesti geza lyukas kinai routerere/kamerajara, mar kesz is a zold letsencrypt. :)
a letsencryptes zold lakat ennyit "tud".

Ez nem lets encrypt probléma, egy webszerverre kirakott verification fájllal bármilyen fizetős certet lehitelesítesz. Másrészt, nincs oda írva a lakat mellé hogy letsencrypt vagy sem. Harmadrészt, ha oda lenne, a legtöbb embert akkor se érdekelné és nem tudná, hogy miért van ott Lets Encrypt, Symantec vagy StartSSL.

"Sose a gép a hülye."

lassuk...

dorsy@wsl64:~$ dig 808c6e38.unconfigured.pool.telekom.hu

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> 808c6e38.unconfigured.pool.telekom.hu
808c6e38.unconfigured.pool.telekom.hu. 84127 IN A 128.140.110.56

dig -x 128.140.110.56
56.110.140.128.in-addr.arpa. 86400 IN   PTR     noopweb2.unreachable.hu.

ezzel nem sok levelet nem fogsz kikuldeni, elbuksz az elso PTR checken :)

hat, max ha a mailname-ed is a noopweb. de mint mondtam ez mindenhol "jar". olyan reverse-t adok a vasarolt ip-mnek amilyet akarok.

es a telekom.hu-s SPF-ben benne vagy-e? :)
dmarc priv kulcsod is van hozza? :)

a legalapabb spamchecken sem mesz at.

reject_unknown_sender_domain
Reject the request when Postfix is not the final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A record, or 2) a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later

Fedora 41, Thinkpad x280

Jó, akkor postfix így nem tudja, de ugye nem csak postfix van. Exim talán tud ilyet. Ha már MTA szinten el akarod dobni. Viszont MTA után csillió lehetőséged van kiszürni, hogy van-e MX 

Viszont mivel SPF nincsen eleve kuka vagy jobb esetben SPAM ...

Fedora 41, Thinkpad x280

lehet ok maskepp gondoljak mint en, amde:

reject_unknown_helo_hostname (with Postfix < 2.3: reject_unknown_hostname)
Reject the request when the HELO or EHLO hostname has no DNS A or MX record.

 

reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
Reject the request when 1) the client IP address->name mapping fails, or 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address.
This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above.
The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.
 
 

es/vagyzarojel :D
de ugye onnantol mindegy, h van SPF check. marpedig anelkul ahogy mondani szoktuk elni ugyan lehet, csak nem erdemes.

Mindkét opciót használom, egyik se az.

reject_unknown_helo_hostname: a helo hostnévnak nincs A vagy MX rekordja. Ha A vagy MX van, akkor pass.

reject_unknown_client_hostname: ez meg annyit néz, hogy a helo hostnév valid (feloldható), és valóban arra az IP-re mutat, aki ezt a helo nevet mondta.

Egyébként tldr, RFC szerint sem kötelező az MX rekord megléte, ha nincs A rekordra próbálja kézbesíteni pl. a levelet.

"Sose a gép a hülye."

az, hogy te nem uzemeltettel meg mailszervert, nem jelenti, hogy mas sem. :) a legalapabb checkeken nem jutsz at.
ebbol a tartomanybol "normalisan beallitott" MX-re te be nem kuldesz semmit :D (se spf se dkim)
ami kb. a default postfixet jelenti barmelyik random hostingban es/vagy barmelyik nagyobb free mail providert.

Nem érted és/vagy nem akarod elfogadni amit írok.

Befejeztem veled a vitát, mert semmi értelme, össze vissza felhozol dolgokat, majd mikor eggyel zsákutcába kerültél, akkor előhúzol egy másikat.

Remélem a telekomnál van legalább 1 értelmes ember, aki érti amiről beszélek.

"Sose a gép a hülye."

ertem mirol beszelsz. nem latom mitol masabb egy ilyen ip-rol spamelni, amire van egy LE certed, ami a iphash.unconfigured.pool.telekom.hu (ami egyebkent igaz a "rendes" telekomos ugyfel tartomanyokra is), mint egy masikrol. :) erre nem tudtal valaszt adni, ezert szemelyeskedsz.

Nem személyeskedek.

Annyival másabb, onnan indult az egész, hogy ez bármilyen IP címmel működik, nem kell telekom ügyfélnek lenned. És ismét mondom, hogy a spammelés is csak egy példa volt, mint a 9.9.9.9, hogy mit csinálsz a domain mögött, annak csak a fantázia szab határt.

Illetve neked is mondom, hogy ha szerinted ez nem probléma, csinálj nekem légyszi egy hnsz2002.dorsycege.hu domaint, megmondom milyen IP-re irányítsd, aztán hadd tegyek ki rá bármit, amit akarok.

"Sose a gép a hülye."

Ez ok. És akkor mi van ? Hol van az megtiltva, hogy ne csináljak olyan DNS szervert ami minden IP-re ad vissza A rekordot ? Mint a szálban is említették van is már ilyen.

Szóval mi ebben a meglepő ? Mire lehet használni ? 

Persze lehet nekem kevés a fantáziám, hogy akár a fenti esetben is mit kezdhetnék egy unconfigured.pool.telekom.hu hostnévvel, aminek egy A rekordja van és kész ...

Fedora 41, Thinkpad x280

Ne komolytalankodj. A telekom.hu domaint akkor is a telekom NS oldja fel, ha te egy közbülső rekurzív DNS servertől kérdezed. Nem az oldja fel, az csak továbbítja neked a tartalmat.

a dorsy.ingyenlofaszdomain.com se kéne, hogy visszaadja a 8.8.8.8-at, mert semmi köze hozzá. Technikailag persze megteheti, de nem kéne. Ez olyan, mintha más maildomain nevében küldenél levelet. Amit régen megtehettél (technikailag), nem véletlen, hogy ennek kivédésére mindenféle megoldások születtek.

akkor is a telekom NS oldja fel > ez netto baromsag. barki lehet barmelyik domain authorativ NS-e, sot, jobban jarsz ha zonan kivuli, kisebb esellyel fog "eltunni a zonad a vilagbol", ha valami van, pl. elszarodik a glue rekord egy NS ip csere miatt. :)
barkitol veszel egy domain+hostingot, 99% ok lesznek az NS default. kidelegalhatod ahova tetszik.
azt akarod mondani, h ripe szerint tiednek kellene legyen az ip subnet, hogy feloldhasd dns-ben?
fogalmazzunk ugy, erost eletszerutlen.
mert akkor a dyndns, cloudflare... is dogoljek meg! :) az osszes shared hosztinggal egyetemben.

Megint hülyeséget beszélsz, ez egy tök más dolog.

"barki lehet barmelyik domain authorativ NS-e"

Persze, ha tied a domain, úgy állítod ahogy akarod. Ellenben a telekom.hu domainek azok az NS-ekhez fognak szegről végről menni, amik a telekom.hu authoritativ NS-e.

"Sose a gép a hülye."

melyik resszel szeretnel vitazni?
az nem gaz, hogy a paraszt csinalhat DNS bejegyzest az otthoni telekomos IP-jere nem telekomos DNS-bol? :) csak forditva halunk meg mind? :)
ha en csinalok egy DNS cname-et, ami a mikrotikem dyndns-ere mutat, ami meg mondjuk egy telekomos iptartomanyban van akkor en nem vagyok geci, csak a mikrotik DNS-e az? vagy fifty-fifty? :D

mit is szeretnel mondani? :)

dig (sn.)mynetname.net txt

;mynetname.net.                 IN      TXT
;sn.mynetname.net.              IN      TXT

Akkor most jajj, mi lesz, meg SPF sincs a dyndns-es zonaban!!!!1111
azmeghogy a MT (whoever) altal birtokolt DNS zona felold random IP-ket a vilagbol, so what? :D ettol meg semmi koze hozza mi van azon az IP-n. mindenki le se tojja.

A delegálás már csak subdomain, és akkor is csak az lehet az authoritatív NS, akihez delegálják. Szóval a bárki lehet bármelyik domain authoritatív DNS-e továbbra sem igaz. Viszont a sok smiley - ahogy az lenni szokott - tökéletes jelzése annak, hogy te is tudod, hogy buktad az érvrendszert.

A továbbiakban vitatkozz egyedül.

mar hogyne lenne igaz. a TLD-bol van kidelegalva a domained a regisztrator altal. olyan NS-re amilyenre csak akarod.

rohadtul nem kell, hogy a tied legyen az ns. akarkie lehet, domainen kivuli is. ha ezzel ujat mondtam, vitazz inkabb magaddal [smile]

Látható, hogy nem vagy képes értelmezni a saját szövegedet. Nem bárki, hanem egy adott server, amelyik a delegált névserver. Ha bárki lehetne, akkor én felhúzhatnék egy NS-t és feltehetnék rá tetszőleges domaint, mert én is beleesem a bárki halmazba. Mindezt delegálás nélkül. Amit te állítottál, az nagyjából ez. Ez pedig nyilvánvaló marhaság.

az, hogy neked a valaki/akarki nem a barki halmaz resze es direkt felreerted amit mondok, aztan meg bele is allsz, mert trollkodhatnek-fozeleket ettel, arrol nem en tehetek, sry :)
BARKIHEZ iranyithatod az NS-ed. AKARKIHEZ: "barki lehet barmelyik domain authorativ NS-e". ezzel vitazol.
amit kerdeztem, hogy ki mondja meg ki mit oldhat fel es milyen alapon, azt meg leszarod :)

mert igazam van? :)

arrol nem beszelgetunk, hogy miert eletszerutlen ordas nagy baromsag a javaslatod, hogy csak az oldhasson fel XY ip-t, aki a tulaja XY ip-nek/subnetnek?
vagy arrol az ordas hulyesegrol, h adott domain authorativ nevszervere csak annal lehet, akie a domain? ki is nem fogalmaz itt egyertelmuen?

csak arrol, hogy az egyertelmuen - direkt ott volt, pedaval egyutt, mire gondoltam - leirtakat felreertve probalsz lehulyezni 4 szinten egyertelmu valasz ota? :D

Oroszország nehéz mert a barátaink és nagy ívben szarnak az abuse reportokra akár kurváhosszu Telekom.hu domain ami megzavarja a usert akár nem.

https://toremanc.com/lnk/data/ip.admin.txt

Ez nem domain függő, egyszerűen az ilyen "szolgáltatóktól" vissza kellene venni a tartományt és keressenek egy rendes munkát.

Amúgy a regisztrátornál még nehezebb ;) ezért adnék neked én subdomaint.

Meg tudsz téveszteni olyan embereket, akik elhiszik, hogy az adott cím a telekom.hu-hoz tartozik. Az adathalászat elleni szövegek jellemzően azt sulykolják, hogy a domaint ellenőrizd, és azt is hozzászokták tenni, hogy domain alatt hu esetében a valami.hu-t kell ellenőrizni. Azt, hogy a további szinteken mi van, már nem szokták hozzátenni (részben jogosan, mert lehet www, www2,  login, sso, és lehetne sorolni). Ebből a szempontból a többi szolgáltató is némileg problémás, mert vodafone.hu alatt is megvan a .catv.fixed.vodafone.hu subdomain IP címmel kiegészítve (lehet, hogy erre egy más domaint jobb lenne használni), de legalább csak a tényleg hozzájuk tartozó címekre. Egységsugarú user azt se ismeri fel, hogy a telekomos domainben az IP cím van elrejtve, mert nem IP-nek néz ki az iptohex konverzió miatt.

Szóval mindenképpen alkalmas megtévesztésre, még akkor is, ha elég hülyének kell lenni hozzá. De sok ember elég hülye.

Csak míg az egy tök másik domain, ez ennek egy subdomainje. És visszajutunk oda, hogy kinek hogy magyarázod meg, hogy az auth.login.telekom.hu domain jó, a pool.telekom.hu pedig rossz.

De egyébként a másik domainnel is ugyanez a helyzet. Hogy mondod el, hogy a github.com meg a githubusercontent.com jó, a githubscammercontent.com meg nem?

"Sose a gép a hülye."

Hogy mondod el, hogy a github.com meg a githubusercontent.com jó, a githubscammercontent.com meg nem?

Ki nem szarja le ? Ez egyéni szociális probléma, ha az ember hülye. Ebből élnek az adathalászok, is.

A tárgyban szereplő "feature" nek ehhez semmi köze, mert semmivel nem másabb mint fél perc alatt regelni saját scammer domaint, amihez bármilyen más rekordot is be tud állítani, hogy még hitelesebb legyen.

Az emberek 95% el se olvassa milyen link van, csak kattint, és kattint és kattint. 

Fedora 41, Thinkpad x280

( uid_4278 | 2024. 09. 05., cs – 15:40 )

Szerintem jelentsd nyugodtan. Úgy is kicsit lapos a hup mostanában, kéne néhány jó sztori :D

( kruska v | 2024. 09. 05., cs – 17:14 )

Egyéb wildcard DNS példák, PowerDNS alapokon:

9.9.9.9.xip.moss.sh

9.9.9.9.getmoss.site

9.9.9.9.nip.io
9-9-9-9.nip.io
09090909.nip.io

Mondjuk ezeknek nincs akkora "ereje", mint egy .telekom.hu-nak.

Szerintem erősebbek mert rövidebbek mint manapság az attention span ;) Amúgy annak se lennék a helyében aki Telekom ügyféloldalt hamisít , mintha már jelszót sem kérne, hanem  vagy smst küld, vagy emailt. Az okozott károkat sem nagyon tudom elképzelni, lehet kérni esimet aztán ha az importálás nem sikerül szerintük..., kell a 1414-nek az öt számjegyű ügyfélkód amiből nem csak egy lehet.

Lehet ezért nem jön soha Telekom spam üzenet. :)

...és akkor amíg mindenki azon kötözködik, hogy az rfc szerint opcionális DKIM meg SPF meg stb. megvédi-e a levelezést miközben ilyen orbitális marhaságra képes a telekom, még azt nem említettük, hogy jóska pista beállítja a céges tűzfalban/policyben/transzparens proxyban hogy *.telekom.hu access kifelé, mert nem akarja felsorolni az összes portáljukat, meg az ip-k is összevissza változnak, aztán jé nem átbújik az adathalász kamuoldal ezen is?:) És persze így nem kell, hogy valós telekomos ip legyen, szóval NMHH felejtős, és naponta jön egymillió másik külföldi ip-ről újra.

Mondjuk én már azt se értem, hogy mit keres az spf.protection.outlook.com a telekom.hu spf rekordjában, meg spf.smtp.hu? Kiszervezték az MS-nek a levelezést?:)

Ja és egyébként zárójelben ez is be van inklúdolva: _spf.t-systems.hu  -> ... .254/32 ~all" (meg az spf.smtp.hu-ban is tilde van) ilyet még nem csináltam hogy egy egyébként -all -os spf rekordba include-olok egyet amiben ~all van, ilyenkor akkor hardfail vagy softfail van? Lehet érdemes lesz figyelni, mert egyszer feladják, és beleteszik hogy 0.0.0.0/0 :) azt már félve írom le, hogy a dmarc-nál p=none; van...

Köszi hogy rávilágítottál erre is. Azaz *.pool-lal megy.

Akkor innentől még mindig azt mondod, hogy egy 11223344.login.pool.telekom.hu domain, ami megkapja az összes telekom-hu cookiet, nem gáz, és nem alkalmas arra, hogy gyakorlatilag az üzemeltetőn és a programozón kívül (akik pontosan tudják, hogy itt milyen domainnek vagy url-nek kéne lenni), kb. mindenki bekajálja?

Még egyszer mondom, hogy aki szerint ez rendben van, az jó messzire húzzon az IT-tól.

"Sose a gép a hülye."

vagdalkozas az megy, de muti mar meg a PoC-t, ahol megszerzed a login cookie-jait a telekomnak! :)

Cookie Domain Description Duration Type
mt-login-token www.telekom.hu   session Other

ezzel nem sokra mesz :)
nem, nincs T accom, es csak a login oldalt latom, ezert kerdezem, h mi az a nagyon durva megfejtes, amire farkast kialtasz :)

mit keres az spf.protection.outlook.com a telekom.hu spf rekordjában > ott van a levelezesuk (meguntak ok is a levelezes uzemeltetest => szellel szemben hugyozast) :)
 

	dkim=pass (1024-bit key; unprotected) header.d=MTELEKOM.onmicrosoft.com header.i=@MTELEKOM.onmicrosoft.com header.b="joEDKTzd";

Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2072.outbound.protection.outlook.com [40.107.22.72])

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=MTELEKOM.onmicrosoft.com;
...

legalabb elolvashattad volna az spf include RFC-jet mielott "mindmeghalunkat" kialtasz :)
https://www.rfc-editor.org/rfc/rfc7208#section-5.2

5.2.  "include"

   include          = "include"  ":" domain-spec

   The "include" mechanism triggers a recursive evaluation of
   check_host().

   1.  The <domain-spec> is expanded as per Section 7.

   2.  check_host() is evaluated with the resulting string as the
       <domain>.  The <ip> and <sender> arguments remain the same as in
       the current evaluation of check_host().

   3.  The recursive evaluation returns match, not-match, or an error.

   4.  If it returns match, then the appropriate result for the
       "include" mechanism is used (e.g., include or +include produces a
       "pass" result and -include produces "fail").

   5.  If it returns not-match or an error, the parent check_host()
       resumes processing as per the table below, with the previous
       value of <domain> restored.

   In hindsight, the name "include" was poorly chosen.  Only the
   evaluated result of the referenced SPF record is used, rather than
   literally including the mechanisms of the referenced record in the
   first.  For example, evaluating a "-all" directive in the referenced
   record does not terminate the overall processing and does not
   necessarily result in an overall "fail".  (Better names for this
   mechanism would have been "if-match", "on-match", etc.)

a dmarcot meg hagyjuk :)

hangzatos, lehet puffogtatni, csak a kutya sem hasznalja erdemben, mert elobb terjedt el a fent emlitett SPF. :)
(es nem, meg mindig semmi kozom a telekomhoz, mielott megint valaki ezt talalna ulitmate "ervnek" hozni xD)

( hnsz2002 v | 2024. 09. 10., k – 20:47 )

Szóval, jobb híján az ugyfelszolgalat@telekom.hu-ra írtam... Akiknek fogalmuk nem volt róla, hogy mi ez, mivel felhívtak utána, hogy mi ez amit küldtem.

Próbáltam elmondani, illetve azt is, hogy az oldalon ott van leírva a lényeg, de továbbítsák hálózatos vagy security-s kollégának, ők fogják érteni.

Szerintem nem továbbították... Ellenben a bejelentést ma lezárták.

"Sose a gép a hülye."

lehet a halozatuzemeltetes fele kellett volna bekuldeni, nem a lakossagi level0-hoz.
nem tudom melyik AS-rol van szo, mert le*om, de igazabol mindegyis: https://bgp.he.net/AS5483#_whois

NOC: noc.ip@telekom.hu
Abuse: abuse@telekom.hu

szivesen!