Témata

16

Server / Při absenci MX se nedoručí na AAAA

« kdy: 17. 03. 2023, 21:02:34 »

Zdravím,je nějak definované,jak doručit mail na doménu(za zavináčem),která nemá MX záznam?

 Je to nějak standardizované a děje se v praxi,že se zkusí "fallback" na A záznam,když tedy MX není? Tuším, že v RFC to je zmíněné, ale nevím jak moc MUST,SHOULD,MAY a nevím jestli toto rfc bylo aktualizované pro IPv6

K jádru dotazu, Platí totéž i pro IPv6 (tedy když nemá MX, ale má jen AAAA)?

Mám jen jeden vzorek dat (jeden outbound) a výsledek,že v případě  poslání doménu (třetího řádu)s jen "RR:A" mail přijde
ale v případě poslání na doménu s jen "RR:AAAA" se vrátí jako PermError - no valid mx Record



(Otázka míří na sending side.Předpokládá se,  že na straně příjemce nezáleží, příjemcův SMTP server na IPv4 a IPv6 adresu tuto poštu ochotně přijme.Vlastně nikde ani není dáno že musí jít o téhož přijemce, může jít o 2 příjemce,které spolu nesouvisejí, ale první doména má jen A RR, druhá AAAA RR)


Případně,je nějaký dobrý vysvětlení, proč v případě jen-A záznamu  ji doručí,ale pro jen-AAAA doménu se vrátí jako nedoručitelná-noMXchyba

17

/dev/null / význam dat v play.google.com/log

« kdy: 15. 03. 2023, 22:08:43 »

Zde jsem na to upozornil. Zapomněl jsem zmínit, že se to páchá i na youtube.com
 Během 7 min na stránce minut 16 pokusů o odeslání v časech 7s, 35s, 2min,4,5


Některá pole se mění (typicky timestampy začínačící 16789), pak se mění čísla v párech [null,float nebo nula], magický string (\"O43z0dpjhgX20SCx4KAo\") zůstává. Ale zkoušeno jen na jednom pageview.
Jaký je význam?

Kód: [Vybrat]

[[1,null,null,null,null,null,null,null,null,null,
[null,null,null,null,"cs-CZ",null,"9",null,null,[1,false]]],1654,
[["1678913564561",null,[],null,null,null,null,"[[[\"/client_streamz/po/w/cec\",null,[\"ec\",\"rk\"],[[[[null,11],[\"O43z0dpjhgX20SCx4KAo\"]],[2]],[[[null,14],[\"O43z0dpjhgX20SCx4KAo\"]],[1]]],null,[]],[\"/client_streamz/po/w/el\",null,[\"en\",\"rk\"],[[[[\"q\"],[\"O43z0dpjhgX20SCx4KAo\"]],
[null,0.19999980926513672]],[[[\"S\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,0.7000007629394531]],[[[\"r\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,2893.199999809265]],[[[\"y\"],[\"O43z0dpjhgX20SCx4KAo\"]],

[null,0.09999942779541016]],[[[\"e\"],[\"O43z0dpjhgX20SCx4KAo\"]],[null,0.7999992370605469]]],null,[]],
[\"/client_streamz/po/w/rl\",null,[\"mn\",\"ac\",\"sc\",\"rk\"],[[[[\"c\"],[null,1],[null,2],[\"O43z0dpjhgX20SCx4KAo\"]],[null,3.3000001907348633]],[[[\"c\"],[null,2],[null,2],[\"O43z0dpjhgX20SCx4KAo\"]],
[null,1.9000005722045898]]],null,[]],[\"/client_streamz/po/w/csc\",null,[\"cs\",\"rk\"],[[[[null,3],[\"O43z0dpjhgX20SCx4KAo\"]],[1]]],null,[]]]]",null,null,null,null,null,null,-3600,null,null,null,null,[],1,null,null,null,null,null,[]]],"1678913585043",[]]: 

hlavičky
X-Goog-AuthUser: 0

Co ty údaje znamají a proč je jejich komplicem doména play.google.com?

Call chain je povětšinou v youtube.com/.../base.js , funkce: g.k.send, xfa,$fa,r, g.k.flush, g.k,G.K,oba,a

Ale hledat něco v 624kB minifikovaného javascriptu to nevím,,, nevím, před spaním raději preferuji penetrační testování internetových bankovnictvích případně válení sudů po střepech na chodbě olomoucké hospody v fotbalovém dresu sparty

18

/dev/null / šokující : android nemá binárku na typu dig /host/nslookup

« kdy: 10. 03. 2023, 21:32:15 »

Že jsem tak smělý, jak si na androidu(11) laskavě zjistím hostname nějaké domény (s určením RR typu)?

# ! přes příkazový řádek
a
# out of box, bez instalace pkg install dig v termuxu

Ty dvě podmínky jsou kruciální, mohu si v Termuxu nainstalovat pkg install dig nebo nedejbože v google stóre stáhnout 20megovou aplikaci   co se kromě zvoleného DNS(pokud to vůbec umí, stačí systémový DNS) připojuje na 20 spywarových domén...

Jde zkrátka v androidu (9-12) spustit binárka ,která mi resolvne nějakou doménu a konkrétního RR typu (TXT např) a volitelně přes zvolený DNS(over UDP ,TLS,HTTPS)

Zkoušel jsem "appky"
defaultní "appku" Terminál (kterou pro totální absenci jakýchkoli základních funkcí má v Výbojářských nástrojích zakázanou, jsem ji teď povolil a pak zase zakázal, neumí ani historii)
Connectbot  - local teminal- pravděpodobně pouze wrapper pro ten terminál -tedy stejných chroot, funkce
Termux - až po instalaci mám dostupné dig,host,nslookup, ale do momentu než přes su přepnu na roota



Zkoušel jsem název příkaz textově zadat
nslookup
dig
host
ho

19

/dev/null / bug adresního řádku mobilního firefoxu

« kdy: 08. 03. 2023, 21:56:05 »

Když mám v schránce delší text (třeba zkopírovanou poznámku,  nevím třeba 1kB) a v mobilním firefoxu na androidu otevřu adresní řádek (jakože si chci otevřít nějakou stránku World Wide Webu, ,  po staromilsku vytočením vyťukáním URL, našeptáním si z historie nebo záložek* nebo si prostě momentální URL chci zkopírovat), tak v momentě kliknutí na address bar se firefox zasekne asi na minutu. A potom se objeví vložený text a a kurzor na jeho konci.



(Mimochodem, když už je na mobilech vše responzivní a rozliklikávacík, nemohl by adresní řádek být víceřádkový - pochopitelně jen při interakce? To bych chtěl asi užmoc)


 Když v mobilním firefoxu mám napsaný text v adresním řádku a omylem zakliknu na tlačítko "křížek v kruhu" v pravé části adresního řádku, už ho nejde vrátit přes Ctrl+Z.


Jenže našeptávání v mobilním firefoxu funguje jak španělský  auta v zimě :  někdy funguje:ukáží se řádky s vyhovujícími kandidáty (asi pondělí úterý sobota ) a někdy ne: můžete psát do aleluje a co chcete a nezobrazí  zaboha žádný kanditát, jako kdyby tato funkce nebyla (asi  středa čtvrtek)


(Vypozoroval jsem, vždy po novém spuštění to funguje několik pokusu/nějakou dobu). Občas, velmi občas když to nejde to začne jít bez nutnosti restartu ale to je asi když zrovna je neděle.

20

/dev/null / POWER_SUPPLY_CAPACITY_**RAW**

« kdy: 08. 03. 2023, 16:08:49 »

Snažil jsem pouzit hledač, ale nenašel jsem význam (/sys/class/power_supply/uevent) řádku(android 10, kernel 4.4 , snapdragon 16nm, s podporou usb-c (vč.PD) už)

POWER_SUPPLY_CAPACITY_RAW (analogicky  /sys/class/power_supply/ bms/capacity - konkrétní "řádek")

Přičemž
POWER_SUPPLY_CAPACITY je hodnota v procentech (co je vidět v liště třeba)


(Zeptal bych se i na POWER_SUPPLY_CHARGE_NOW_RAW=0                 POWER_SUPPLY_CHARGE_NOW=0) ale ukazují nuly při nybijení i vybijení)

21

Odkladiště / Je možné získání dat skrze XXE?

« kdy: 07. 03. 2023, 17:08:36 »

Zde v sekci "exponential"

Jak se s tím dají vyčítat data? Připadá mi to jako nepodložená senzace... Napadají mě snad jen2cesty: buffer overflow ;a chybová hláška, která  odhalí max.cestu zpracujicího sktiptu

server APIs, and customer information can be stolen through XML attacks.

XXE attack when performed successfully can disclose local files in the file system of the website. 

22

/dev/null / Jaký to dává smysl?

« kdy: 02. 03. 2023, 16:46:18 »

Jakýto dává smysl? Možnost přihlásit na Centrum.cz Mail Přes (tlačítko) Přihlásit se přes google? To je nějaký černý humor?

23

Server / Update kernelu na VPS

« kdy: 22. 02. 2023, 14:36:38 »

Bývá časté na VPS si možnost updatovat kernel  ? Vlastnoručně?

Nemůže se něco rozbít? Záleží přitom na druhu virtualizace?

Konkrétně  mi nejde ip link add type wireguard: Unknown device type. Distribuce jeDebian BullsEye a, 5.4, a jádro něco jako el7.elrepo

24

/dev/null / iptables --m recent: možné oba zápisy update+set (pořadí a -j)

« kdy: 17. 02. 2023, 15:35:58 »

Narazil jsem při hledání použití parametru --mask v iptables

na zajimavou ukázku:
Na něm mě (kromě mírně nezvyklého zápisu -I1- I2,I3)zarazila přítomnost+nepřítomnost action u set+update a taky jejich samotné pořadí

Kód: [Vybrat]

iptables -A black   -m recent --set   --name blacklist   -j DROP

iptables -X ssh
iptables -N ssh
iptables -I ssh 1   -m recent --update    --name blacklist   --reap   --seconds 86400     -j DROP
iptables -I ssh 2   -m recent --update    --name timer       --reap   --seconds   600     --hitcount 4   -j black
iptables -I ssh 3   -m recent --set       --name timer   -j ACCEPT

Setkali jste se s tím? (ano, je to tam vysvětlená a man jsem četl, -vím, že --set matchne vždy, taky se musí dávat pozor že právě pravidlo za always match efektivně ukončí chain) Většina použití má prohozené pořadí Dokonce obou věcí

• první pravidlo je --set, druhé pravidlo je --update
• u --set není action, u --update je -DROP

Tady je to opačně.
Funguji oba zápisy stejně nebo sice fungují ,ale jinak?

A zpět, k tomu, co jsem hledal: musí se --mask uvádět u --set i u update??? Nikde jsem to nenašel vysvětlené. Experimentálně jsem to nezkoušel zatím.

25

Server / Volby pro SSH, aby vydržel dlouhodobě NAT

« kdy: 17. 02. 2023, 09:42:26 »

Mám dotaz, jaké zvolit volby pro sshd + ssh, aby  vydržel téměř nonstop pro Remote forwarding portu. Na server například je komunikace každou hodinu, která se forwarduje do klienta (tedy ten co spouští ssh)
V situaci, kdy klient je za NATem s poločasem rozpadu 2 minuty.

Používám nyni -o ServerAliveInterval 50 a běží to   třeb půl dne ale  v noci někdy(nevím jak často) vymizí, proces ssh se ztratí a na serveru už ss-4lntp taky neukazuje řádek který jsem nastavilMám pocit, že s touto volbou to vydrží.  Jednu hypotézu mám, že výsledky by mohlo zkreslovat různé nepovedené komunikace, které neprovedou výsledek, nezalogují se, jako  třeba jen otevřené spojení, různé port scannery, které refreshnou komunikaci a zabrání expiraci.

Předtím jem to provozoval bez ServerAliveInterval amám pocit, že rozpadky byly čaastější, ale neumím to upřesnit.

1. Jsou volby Server vs Client - AliveInterval/Count rovnocenné? (až na to že se nastavují u klienta resp. u serveru a odhlédnu od toho, který konec čeká na expiraci timeru)
Je tato volba důležitá?

2. Bonusová otázka, jak Remote/local forwarding funguje,   čeká server až se dokoncčí handshake a pak teprv začne komunikace na klientovi a nebo tunel posílá TCP pakety jak přijdou /že přes tunel putuje TCP syn, ack+syn, ck přes celý tunel)


3: TCPKeepAlive jsem pochopil že není to co chci. Má být vypnuté nebo na něm nezáleží? (Volba je pro obě strany)

26

Sítě / Podmínky Wake on LAN u Wi-Fi karet

« kdy: 10. 02. 2023, 22:18:00 »

Jaké jsou podmínky Wake on LAN u wifi karet (interních i externích pře USB), funguje to vůbec a na jakém principu?

1. Zůstává třeba wifi karta stále asociovaná k AP?(správněji, jestli ji AP vede ve své tabulce)

Na kabelu jen stačí, když je v zasunutém stavu(že  tam i na protistraně "svítí dioda LAN") a na do kabelu se dostane paket s magic paternem (tuším že opakovaná mac adresa).Nevím jestli stačí broadcast  magic packet, nebo i dst mac musí odpovídat, ale to není moc velký problém

Na wifi jsou asi 3 problémy:
1 Operuje na určitém kanálu. KLIENT i AP
2. Pokud je vyřešen problém s kanály, stačí opět  wifi paket s cílovou mac adresou wifi karty (na wifi jsou T(ransmiter)A,R(eceiver)A,D(est)A,S(ource)A)
2 Funguje to v rámci dané zaheslované wifi sítě nebo tahle funkce  bez ohledu na SSID a šifrování
3Na jaké vrstvě funguje vůbec wake on lan na wifi??

Přecijen u kabelové LAN je potřeba vyslat rámec  z "kolizní domény", cožmůže být pár zařízení na switchi, u bezdrátu je médium okolní trojrozmerný prostor a mělo by tam být aspoň znalost hesla v případě WPA, jenže to právě vznáší ty otázky, jak to funguje.

27

/dev/null / Různý EHLO string

« kdy: 06. 02. 2023, 15:04:10 »

Mimochodem, když odesílám e-mail přes STARTLS, Tak po tomto příkazu (EHLO,STARTTLS,EHLO,MAIL FROM) zase se začíná od EHLO.  Jaká je praxe při kontrole EHLO, pokud se použije pokaždý jiný EHLO string (ano, nedává to smysl...), kontrolují se obě nebo jen tam první nebo ta po STARTTLS nebo stačí když vyhoví jedna?

Mě šlo poslat mail na  příchozí SMTP server  i když nemám RDNS záznam. ani dokonce když EHLO neodovídá mé doméně. A došel

 The IP address sending this 550-5.7.25 message does not have a PTR record setup, or
the corresponding
 forward DNS entry does not point to the sending IP.
As a policy,  Gmail does not accept messages from IPs with missing PTR records.

Dávání jednořádkového dlouhého textu do CODE není uplně friendly.

28

Sítě / Může switch nebo router spojovat fragmenty TCP?

« kdy: 06. 02. 2023, 00:37:35 »

TLDR: to sítě vstupují IP  pakety o délce 576, ale na počítač jdou o délce 576,1110,1624,2148 a 2672. matematicky to sedí, stačí odečíst 20, odečíst 32 a vydělit 524.

Všiml jsem si zvláštní věci, jde o normální DASH video přes HTTPS přes port 443-TCP přes IPv4, z české televize, které občas dělá problémy (někdy se přehrávání   webu zadrhne- pozoruji, že to je skoro vždy když  příchozí IP pakety o délce výhradně 576b chodí až do stroje, ale o tom to dnes nebude  ). přehrávalo se to teď ne na webu, ale v přehrávači videí, a všiml jsem si ,že conntrack na bráně ukazoval  350 řádků spojení k romuto serveru, ale nethogs, že aktivních jich bylo tak 10 (mezi 10 a 180 kB/s).
Síť: (wifi)brána(ethernet) ---  (ethernet)Wifi-AP(br0:wifi+eth) --- switch --- počítače

brána je RPi, wifi-ap je tzv. wifirouterkombo, už několik let staré, ale relativně vyšší střední třída s Gigabit porty, DSLWAN(deaktivovaným) a switch je  takový nejlevnější gigový 4portový .

Příchozí rámce  do brány mají délku 590b (14+20+32+ 524)b, bez těch 14 to je těch 576.
Poznámka TCP má hlavičku 32 b oproti normální 20 (ecn,ecr+padding).
Odchozí rámce z brány taky.
Příchozí rámce do počítače jsou modifikované, je to spektrum paketů o asi 5 vellikostech a nejpodivnější na tom je, že má i velikost přesahující 1500b.

Trochu ve stínu zustal wifi ap router, vše je zapojeno v LAN portech. Má sice programy ip, jádro 2.6 z roku 2016(?nesoulad), ale prihlašuju se na něj přes telnet. Nemá binárku conntrack, ale  shell sh a  příkaz cat /proc/net/nf_conntrack
 hlásí jen spojení na telnetu, takže se dá předpokládat že jenom bridguje. kromě toho iptables -L {nat,mangle,filter,raw} nic moc, mangle prázdný, raw neexistuje, nat prázdný . filter má nulové čítače kromě inputu. a input  má jen 24 MB dat na -i bridge -j ACCEPT a to asi taky nic není, takže asi jenom fakt bridguje ....

SWITCH:
Předpokládám, že stále platí, že switch maximálně ví, že podle ethertype to jsou IP pakety ale dál s nimi nic nedělá, o IP vrstvu, natož TCP se nestará . Je to hloupý switch bez managementu.

WIRESHARK:
Snad ani wireshark nedělá žádnou magii v prezentaci paketů. Nikde nemám nic jako  záložky Packet / reassembled frame,  ani. IP pakety nejsou fragmentované


Pakety jsem sniffoval přes wireshark, ale sekvenčně pokaždé na jiném konci. (Ideální by bylo souběžně na rozhraní any na všech prvcích.... a zkorelovat je, ale nejsem CSIRT )
Kromě toho je tam nějak modifikované WIN size u na vstupuju bylo něco kolem 500-650 ale u těch modifikovnaných na stanici je10880 .

Proč k některým zdrojům dojde v původní podobě  (jen 576)?
Druhá zvláštnost je MTU.... jakko kdyby neexistovalo., koncová stanice, brána mají v ip address uvedené MTU 1500, router taky(u bridge,eth i wifi)
na jakém prvku dochází k té změně?
Není to třeba tcp offloading, který právě tcpdump nemá šanci zachytit?

Někd nějaké nápady, jak zjistit, co a kde se děje?

29

Hardware / Může uspání jader CPU způsobit problém?

« kdy: 05. 02. 2023, 18:52:57 »

Máte někdo zkušenost, že by příkaz vypnutí  jednoho nebo několika CPU v linuxu
   přes

Kód: [Vybrat]

echo 0 | sudo tee /sys/devices/system/cpu/cpu#/online

mohl po uspání do RAM a následném probuzení způsobit problém že se se něco pokazí? myslím tím třeba zatuhnutí  při uspání, při probuzení, samo-reset, nebo že se prostě zasekne a vypne (při sleep nebo probuzení)

30

Sítě / V jednom směru jde IPv6 ping jen s %wlan0

« kdy: 04. 02. 2023, 23:54:24 »

Vše podstatné jsem se sznažil vměstnat do názvu. Mám 2 počítače spojené switchem (technicky jeden přes ethernet, druhý přes wifi, ale je "wifi router" to bridguje ), oba link local adresy. Z žádného rozhraní neodejdou žádné pakety

Problém je ,ten, že ping na ipv6 adresu u z druhého na první jde jen  uvedení -I wlan0 nebo %wlan0 za adresou? (I když  chvíli dřív jsem měl pocit, že -I wlan0 taky nefunfovalo)
Proč?
(Chápal bych to třeba obráceně, z  počítače, který má těch rozhraní hafo a ne z tohoto který má jedno)

Situace je symetrická až na  trošku jiný tvar ip adres. a počet rozhraní každého pc., a způsobu "setupu" a taky že v výpisu ip se ukazuje noprefixroute(nevím co to znamená a jestli to něčemu vadí) a u druhého ne
tady jsou výpisy, slovní popis jsem dal do citace(je to ukecané)

Kód: [Vybrat]

#druhý:
#druhá půlka ipv6 je skoro mac adresa#
ip -6 a show wlan0 ## druhý
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 fe80::8737:b5ee:87f4:9caa/64 scope link !!!! noprefixroute !!!!
       valid_lft forever preferred_lft forever
ip neigh
fe80::bbbb:bbff:fe5d:3333 dev wlan0 lladdr b9:bb:bb:5d:33:33 DELAY

## první
#mac adresa a ipv6 nemají nic sp lečného
ip -6 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::baaa:aaff:fe5d:3333/64 scope link 
       valid_lft forever preferred_lft forever
ip neigh
fe80::8737:b5ee:87f4:9caa dev eth0 lladdr 00:1f:cf:51:a4:30 DELAY

Ping:

Kód: [Vybrat]

první na druhý, není potřeba %wlan0 ani -Iwlan0
ping fe80::8737:b5ee:87f4:9caa
PING fe80::8737:b5ee:87f4:9caa(fe80::8737:b5ee:87f4:9caa) 56 data bytes
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=1 ttl=64 time=2.02 ms
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=2 ttl=64 time=2.02 ms
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=3 ttl=64 time=2.10 ms

druhý-první
ping  fe80::babb:bbff:fe5d:3333 
PING fe80::babb:Bbff:fe5d:3333(fe80::bbbb:bbff:fe5d:3333) 56 data bytes
^C
--- fe80::babb:bbff:fe5d:3333 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1022ms

ping  fe80::bbbb:bbff:fe5d:3333 -I wlan0
ping: Warning: source address might be selected on device other than: wlan0
PING fe80::bbbb:bbff:fe5d:3333(fe80::ba27:bbff:fe5d:3333) from :: wlan0: 56 data bytes
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=1 ttl=64 time=10.2 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=2 ttl=64 time=2.56 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=3 ttl=64 time=8.17 ms
^C
--- fe80::bbbb:bbff:fe5d:3333 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

ping  fe80::bbbb:bbff:fe5d:3333%wlan0
PING fe80::bbbb:bbff:fe5d:3333%wlan0(bbbb:bbff:fe5d:3333 %wlan0) 56 data bytes
64 bytes from fe80::bbbb:bbff:fe5d:3333 %wlan0: icmp_seq=1 ttl=64 time=9.07 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333 %wlan0: icmp_seq=2 ttl=64 time=7.44 ms

první (ten kabelem připojený) má debian a původě provozuju bez ipv6, headless, tudíž tam jsou ty síťové daemony povypínané, ale grafický seat tam stejně běží,  síť je konfigurovaná ručně (původně bez ipv6), až navíc jsem přidal ipv6 adresu eth0 rozhraní pouze tím, že jsem povolil sys sysctl net.ipv6.conf.eth0.disable_ipv6  a tím na eth0 mu přibyla fe80:: adresa.  forwarding je disabled. . Má přiřazenou ip fe80::MmAA:CCFF:FEMM:AACC (v podstatě vnořená mac adresa až na nějaký xor) . má wireguardy(žádné fe80: s ipv6, wifi, eth0, lo,. ipv6 je na wg,lo, a teď nově i na eth0
druhý (ten připojený přes wifi) má  Ubuntu "jammy" a  připojen je klasicky přes nework manager v liště ,, s výchozím nastavením, prostě nalezena wifi : ipv6 settings automaticky., má jediné aktivní rozhraní wifi+lo