Poslední příspěvky

1

Sítě / Re:Rozdíl mezi REJECT a DROP ve firewallu

« Poslední příspěvek od jjrsk kdy Dnes v 10:26:39 »

Bavime se o odchozim provozu (OUTPUT) tzn chceme zakazat klientovi se nekam pripojit nebo serveru na nejaky provoz odpovedet ....

Tzn vzdy by tam mel byt REJECT... jednoduse proto ze je to nas stroj, a tudiz chceme aby reagoval co nejrychleji.

Smerem zvenku (INPUT) je to spis opacne. V tomhle pripade drop omezuje zatizeni linky + pripadne posilani rejectu na skutecny cil utoku.

2

Hardware / Re:Redukce USB-C na USB-A

« Poslední příspěvek od Vít Šesták (v6ak) kdy Dnes v 10:16:45 »

Přemýšlím, jak otestovat tu redukci (USB-A samec, USB-C samice). Měl bych multimetr a nějaký breakout board pro USB C, u USB A bych měl být schopen měřit přímo z konektoru i bez breakout boardu. Bude stačit ověřit, že Vcc není u nepřipojené redukce průchozí?

3

Sítě / Re:Rozdíl mezi REJECT a DROP ve firewallu

« Poslední příspěvek od Ivan Brezina kdy Dnes v 09:42:04 »

Pokud jde o ICMP tak existuje doporuceni NIST ktere vyjmenovava ICMP zpravy ktere by se nemely dropovat.
Z hlavy si pamatuju jen ICMP host unreachable.
I nas v praci se nejaci mozkovi giganti ze security rozhodli zahazovat kompletne vsechno ICMP vsude na vnitrni siti a to se pak dely veci. Hlavne systemy ktere mely nakonfigurovane HA mely problemy, umrely na timeout protoze cekaly dlouho na pripojeni do databaze.

4

Sítě / Re:Rozdíl mezi REJECT a DROP ve firewallu

« Poslední příspěvek od Tom5 kdy Dnes v 09:22:24 »

Osobně dávám všude REJECT a povoluji/nezakazuji ICMP. IMHO DROP útočníkům nic nestěžuje a pro mne je důležitější funkční služba a jednodušší správa.

5

Windows a jiné systémy / Re:Windows odmítá naformátovat n-tý oddíl na flashce

« Poslední příspěvek od tester3274 kdy Dnes v 08:44:25 »

Neni co opravovat (ani "opravovat"). Microsoft Windows je uzavrena platforma, pokud to nevite.

Jak to souvisí se skutečností, že core Microsoft komponenta WinAPI plně nepodporuje všechny funkce jiné core Microsoft komponenty NTFS?

Jake specifikace?

Pochopitelně ty co Microsoft zveřejnil. Snažíte se to okecávat marně. Diskutovaná funkcionalita je veřejně známá desítky let. To, že ntfs3 nepodporuje nějakou undocumented nebo secret feature je především problém samotného Microsoftu - je to jejich produkt. Kdyby chtěli, tak tu podporu naimplementují. Nikdo to za ně dělat nebude zejména proto, že mimo Widle nikdo příčetný NTFS používat nebude (navíc moderní FS jsou dnes někde úplně jinde)  a pro specifické případy "migrace" dat současný stav dostačuje.

No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet

To vskutku brilantní dedukce. Aby uživatelé Windows "netrpěli", tak vývojáři Linux kernelu by měli něco opravit

NTFS podporuje POSIX namespace, je to jeho standardní funkce, proto se při pripojení k POSIX OS používá. Ostatně tak si to MS sám navrhnul. Problém je čistě na straně WinAPI, které z nějakého důvodu nedokáže v rámci NT namespace s POSIX subsystemem pracovat. Tenhle problém je čistě na straně MS a jeho opravy se asi nedočkáte.

Jediné, na čem se asi shodneme je fakt, že přepínač "windows_names", který byl jako mount option dlouho k dispozici už v ntfs-3g by z praktického hlediska mohl/měl být výchozí. Ale to je workaround a nikoliv řešení problému. který leží někde úplně jinde.

6

Windows a jiné systémy / Re:Windows odmítá naformátovat n-tý oddíl na flashce

« Poslední příspěvek od Marek Staněk kdy Dnes v 07:40:39 »

Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.

No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet

Define "běžný uživatel". Podle mojí zkušenosti "běžný uživatel", který přechází mezi woknama a linem, má soubory buď na serveru (kam z woken leze SMBčkem a z lina většinou taky, výjimečně NFS), nebo na přenosným médiu formátovaným v drtivý většině FAT32.

7

Windows a jiné systémy / Re:Windows odmítá naformátovat n-tý oddíl na flashce

« Poslední příspěvek od Marek Staněk kdy Dnes v 07:38:15 »

To je problém MS, že to má "rozbité".

Ale MS to nemá rozbitý. Když si koupíš auto s asistentama (a nový už si bez nich v EU koupit nemůžeš), a nebudeš je z vlastního rozhodnutí používat, znamená to snad, že máš auto "rozbitý"?

8

Windows a jiné systémy / Re:Windows odmítá naformátovat n-tý oddíl na flashce

« Poslední příspěvek od LamZelezo kdy 02. 01. 2025, 23:08:05 »

Všimnul jste si, že od té doby vydali vydali 5 verzi NTFS a v žádné nebyli schopni to "opravit"?

Neni co opravovat (ani "opravovat"). Microsoft Windows je uzavrena platforma, pokud to nevite.

Protože se tradičně drží specifikace? Jakýkoliv jiný přístup vede k totálnímu bordelu. NTFS z rozhodnutí MS je case sensitive podporuje speciální znaky, proto ovladač ntfs3 podporuje totéž. To je problém MS, že to má "rozbité". Úplně totéž platí třeba pro USB disky Seagate, USB/SATA převodník odporuje standardní SATA specifikaci, a driver tak má vypnutý UAS, dokud si to Seagate milostivě neopraví což se už delší dobu neděje.

Jake specifikace? MS uz zverejnil oficialni specifikace? Podporuje ntfs3 ovladac transakce? Quoty? Shadow Copy? Ja jenom, aby nevznikl totalni bordel

Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.

No super, at to teda daji jako vychozi volbu. Jinak bezni uzivatele budou stale trpet

9

Windows a jiné systémy / Re:Windows odmítá naformátovat n-tý oddíl na flashce

« Poslední příspěvek od tester3274 kdy 02. 01. 2025, 21:31:48 »

Protoze design NTFS je odvozen od HPFS a pochazi z doby, kdy se o rade NT teprve koncepcne debatovalo a nebylo rozhodnuto ani jak tesne bude rada NT na OS/2 navazovat ani jak daleko od OS/2 se odvine/odkloni.

Všimnul jste si, že od té doby vydali vydali 5 verzi NTFS a v žádné nebyli schopni to "opravit"?

PS Kdybych se zeptal: Proc linux umoznuje ukladat na cizi souborovy system NTFS soubory s nazvy, ktere jsou na nativnim OS nepodporovane, to by byl ficak, ze jo )

Protože se tradičně drží specifikace? Jakýkoliv jiný přístup vede k totálnímu bordelu. NTFS z rozhodnutí MS je case sensitive podporuje speciální znaky, proto ovladač ntfs3 podporuje totéž. To je problém MS, že to má "rozbité". Úplně totéž platí třeba pro USB disky Seagate, USB/SATA převodník odporuje standardní SATA specifikaci, a driver tak má vypnutý UAS, dokud si to Seagate milostivě neopraví což se už delší dobu neděje.

Mimochodem aktuální ntfs3 ovladač má k dispozici přepínač "windows_names", takže tento souborový systém lze připojit tak, že ovladač vynutí všechna omezení odpovídající WinAPI.

10

Sítě / Re:Rozdíl mezi REJECT a DROP ve firewallu

« Poslední příspěvek od František Ryšánek kdy 02. 01. 2025, 20:32:11 »

> jak se to aplikace dozví

Programujete trochu? Pokud ano, v čem?

Já trochu znám BSD sockets API hezky jak ho pánbůh stvořil = v céčku. Tzn.:
- na straně klienta se TCP spojení navazuje: socket(), connect()
- na straně serveru klasická práce s TCP vypadá takto: socket(), bind(), listen(), accept()
V obou případech dostanete "otevřený file descriptor" - pokud všechna volání skončila úspěchem.
S otevřeným socketem/deskriptorem se dál pracuje pomocí funkcí jako send()/recv(), případně read()/write(), trochu specialita je select() = lze čekat na událost od kteréhokoli z více otevřených socketů ve specifikované množině.
Jsou i nějaké další modernější funkce nad otevřenými sockety (poll(), co já vím co ještě).

Takže pokud se pokusíte otevřít spojení na trase, kde je předem ofiltrováno pomocí REJECT směrem ven, tak Vám na klientu connect() skončí okamžitě chybou, na serveru si nejsem jist - accept() buď skončí chybou, nebo se možná vůbec neprobudí z blokujícího čekání na příchozí TCP relaci.

Pokud byste měl navázané TCP spojení, běžel na něm provoz, a vy byste v tu chvíli vložil pravidlo s REJECTem do iptables, tak Vám selže s chybou nějaký ten send() / recv() a socket se sám zavře / padne do nějakého vadného stavu.

Výše uvedené chování při REJECTu odhaduji pro TCP = když při vytváření socketu specifikujete option SOCK_STREAM.
Jak to vypadá při použití connection-less vrstvy UDP (SOCK_DGRAM) to si nejsem jist.

Okamžitý stav socketu se dá zjistit jednak funkcí getsockopt(), druhak i bez ní jednotlivá výše zmíněná volání "končí chybou" tím způsobem, že v souladu s manuálovou stránkou vrátí "chybovou" návratovou hodnotu (třeba recv() vrací 0 bajtů přijato, jiné funkce mohou vracet přímo chybový kód se znaménkem mínus) - vedle návratové hodnoty bývá současně k dispozici globální proměnná errno, kterou lze interpretovat na textovou zprávu (řetězec) funkcemi strerror() nebo perror()... k tomu všemu jsou v linuxu man pages.