151
/dev/null / vysvětlení generací útočných krajin
« kdy: 13. 09. 2022, 17:59:23 »
Co je fifth generation attack landscape? 4,3,2,1 dtto ajsme u dál za pětkou?
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.
152
Vývoj / Re:Filtrování spamu a scamu na mail serveru
« kdy: 12. 09. 2022, 23:59:44 »
Staci si includovat projekt phpmailer a
Poslat mail je asi na 8 řádků (new PHPMailer,prijemci,subj,from,body,cíl,send())
Umí i dkim i smtp plain, ssl i star(t)tls
Jen pozor, nastaveni tls je ponekud divne(neintuitivni) v tom smyslu ze je dobre se presvedcit, ze to pravdu jde zasifrovane
Poslat mail je asi na 8 řádků (new PHPMailer,prijemci,subj,from,body,cíl,send())
Umí i dkim i smtp plain, ssl i star(t)tls
Jen pozor, nastaveni tls je ponekud divne(neintuitivni) v tom smyslu ze je dobre se presvedcit, ze to pravdu jde zasifrovane
153
Vývoj / Re:Filtrování spamu a scamu na mail serveru
« kdy: 12. 09. 2022, 22:56:15 »
8 stránek, 9 dní, 10 nocí, nechcete z toho sepsat knihu? (Když tam nebudou příspěvky Franze Jorseka, by to byl i sešítek)
Timto zpusobem si pošleš mail tak leda na svuj mailserver,kdyz na nem vypnes antiochrany a kontroly (přehánim, ale nějak tak to je). Vtipné je, že na seznam.cz takto doručovat jde.
Souhlasím, jako kdyby to psal Filip Jirsák (tu odpověď, co psal M.Poljak))
Timto zpusobem si pošleš mail tak leda na svuj mailserver,kdyz na nem vypnes antiochrany a kontroly (přehánim, ale nějak tak to je). Vtipné je, že na seznam.cz takto doručovat jde.
Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
Zrovna tohle vlákno je efektně jižansky hysterické a teatrální nemluvě o tom, že působí značně grafomanicky. O co méně skutečného pochopení a obsahu, o to více řevu. Pán měl evidentně ...
Souhlasím, jako kdyby to psal Filip Jirsák (tu odpověď, co psal M.Poljak))
154
/dev/null / reklamština: význam 100% odezva(inet.připojení)
« kdy: 06. 09. 2022, 18:08:21 »
Co u internetového připojení(nabídka na webu) znamená buzzwěta "téměř 100%" odezva?
155
Software / obrana proti instalace stejné aplikace z f-droid a update přes apk/ručně?
« kdy: 26. 08. 2022, 13:36:56 »
Věděl by, někdo proč s tím jsou takovéhle TRUMPOTY s těmi repozitáři, zdroji , původy a aplikacemi ? Proč prostě nejde otevřít apk a nainstalovat (nepočítám nastavení systému "Aplikace, ze kterých lze povolit instalaci" nebo něco na ten způsob, musel jsem povolit "Správce souborů", když jsem si na SD kartu přesunul apk z disku a instaloval z výchozího filebrowseru.)
Nemá s tím dočinění nějaká politika repozitářů nebo aplikací oprávněných k instalaci ? Nebo nějak android si poznamená, jakým způsobem byla aplikace instalovaná a když narazí na pokus instalovat stejnou aplikaci ("org.schwabi.notes") která už je instalovaná jiným způsobem (manálně soubor, přesadb, přes f-droid aplikaci, přes google play repozitář přes google play aplikaci , přes google play repozitář přes aplikaciAurora store - je v těchto dvou rozdíl?, g-droid) a narazí na rozpor (první repozitář, pokus o reinstal manuálně), vyhodí to tuto chybu? Nebo F-droid nějak pozmění parametry instalace, že druhá instalace se nezdaří (například stejný název, ale prefixovaný název "f-droid.org.schwabi.notes) nebo jiný parametr??
Pokud to je pravda (A není to jiný bug) , jaký to má smysl, kromě otravování uživatele?
Nemá s tím dočinění nějaká politika repozitářů nebo aplikací oprávněných k instalaci ? Nebo nějak android si poznamená, jakým způsobem byla aplikace instalovaná a když narazí na pokus instalovat stejnou aplikaci ("org.schwabi.notes") která už je instalovaná jiným způsobem (manálně soubor, přesadb, přes f-droid aplikaci, přes google play repozitář přes google play aplikaci , přes google play repozitář přes aplikaciAurora store - je v těchto dvou rozdíl?, g-droid) a narazí na rozpor (první repozitář, pokus o reinstal manuálně), vyhodí to tuto chybu? Nebo F-droid nějak pozmění parametry instalace, že druhá instalace se nezdaří (například stejný název, ale prefixovaný název "f-droid.org.schwabi.notes) nebo jiný parametr??
Pokud to je pravda (A není to jiný bug) , jaký to má smysl, kromě otravování uživatele?
156
Sítě / Re:praktický význam SNAT --to s jednim portem
« kdy: 26. 08. 2022, 13:28:27 »Pro jeden port mě využití nenapadá, ale pro CGNAT se může používat rozsah portů cca 256/zákazník.Rozumím, ale jde o stejný use case jako NAT v podstatě. (a toto je směr "ven")
protože spojení je určeno čtveřicí (zdrojová a cílová IP adresa, zdrojový a cílový port) a obecně není služba svázána s žádným portemNo to sice teoreticky není, i se to tak dělá, že si někdo přehodí ssh mimo 22 nebo rozjede víc http servrů odlišených porty (když nejde použív agregace virtualhostů nebo vícnásobný listen, prostě třeba různé implementace), ale prakticky se pokaždé na web lidi připojují na port 443 nebo sdílení windows samba taky předpokládá nějaký 139 nebo 445 (je jich víc) .
Možná tady je jádro pudla. Je použití SNAT takové, které s tímhle nějak souvisí?
157
Sítě / gullo.me 20 portů sr nedá považovat za řešební
« kdy: 25. 08. 2022, 01:17:48 »
Ale tohle není ani ip-adresa-invalida , to je ohlodaná kost,nějakých 20 náhodných portů co mi laskavě ta služba prodá.
Neříkám.že mě to ale nezaujalo, je to zajímavé pro nějké use case ośatně veřejná ip by stályy ty 2ažtři doláče za měsíc ne?
Taky mě zaujal localtunnel.me
Neříkám.že mě to ale nezaujalo, je to zajímavé pro nějké use case ośatně veřejná ip by stályy ty 2ažtři doláče za měsíc ne?
Taky mě zaujal localtunnel.me
158
Sítě / Praktický význam SNAT --to s jedním portem
« kdy: 24. 08. 2022, 21:46:00 »
Má nějaký praktický využití iptables -I POSTROUTING -t nat --to xxx.xxx.xxx.xxx:jeden_port?
Kdy tonajde uplatnení ? U local → ven nebo zvenku→na.local nebo při forwardingovaní
Mám pocit že to znemožní souběžná připojení pro každou IP a danou službu(fixní port jelikož socket je tuple ip1,port1,ip2,port2) a jeden port je tedy zabrán (např 80), ip adresu má počítač jednu(předpoklad), druhý port je omezen-určen tímto pravidlem a zbývá tedy jen ta ip adresa druhého konce (schválně jsem to psal aniž bych předpokládal směr komunikace NAT-odchozí vs forwardovování-někam-příchozí. Ano vím,že když se řekne SNAT(typ pravidla), náskočí NAT(maškaráda, natování u providera))
Kdy tonajde uplatnení ? U local → ven nebo zvenku→na.local nebo při forwardingovaní
Mám pocit že to znemožní souběžná připojení pro každou IP a danou službu(fixní port jelikož socket je tuple ip1,port1,ip2,port2) a jeden port je tedy zabrán (např 80), ip adresu má počítač jednu(předpoklad), druhý port je omezen-určen tímto pravidlem a zbývá tedy jen ta ip adresa druhého konce (schválně jsem to psal aniž bych předpokládal směr komunikace NAT-odchozí vs forwardovování-někam-příchozí. Ano vím,že když se řekne SNAT(typ pravidla), náskočí NAT(maškaráda, natování u providera))
159
Windows a jiné systémy / Re:Potplayer nezvládá přehrávání souborů ProRes
« kdy: 24. 08. 2022, 07:06:48 »
To by byla prča, kdyby ten ffmpeg prores dekodér v potplayeru byl stejný jako dekodér v balíku ffmpeg+ffplay 
Řeší dekodér i čtení /přístup k zdrojovému videosouboru?
Řeší dekodér i čtení /přístup k zdrojovému videosouboru?
160
Windows a jiné systémy / Potplayer nezvládá přehrávání souborů ProRes
« kdy: 22. 08. 2022, 14:19:42 »
Na Windows jsem zpozoroval při přehrávání ProRes souborů (700Mbps) v přehrávači PotPlayer jeden problém. Domnívám se, že jde problém PotPlayeru, jelikož ffplay \\unc\gigasoubor.mov tím netrpí (traffic je kolem850 Mbps). Frčim samozřejmě na Gigabitu.
Jakmile otevřu soubor v PotPlayeru, začne se trhaně přehrávat , jelikož traffic je 400-600 (spíš 470))Mbps, což obviously na bitrate nestačí. Jakmile dám Pauzu, traffic vzroste k 700-900 Mbps a soubor se dotáhne a následně je přehrávání OK. Problém se vyskytuje i při maximální frekvenci CPU. OS je WINDOWS 10 .
Je někdo, kdo by s tím dokázal poradit, zná trochu program PotPlayer ??
Zkoušel jsem nastavení Obecné - Otevírat soubor pomocí pracovního vlákna ON/OFF aSpráva FIltru-preferences builtin - Přednačtení OFF/ON. a dokonce i změna filtru pro MOV z builtin na ffmpeg (pomocí ctrl F1 ověřil že (1)Source se liší ), ale nic nepomohlo. (vždy jsem pak otevřel další soubor v řadě)
Zvláštní je ,že vytížení CPU (4jádro+HT) je 25%
když se to seká (450Mbps traffic + sekáané hraní)
.Nezávisle na volbách výše .. Když soubor do načtu cpu load je55%. Díval jsem se do htreads, vytěžují 4% (maálo??) mscvt!enthreadEx ...
Gigovka je nativní intelu. Přehrává to ffmpeg prores dekodér. ale jak říkám , kdž otevřu soubor, načítá to 450, dám pauzu na pár sekund, skočí to na 800, soubor se donačte a hraje to plynule.
Jakmile otevřu soubor v PotPlayeru, začne se trhaně přehrávat , jelikož traffic je 400-
Je někdo, kdo by s tím dokázal poradit, zná trochu program PotPlayer ??
Zkoušel jsem nastavení Obecné - Otevírat soubor pomocí pracovního vlákna ON/OFF aSpráva FIltru-preferences builtin - Přednačtení OFF/ON. a dokonce i změna filtru pro MOV z builtin na ffmpeg (pomocí ctrl F1 ověřil že (1)Source se liší ), ale nic nepomohlo. (vždy jsem pak otevřel další soubor v řadě)
Zvláštní je ,že vytížení CPU (4jádro+HT) je 25%
když se to seká (450Mbps traffic + sekáané hraní)
.Nezávisle na volbách výše .. Když soubor do načtu cpu load je55%. Díval jsem se do htreads, vytěžují 4% (maálo??) mscvt!enthreadEx ...
Gigovka je nativní intelu. Přehrává to ffmpeg prores dekodér. ale jak říkám , kdž otevřu soubor, načítá to 450, dám pauzu na pár sekund, skočí to na 800, soubor se donačte a hraje to plynule.
161
Sítě / WireGuard: musí allowed-ips být shodné?
« kdy: 22. 08. 2022, 10:56:48 »
V návodech jsem četl, že wireguard jako jakýsi "klíč" využívá" ip adresu a allowed-ips hodnotu pro nějaké určení.
A pokud to chápu správně, tak je to jednoduše řečeno, které adresy mohou téct od daného peera(nevyhovjící neprospustí) a jaké adresy mohou téct "k " danému peerovi (Otázka, mám to chápat spíš jako routování nebo filtrování)? Já to chápu jako routování, vybrání, na kterého peera paket poslat a až když žádný nevyhoví, paket se neodešle(filtrování je asi nepřesné)
Čili jinak - v směru od peera: filtrování příchozích IP podle seznamu allowed-ips,, odchozí směr: filtrování?a?nebo?routing). Samořejmě jde o routing uvnitř tunelu, jelikož z pohledu z vyšší úrovně(bez uvážení wireguardu) vše je routováno na wg0 - bez rozlišení peerů
Hlavní dotaz
Moje otázka je, musí být allowed-ips shodné (na obou peerech shodná hodnota 10.1.0.64/28 & 10.1.0.64/28 nebo i případně 10.1.0.64/28 & 10.1.0.64/28,192.168.0.0/24)
a nebo stačí slabší podmínka, aby prostě protější IP adresa byla uvnitř masek allowed-ips ?
Například
Peer 1: IP 10.1.0.81/24* . Peer 2: 10.1.0.73/24*.
Allowed ips: peer 1 10.1.0.72/29, peer 2 10.1.0.80/30
* hvězdička značí, že jde o konfiguraci ip adresy podle ip addr set ... dev wg0, a ne allowed-ips
Bude to v principu fungovat?
A pokud to chápu správně, tak je to jednoduše řečeno, které adresy mohou téct od daného peera(nevyhovjící neprospustí) a jaké adresy mohou téct "k " danému peerovi (Otázka, mám to chápat spíš jako routování nebo filtrování)? Já to chápu jako routování, vybrání, na kterého peera paket poslat a až když žádný nevyhoví, paket se neodešle(filtrování je asi nepřesné)
Čili jinak - v směru od peera: filtrování příchozích IP podle seznamu allowed-ips,, odchozí směr: filtrování?a?nebo?routing). Samořejmě jde o routing uvnitř tunelu, jelikož z pohledu z vyšší úrovně(bez uvážení wireguardu) vše je routováno na wg0 - bez rozlišení peerů
Hlavní dotaz
Moje otázka je, musí být allowed-ips shodné (na obou peerech shodná hodnota 10.1.0.64/28 & 10.1.0.64/28 nebo i případně 10.1.0.64/28 & 10.1.0.64/28,192.168.0.0/24)
a nebo stačí slabší podmínka, aby prostě protější IP adresa byla uvnitř masek allowed-ips ?
Například
Peer 1: IP 10.1.0.81/24* . Peer 2: 10.1.0.73/24*.
Allowed ips: peer 1 10.1.0.72/29, peer 2 10.1.0.80/30
* hvězdička značí, že jde o konfiguraci ip adresy podle ip addr set ... dev wg0, a ne allowed-ips
Bude to v principu fungovat?
162
Sítě / "nat vps" -doporučte
« kdy: 22. 08. 2022, 10:37:32 »Mělo by to jít udělat i bez VPN (ale stále musíte mít nějaký Linux s veřejnou IP - prodávají se tzv. "NAT VPS" za cenu třeba $1 měsíčně),
Sháním takového. Máte tip?
163
Sítě / (B)SSID na dvou různých kanálech
« kdy: 15. 07. 2022, 16:24:20 »
Nevím čím to je , ale jednu dobu mi počítač viděl dvojmo(jen se lišili kanály (1(2412MHz) a 5(2432MHz)):
Asi na půl dnes se stalo, že debian viděl wifi jakoby dvakrát na kanále 1 a na kanále 5, identické SSID i BSSID. Výstupy různých nástrojů hlásily kanál 1 a jiné 5 (ale konzistentně v čase).
Zároveň v tu doby bylo spojení pomalejší - max 4Mbps místo 48 Mb/s (limitované 802.11n 1T1R 20Mhz spojem), i RX i TX se pohybovalo v mezích 1 3 5 Mbps (link speed)
Například iw wlan0 link jednička, iw wlan0 info pětka, wavemon v bloku Info jednička, iwconfig pětka. WAVEMON v tabu Scan ukazoval danou síť 2x (s oběmi čísly kanálu) (V posledním sloupci bylo ESS)
Čím to může být? Jako vím, že může být šířka kanálu 40 Mhz ,ale to u této sítě nikdy nebylo
Podotýkám, že nikdy se mi tohle nestalo ještě.
Další dlůležitá věc, všiml jsemsi že wifina mění kanály v čase a hlavně po KILLnutí wpa.supplicanta a spuštění se to opravilo
Dokonce jsem si uložil i v tu dobu iw wlan0 scan výstup. Vyřízl jsem záznamy a udělal jejich diff. Last seen (první výskyt je5dnů ago identický)
Liší se jen v:
- Úvodní řádek BSS <mm:aa:cc:mm:aa:cc> (on wlan0) - u prvního je associated navíc
- freq: 2412 resp 2432
- signal (o 2dB)
- last seen(druhý výskyt): 4hod ago vs 0 ms ago
- DS Parameter set :5 resp 1
-secodary channel offset: below resp "no secondary"
- STA channel width any vs 20 MHz
ERP: Barker_Preamble_Mode+<noflags>(dvakrát) vs <no flags>(jednou)
Pokud udělám diff mezi současným výstupem iw wlan0 scan a tahdejším(tím se správným chennel), tak jsou identické až na ...ASSOCIATED(asi byl hokej v tom, ke které byl připojen, ) a signal lišící se o 2dB(fluktuace)
Asi na půl dnes se stalo, že debian viděl wifi jakoby dvakrát na kanále 1 a na kanále 5, identické SSID i BSSID. Výstupy různých nástrojů hlásily kanál 1 a jiné 5 (ale konzistentně v čase).
Zároveň v tu doby bylo spojení pomalejší - max 4Mbps místo 48 Mb/s (limitované 802.11n 1T1R 20Mhz spojem), i RX i TX se pohybovalo v mezích 1 3 5 Mbps (link speed)
Například iw wlan0 link jednička, iw wlan0 info pětka, wavemon v bloku Info jednička, iwconfig pětka. WAVEMON v tabu Scan ukazoval danou síť 2x (s oběmi čísly kanálu) (V posledním sloupci bylo ESS)
Čím to může být? Jako vím, že může být šířka kanálu 40 Mhz ,ale to u této sítě nikdy nebylo
Podotýkám, že nikdy se mi tohle nestalo ještě.
Další dlůležitá věc, všiml jsemsi že wifina mění kanály v čase a hlavně po KILLnutí wpa.supplicanta a spuštění se to opravilo
Kód: [Vybrat]
iw wlan0 info
Interface wlan0
ifindex 3
wdev 0x1
addr mm:aa:cc:mm:aa:cc
ssid Datel
type managed
wiphy 0
channel 1 (2412 MHz), width: 20 MHz, cent
er1: 2412 MHz
txpower 13.00 dBm
$ iw wlan0 link
Connected to mm:aa:cc:mm:aa:cc (on wlan0)
SSID: Datel
freq: 2432
RX: 1543708522 bytes (9346723 packets)
TX: 193582060 bytes (2381008 packets)
signal: -73 dBm
rx bitrate: 5.5 MBit/s
tx bitrate: 65.0 MBit/s
bss flags: short-slot-time
dtim period: 1
beacon int: 100Dokonce jsem si uložil i v tu dobu iw wlan0 scan výstup. Vyřízl jsem záznamy a udělal jejich diff. Last seen (první výskyt je5dnů ago identický)
Liší se jen v:
- Úvodní řádek BSS <mm:aa:cc:mm:aa:cc> (on wlan0) - u prvního je associated navíc
- freq: 2412 resp 2432
- signal (o 2dB)
- last seen(druhý výskyt): 4hod ago vs 0 ms ago
- DS Parameter set :5 resp 1
-secodary channel offset: below resp "no secondary"
- STA channel width any vs 20 MHz
ERP: Barker_Preamble_Mode+<noflags>(dvakrát) vs <no flags>(jednou)
Pokud udělám diff mezi současným výstupem iw wlan0 scan a tahdejším(tím se správným chennel), tak jsou identické až na ...ASSOCIATED(asi byl hokej v tom, ke které byl připojen, ) a signal lišící se o 2dB(fluktuace)
164
Windows a jiné systémy / Skrytí SSID hotspotu na Androidu
« kdy: 09. 07. 2022, 07:45:36 »
Potřebuji na (root)Androidu11 skrýt ssid hotspotu. Jak nato ? Předpokládám,že 8let stará odpověď na stack overflow už není uplně aktuální. (hostapd tam tam není : which hostapd )
165
Hardware / HDMI vs DisplayPort náročnější na součástky?
« kdy: 07. 07. 2022, 14:04:34 »
Je Displayport nebo HDMI (jako celek počítač-kabel-monitor) náročnější na součástky a případně na jakém konci (zdroj a nebo monitor)?
Jde o to, že HDMI (do 2.0a) využívá konkrétní frekvenci pixel clock, ale Displayport několik fixních frekvencí, případně počet lanes. V tom vidím fundamentální rozdíl a laicky bych řekl, že v případě HDMI bude monitor jednodušší (jde tam prostě signál o správné frekvenci).
V případě displayportu všeljaké buffery, fázové závěsy, encodéry a decodéry.
Je to tak, že celé řešení přes DP je ve všech částech náročnejší než HDMI?
(Tím pádem v HDMI zdrojitam musí být ve zdroji někde "součástka" nastavující příslušnou frekvenci ale myslím, že to je řádově levnější než DP encodér/dekodér)
Jde o to, že HDMI (do 2.0a) využívá konkrétní frekvenci pixel clock, ale Displayport několik fixních frekvencí, případně počet lanes. V tom vidím fundamentální rozdíl a laicky bych řekl, že v případě HDMI bude monitor jednodušší (jde tam prostě signál o správné frekvenci).
V případě displayportu všeljaké buffery, fázové závěsy, encodéry a decodéry.
Je to tak, že celé řešení přes DP je ve všech částech náročnejší než HDMI?
(Tím pádem v HDMI zdrojitam musí být ve zdroji někde "součástka" nastavující příslušnou frekvenci ale myslím, že to je řádově levnější než DP encodér/dekodér)
