Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - Vietnamka

Stran: [1] 2 3 ... 5
1
Desktop / Nefunguje zvuk v Chrome
« kdy: 29. 05. 2023, 16:26:11 »
Chrome mi nedokáže přehrát zvuky.
- videa bez zvukové stopy mi chrome přehrává OK .
 videa se zvukovou stopou se nepřehrají
- když otevřu file:// zvuk.wav nebo ogg , okénko s progresbarem a stopáží se ukáže ale nic se nepřehrává (identické jako přechozí odrážka)
hlásí  mi chrome(z terminálu):

Kód: [Vybrat]
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
Received signal 11 SEGV_MAPERR 0000000000f2
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242

kde je chyba? před měsícem to šlo. sw jsem neaktualizoval.

2
Server / Smysluplnost "aliasů" v hlavičkách To,Cc
« kdy: 28. 04. 2023, 20:20:45 »
Chtěl bych zde kriticky a revisionisticky probrat užitečnost, a smysl "Jmen" v jednotlivých příjemcích v e-mailové zprávě (MIME Message) v hlavičkách To,Cc,Reply...

Jde o : To: "Petr Pavel" <ruskytrol@media.ru>, Petr Paul <petr@pavel.cz> , "£1b0r Obusek" <chiucpebomber@xgs.cz>, milenka  <zlata@adamovska.cz> (to byl jen příklad)

Dává to v dnešní době smysl?

0. Je to k nečemu dobré reálně?. Odesilatel tuto informaci nepotřebuje, resp. není potřeba ji cpát do přenášené zprávy. Pro Příjemce to může mít jistou, diskutabilní hodnotu

1. Je správná aby MSA hlavičku To: vyčistil? (nechal jen <a@b.dom>)

3. Jak se k tom ustaví MUA(programy), když příjemce má kontakty uložené pod jiným jménem?

4. (podobné trochu 3., ale lišící se)Jak se k tomu staví webmailové MUA(kde může být být podobný Adresář  na straně mailové infrastruktury přijemce, zde je šance, že to bude víc enterprise adresář)
Za druhé, nemůže to sloužit k fingerprintingu, jelikož jednotlivé páry jméno-mail nesou jistou entropii.

3
Server / SMTP: uvádění parametrů a extension až za EHLO
« kdy: 28. 04. 2023, 20:12:45 »
Je možné v SMTP komunikaci na straně serveru
avizovat doplňkové příkazy (typicky 250-.... co avizují přítomnost rozšíření)
až v pozdější fázi, tedy až za BLOK serveru EHLO  ?

MAIL FROM: velky@uploadder.com
250-SIZE 9999999999999999942
250 sender OK

Jsou natoto klienti připraveni, bude to fungovat?

4
Software / tcpdump: výstup bez ecr a ttt bez milisekund
« kdy: 28. 04. 2023, 15:05:16 »
Je mozno nejak v tcdumpu (textovy output)
Nastavit, aby:

-Cas byl v celych sekundach
-- jak absolutni cas ()
--tak delta (při -ttt)
Pripadne cas v celych milisekundach,(integer sec,  float : sec.ms)
-skryt "minuty:"


Neukazovaly se detaily paketu,win,options  (jako noecr,, ts-val), ale v druhem.kole ani ack,seq
Tedy neco jako opak -v,-vv


Dal drobnost: cislo portu oddelene dvojtexkou misto tecky

Tedy :
Z
00:00:58.058516 IP src-dst : Flags [P.], seq 52:104, ack 29, win 11657, options [nop,nop,TS val 2109328276 ecr 3777480036], length 52

Na:
00:58 IP 192.src.0:34102 > dst:22: Flags [P.], (seq 52:104, ack 29, )length 52
Pripadne "58 IP (sekund integer)
(00:)58.26( desitky ms, bez minut i s.minutami, aby tam nebylo 60000 za kazdou minutu)


Cilem je usetrit misto  na terminalu (ma to silenou sirku)


5
Windows a jiné systémy / Zobrazení velikosti SMB disku
« kdy: 26. 04. 2023, 19:21:52 »
Mám otázku do vod windows,... normálně SMB server(třeba druhý počítač).  a dotaz míří pro počítače, které se k smb serveru připojují.  Cesta je např. \\uloziste, konkrétní share \\uloziste\okruh

Je nějaké vysvětlení, proč Total commander(z roku 2015)mi (v cestě \\ulozisko\okruh) normálně napíše v záhlaví Velikost  i volné místo

zatímco průzkumník nic takového ne. Ani po kliknutí - vlasnosti - Velikost se zobrazuje 0 bajtů

(na tom samém PC, Win7)

a linuxová otázka, lze nějak přes příkazovou řádku, jako smbstatus nebo smbcontrol (bez roota) zjistit tutéž velikost obsazeno a volno? (samozřejmě to vidím, když si daný share mountnu přes mount.cifs nebo mount -t cifs, ale nechci mountovat několik bodů abych je hned odmountoval)

6
Software / TLSA kontra SSH
« kdy: 21. 04. 2023, 10:37:01 »
lze pro verifikaci fingerprintu použít záznam TLSA?  Vím, že existuje SSHFP RR, ale ten nemám k dispozici. Umožňuje ssh nějakou volbou ověřit fingerprint právě tímto způsobem?
(s vědomím, že ssh nepoužívá TLS; ssh řeší certifikáty a fingerprinty a hashe "po svém" oproti TLS)  Je to tam nějak "backportováno"?

Případně, existuje patch ssh, který by tento způsob přidal?

(Resp. obecnější dotaz: kde a jak je v stacku implementovaná kontrola TLS, neboli mohou to aplikace kontrolovat specificky svým způsobem? Což by asi byla právě nutnost pro ssh, jelikož ten s TLS protokolem nic společného nemá)

7
je v prohlížeči  (nebo v doplňku ) možné nějak zablokovat url typu webpack:///node_modules/@honeybadge... ?
Ve skutečnosti se načítá (jediný typu javascript )soubor "/assets/javascripts/main.bundle.js" o velikosti 80kB

Případně jaké browsery to umí?

8
Distribuce / Nelze zapsat do sysctl -w kernel.keys.maxbytes
« kdy: 30. 03. 2023, 12:07:12 »
Mám problém spustit kontejner dockervrun hello-world, hlásí mi to temné chyby

Kód: [Vybrat]
docker:
Error response from daemon:
failed to create shim task:
OCI runtime create failed: runc create failed: unable to start container process:
error during container init: unable to join session keyring: unable to create session key:
disk quota exceeded: unknown.

Jde o debian bullseye, instalace z stránek dockeru dle postupu pro debian ( uprava keyring a instalace přes apt-get install )

a hledal jsem problém  narazil na
https://gkellynavarro.com/blog/2020/04/04/container-issues/

radí se tam zapsat

Kód: [Vybrat]
sysctl -w kernel.keys.maxbytes=40000
(nebo do /sys/proc/kernel/keys/maxbytes), pozor v dolním řádku vypadlo kernel v cestě

Ale nemohu tam zapsat. Kde je problém?

df -ih mí hlásí obsazenost inodů 20%, místa 40%.
Případně jak jinak ten docker zprovoznit?

jinak systemd-detect-virt hlásí lxc a dmidecode  že /dev/dmi dev/mem  NO such file a /dev/firmware permission denied

9
Server / RCPT TO na různé domény stejného MX
« kdy: 30. 03. 2023, 01:03:15 »
Z jakého důvodu dostanu tuto chybu při posílání na  MX server aspmx4.googlemail.com   / banner "mx.google.com" ), který obsluhuje, na  příjemců víc na odlišných (@hostovaná a @gmail):

Kód: [Vybrat]
RCPT TO: a@gmail.com
250 OK (prohozené pořadí příjemců nehraje roli)
RCPT TO b@hipsteri.cz
451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
451 4.3.0 try again. z21-....368 - gsmtp

Jiné MX servery s tím nemají problém.

K tomu by mě zajímalo : (asi není potřeba odpovídat na všechny body, některé vyplývají z jiného)
0. Jak je to správně
1. Je toto někde definované v RFC?
2. Porušuje  Gmail standardy?
3. Je seznam  a jiní benevolentní v standardech když dovolí heterogenní RCPT
4. Jakým způsobem se mají chovat MTA .Mohou sdružit různé příjemce do jedné transakce?
5. Znamená, že když ty domény mají stejný MX, tak lze uvést oba příjemce  v jedné SMTP transakci?

10
Pokud si přidám do iptables nějaké pravidla  pro skupin IP adres,pak mi iptables -vL vrátí logicky jeden řádek týkající se té  sady.
Je možné  nějakým způsobem zjistit statistiky (to co je v první a druhém sloupci příkazu výše - počet matchnutých bajtů a paketů) pro každou IP nebo záznam (což je rozdíl) zvlášť , podobně  jako kdyby to byla série pravidel iptables s --source /--dest nějakým způsobem?

Něco jako cat /proc/net/xt_recent/identifikator

tedy něco takového
Kód: [Vybrat]
z
  134  7288 DROP       all  --  *      *       000000000/24       0.0.0.0/0      set: MATCH-SET ssh-grupa      /* ssh--množina */
na:
    1    40 DROP       all  --  *      *       176.111.173.0/24     0.0.0.0/0            /* ssh--l3 */
    0     0 DROP       all  --  *      *       94.20.154.0/24       0.0.0.0/0            /* ssh--l3 */
   40  2400 DROP       all  --  *      *       195.226.194.0/24     0.0.0.0/0            /* ssh--l3 */
   93  3848 DROP       all  --  *      *       62.233.50.0/24       0.0.0.0/0            /* ssh--l3 */
Pochopitelně to nemusí být v tomhle formátu

třeba ten xt_recent má
src=128.199.138.0 ttl: 52  last_seen: 4340684258 oldest_pkt: 25 4340450426,...
src=138.199.134.0 ttl: 126 last_seen: 4340684218 oldest_pkt: 25 4340450426,...


PS: man 8 ipset nemám

11
Sítě / Pakety tečou neNATované do veřejného rozhraní
« kdy: 28. 03. 2023, 21:17:21 »
Zjistil jsem, že mi z nějakého důvodu na WAN rozhraní odchází  pakety, které neprojdou NATováním. tj odejdou 192.168.0.N -> domena.com . Ty paket jsou bezezměny forwardované z interní sítě (Jde o odpověď na SYN pakety přicházejícího z jiného rozhraní) Když už je packet filter nenasměruje do rozhraní odkud přišlo spojení, tak nechápu proč  jim není změněna src adresa pravidlem MASQUERADE

Mám podezření na pravidlo zvýrazněné tučně:


FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -d 192.168.1.0/24 -i wan -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[FORWARD -s 192.168.1.0/24 -i eth0 -o wan -j ACCEPT




Jsou v pořadí odshora dolů první. Nemělo by mít více parametrů --ctstate  který by omezily ACCEPT?

Přitom jde o (v případě policy forward drop) esenciální pravidlo, aby interní síť vůbec mohla iniciovat spojení do internetu.

Pomohlo by pravidlo  -tnat  POSTROUTING -i eth0 -o wan -s 192.168.1:6 -j REJECT ... Jenže REJECT nejde na -tnat

Ale klíčové je odhalit příčinu, proč paket odejde ne-z-MASQUERADEován?


přestože v iptables mám:
*nat
-A POSTROUTING -s 192.168.0.0/24 -o wan -j MASQUERADE



(ip rule s příbuzného dotazu jsem promazal a je ve výchozím stavu )

ip route:
default via 192.168.0.222 dev wlan0
10.0.0.2 dev tun8 proto kernel scope link src 10.0.0.1
192.168.0.222 dev wlan0 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100


12
Zdravec, jak by se  na routeru vnitřní sítě správně řešil  routing  , aby  odchozí pakety nechodily na hlavní rozhraní do internetu ale, přes TUN?  Příchozí spojení pěkně dorazí do zařízení, ale odchozí má tendenci odcházet  špatným rozhraním.
Stručně: je to dím, že nemám v iptables žádné pravidlo FW/CONN/MARK nebo prohibit nebo supressprefix_length?
Obousměrně funkční spojení je funkční pouze  na ip adresu routeru (10.0.0.1) na rozhraní tun. Není funkční na ip rozsah vnitření sítě(ani routeru 192.168.0.222)
Potřebuji zachovat IP adresy remote hostů(takže nejde použít kombo  PREROUTING DNAT 80->192.168.1.9:8080 +  POSTROUTING SNAT  --to-source 10.0.0.2, takže router na vnitřní síti uvidí traffic z vpn rozsahu)
(Rozvedu, toto byl jen stručný úvod)

Na domácím routeru je TUN obsluhované ssh -w 1:2 Vzdálený bod je VPS (IP 1.2.3.4), kde jsou forwardované porty ( iptables -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.9:8080
)

/etc/iproute2/rt_tables : mám "10 vpn"
ip rule: 32765:  from 10.0.0.0/24 lookup vpn

ip route show table vpn
default via 10.0.0.2 dev tun8 (ip samotná je 10.0.0.1)
192.168.1.0/24 via 192.168.1.222 dev eth0

ip link:eth0  =lokální síť, tun =tunel, wan= rozhraní do internetu

Pozorování: Pakety  dovnitř krásně dojdou  (5.4.3.2 je nějaká remote host)

5.4.3.2:54321 -> 1.2.3.4:80 (in: vps-eth0)
5.4.3.2:54321 -> 192.168.1.9:8080 (vps forward out: tun-x, pravidlo -j DNAT)
----
tunel
----
5.4.3.2:54321 -> 192.168.1.9:8080 (router forward in: tun-y)
paket do zařízení v lokální síti
zařízení odpoví  192.168.1.9:8080 -> 5.4.3.2:54321
192.168.1.9:8080 -> 5.4.3.2:54321 (router forward in eth0)
192.168.1.9:8080 -> 5.4.3.2:54321 (router out : wan) - neaplikuje se ani  ip rule from 10.0.0.0/24

Jak routeru říct že tento paket má jít do tun-x a ne do wan  Logicky tam musí být nějaký conntrack, a poznamenat  si že flow z port 54321 přišel z  tun a ne z WAN. Samotné zařízení v síti pak nemá ponětí, že pakety pochazí z WAN

Nebo druhé řešení nějaký prapodivný nat že bych (na VPS) místo -jDNAT 192.168.1.6 dával  -j DNAT 10.99.0.6 a v routeru by se to pak muselo podruhé z natovat pravidlem  10.99.0.Q na  192.168.1.Q?


Co vychází lepe, ten extra-nat nebo nějaký MARK?



(Chci to právě zprovznit na holém tun, tedy ne wireguard).   -jMARK jsem nikdy nepoužíval...
četl jsem toto Policy-based routing v Linuxu: směrování provozu pod kontrolou



---ta funkce " Mezitím vypršelo sezení. Odešlete příspěvek znovu. Tento formulář jste již odeslali je  kvzteku. Už se to stalo zase stalo."  Reload zobrazí samou stránku bez dialogu prohlížeče odeslání POST Dat jelikož je přesměrován na  GET. Tlačítko zpět ho sice zobrazí ale zobrazí se pak čištá formulář

13
Řeším takový záludnější problém se ssh -R který jsem nenašel v man-u ( / -B(ind interface) -b(ind adress),
a sice jak určit ssh klientovy jakou IP použít pro připojení se na cíl tunelu (ne z jaké IP se připojit na sshd démona server, což podle mě dělá -b/-B)

Používám  úspěšně ssh -R  "*:443:192.168.1.20:443", ale chci změnit adresu , z jaké se ssh klient připojuje na   ten
 výstupní endpoint tunelu . 192.168.1.20:443.
pc s ssh klientem má více rozhraní (prvním se připojuje na internet a druhé je LAN) a více ip adres (kromě obvious každé adresy na každém rozhraní  myslím víc ip adres na LAN a tam právě chci provést selekci.).



Přepdpokládám, že zdvojené použití parametru -b nebude fungovat (jako třeba u ffmpeg, kde opakované volby patří ke každému inpu file):

(za předpokladu, že by ssh takto hypoteticky posuzovalo argumenty -b a že ip ssh klienta je 192.168.1.3 na lan a 41.23.22.11 na WAN):
ssh -b 192.168.1.88 -R  "*:443:192.168.1.20:443 -b 41.23.22.11 sshd.com   
(kde 41.23..22.11 je vlastně navíc, jelikož by se mělo vázat na rozhraní do netu a to já měnit nechci - to je stejně jedno)
ale chci změnit  ip adresu ze kterého ssh klient se připojuje na konec tunelu, místo z 192.168.1.3 na 192.168.1.88)

14
Server / Existuje rekurzivní DNS přes šifrovaný kanál?
« kdy: 26. 01. 2023, 11:58:55 »
Je možné  provádět rekurzivní DNS resolvování přes šifrované DNS (over HTTP, TLS)? 
Pokud ano, je v tom nějaký zádrhel a dává to smysl? Představoval jsem si něco jako, že u root serverů změním port na 853 nebo 443...

Pokud ne, kde je problém, v jakém článku řetězu to nepůjde?

15
/dev/null / význam domény sn.pujcka.****.cz
« kdy: 11. 11. 2022, 16:31:09 »
Proč se načítá obrázek /m.png?1475891721 z domény banky https://sn.pujcka.***banka.cz  ,když ve skutečnosti DNS záznam ukazuje na doménu  eq-sp-prod.activate.cz ???
Není v tom nějaká " n e k a l o S T " ?

Stran: [1] 2 3 ... 5