76
Sítě / Re:HW hotové řešení IDS/IPS, security onion
« kdy: 02. 03. 2023, 16:43:32 »
souvisí ten ONION s TOR-em?
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.
77
Sítě / Re:Může switch nebo router spojovat fragmenty TCP?
« kdy: 25. 02. 2023, 18:04:31 »Mimo soutěž / na okraj, zaujala mě zmínka o RTL8153... pro zajímaovst, to je na PCI-e nebo na USB ?Na interním USB 3.0
78
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
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
79
/dev/null / Re:iptables --m recent: možné oba zápisy update+set (pořadí a -j)
« kdy: 22. 02. 2023, 14:32:52 »
Zapomněl jsem dodat tu druhou stranu diffu:
Kód: [Vybrat]
-A guard_block -m recent --set --name listname
-A guard_block -m recent --update --seconds 180 --h
itcount 3 --name listname -j DROP80
/dev/null / Re:je cloud oblbovani lidi?
« kdy: 22. 02. 2023, 14:28:48 »
Až takovéhle extrapolace v tom nevidím Babička si sama hardware nevyráběla, jádro nekompilovala, cloud nebyl.
81
Server / Re:Volby pro SSH, aby vydržel dlouhodobě NAT
« kdy: 22. 02. 2023, 14:25:58 »
Mě právě šlo o dosažení této vlastnosti bez obezliček a wrapperů, jestli to ssh bude samotný.
Na větším množství systému pozoruji široké spektrum chování, třeba když se připojim z macu osu ixu, uspim,proberu druhý den, připojím se na wifi, mohu dopsat "rozepsaný příkaz", maximálně prvních 5 sekund to "bufferuje",.
Jinde minutové rozpojení ohlásí ukončení ssh.
Ale asi už je to pasé a vyřešené, používám to volbu - ServerKeepAlive a už to pár dní nevypadlo.
Na větším množství systému pozoruji široké spektrum chování, třeba když se připojim z macu osu ixu, uspim,proberu druhý den, připojím se na wifi, mohu dopsat "rozepsaný příkaz", maximálně prvních 5 sekund to "bufferuje",.
Jinde minutové rozpojení ohlásí ukončení ssh.
Ale asi už je to pasé a vyřešené, používám to volbu - ServerKeepAlive a už to pár dní nevypadlo.
82
/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í
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í
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.
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
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.
83
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)
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)
84
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.
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.
85
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 09. 02. 2023, 13:09:42 »
Acpi tam není, myslim, ze ta je nějaké dtb(o), lspci neeistuje
Ale mám zkušenost,že vždy když když dojde odroid přepálí spotřebu, dojde vždy k resetu a bootuje. A to se těžko stane v probuzení nebo při spánku nebo unlock screensaveru
Jinak zkoušel jsem probuzení a nikdy to nekleklo na nedostatek elektriky. Paradoxně když jsem 10x dal sleep+resumr nikdy nezamrznul
Ale mám zkušenost,že vždy když když dojde odroid přepálí spotřebu, dojde vždy k resetu a bootuje. A to se těžko stane v probuzení nebo při spánku nebo unlock screensaveru
Jinak zkoušel jsem probuzení a nikdy to nekleklo na nedostatek elektriky. Paradoxně když jsem 10x dal sleep+resumr nikdy nezamrznul
86
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 07. 02. 2023, 21:45:32 »
Je to Odroid XU4, s Arm-em, s úložištěm v podobě eMMC destičky místo obligátních microSD.
Neprovozuju ho moc často(jednou za čas ho yhátnu), takže o spolehlivosti nemohu moc mluvit. Ale už ho pár let mám, na SW jsem nesahal, naběháno toho moc nemá, .
Snad zváštnost je, že jede z 2A USB nabíječky, zdroj mám také, ale tím jak to nezapínám každý měsíc, nemohu tvrdit, kdy to jelo, kdy byly probl=my
(Vím, že u některých nabíječek(spíš powerbank) je zvláštnost, že při detekci nízkého odběru udělají shutdown), ale tady jsem na to nenarazil.
Taky jsem nenarazil na situaci, kdyby nabíječka řekla žravému odroidu you shall not draw. (ta nabíječka má charakteristiku, že někde za 2A začne hodně snižovat napětí) a mmjiné umí i 9V (takové ty quickcharge)
K měření odběru jsem se nedostal, ale ta nabíječka napájely i RPI které bych šacoval na mnohem měnší odběr(nemám to čerstvé, ale v idle 5V krát 100až 140mA) než toto "monstrum""
PS: pro zopakování: nastaly 2 různé jevy, prvně freeze se týkal suspend/resume, druhý při nonstop-běhu(screensaver))
Neprovozuju ho moc často(jednou za čas ho yhátnu), takže o spolehlivosti nemohu moc mluvit. Ale už ho pár let mám, na SW jsem nesahal, naběháno toho moc nemá, .
Snad zváštnost je, že jede z 2A USB nabíječky, zdroj mám také, ale tím jak to nezapínám každý měsíc, nemohu tvrdit, kdy to jelo, kdy byly probl=my
(Vím, že u některých nabíječek(spíš powerbank) je zvláštnost, že při detekci nízkého odběru udělají shutdown), ale tady jsem na to nenarazil.
Taky jsem nenarazil na situaci, kdyby nabíječka řekla žravému odroidu you shall not draw. (ta nabíječka má charakteristiku, že někde za 2A začne hodně snižovat napětí) a mmjiné umí i 9V (takové ty quickcharge)
K měření odběru jsem se nedostal, ale ta nabíječka napájely i RPI které bych šacoval na mnohem měnší odběr(nemám to čerstvé, ale v idle 5V krát 100až 140mA) než toto "monstrum""
PS: pro zopakování: nastaly 2 různé jevy, prvně freeze se týkal suspend/resume, druhý při nonstop-běhu(screensaver))
87
Sítě / Re:Může switch nebo router spojovat fragmenty TCP?
« kdy: 07. 02. 2023, 21:39:42 »
JE TO RTL8153
Jedna z otázek mě taky napadlo k forwardování. Jak se to chová kdyby dotyčný stroj, co umí LRO zároveň forwardoval a MTU by měl 9000, jestli pro forwardování tam nejsou jiný pravidla nebo omezení
Zajímavé, myslel jsem že zkratky G** VS T** roslišují jestli jde o protokol (T)CP nebo pro víc (G)protokolů(i když mi bylo divné, o jaké by mělo jít)
Jedna z otázek mě taky napadlo k forwardování. Jak se to chová kdyby dotyčný stroj, co umí LRO zároveň forwardoval a MTU by měl 9000, jestli pro forwardování tam nejsou jiný pravidla nebo omezení
Zajímavé, myslel jsem že zkratky G** VS T** roslišují jestli jde o protokol (T)CP nebo pro víc (G)protokolů(i když mi bylo divné, o jaké by mělo jít)
88
Server / Re:Google, Seznam vs. domácí server
« kdy: 07. 02. 2023, 21:29:39 »Nedávno na toto téma vyšel článek (teď nevím zda na rootu nebo živě.cz), jak někdo takto hostoval cca 20 let svůj mail ale pak to už vzdal, ...Máte někdo link? Na rootu vyšel po zrušení google hostovaného mailu od Eisenhowera , v podstatě článek v opačném gardu (byly tam alternativy Zoho,Seznam-profi,vlastní hosting)
89
Sítě / Re: fragmenty TCP? GRO,LRO vs TSO,LSO
« kdy: 06. 02. 2023, 19:36:47 »
Zajímavé. Ale teď když o tom přemýšlím, to, že některé počítače přijímají 524b pakety vlastně říká že na výstupu jsou původní pakety a ta HW transformace se děje na některých vybraných cílových PC.
Ještě jsem nekoukal na konfiguraci cílové stanice... na ethtool
Ale po prostudování myslím, že to co hledám, je GRO/LRO .. Generic Receive / Large receive offload.
Jestli to chápu dobře podle popisu tso (TCP Segmentation offload nebo jinak Large Send offload), tak offloading je rozsekávání velkých chunků na malé, ale tady je opačná situace. (a pochybuju, že by mi zvenku chodily 4kB pakety) Na WAN mi chodí 590 rámce
Ještě jsem nekoukal na konfiguraci cílové stanice... na ethtool
Ale po prostudování myslím, že to co hledám, je GRO/LRO .. Generic Receive / Large receive offload.
Jestli to chápu dobře podle popisu tso (TCP Segmentation offload nebo jinak Large Send offload), tak offloading je rozsekávání velkých chunků na malé, ale tady je opačná situace. (a pochybuju, že by mi zvenku chodily 4kB pakety) Na WAN mi chodí 590 rámce
90
/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
Dávání jednořádkového dlouhého textu do CODE není uplně friendly.
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.
