Příspěvky

46

O serveru Root.cz / Re:Místní fórum – uživatelská blokace některých uživatelů

« kdy: 05. 05. 2020, 13:39:56 »

Já se ptám věci, na který je google krátký. Občas mi tam ujede nějaká chybová hláška, ale většinou se ptám na komplexní problém, na který nestačí vysvětlení jednoho termínu.

10 x zmíněno mé ctěné jméno, tolik publicity si nezasloužím. 
Spíš bysme si měli dát pozor na Grétu. Není zdaleka na root.cz, ale na řadě předních českých webů všeljakého zaměření. Zhruba asi od podzimu 2019, hodně ji vzal hackerský útok na nějaké Tykačovy elektrárny a asi se pomstila na mimibazaru

47

Sítě / Vytvoření izolované podsítě s využitím brány

« kdy: 05. 05. 2020, 13:36:13 »

Chtěl bych vědět, jak prakticky na linuxovém stroji vytvořím  subsíť, která bude mít určité vlasnosti z nadřazené sítě. S možností přístupu na internet přes bránu, ale bez komunikace mezi jednotlivými sítěmi)
Začnu popisem nadřazené sítě: je to 192.168.0.0/16 s bránou a DHCP 192.168.1.1 a . Tu mohou využívat, ale nemohu ji konfigurovat.

Do té sítě jsem připojen přes první rozhraní a do vnitřní sítě přes druhé rozhraní.

Chci udělat to, aby zařízením z vnitřní sítě byla přidělována IP z pod-rozsahu, tedy  192.168.200.xxx/24. (to by jim zařídil zde běžící DHCP server, který ale nějakým způsobem bude muset spolupracovat s DHCP původní sítě) Zároveň aby zařízení  z vnější sítě nemohly komunikovat s vnitřní sítí (kromě brány) a zařízení z vnitřní sítě se nemohly napojit na vnější  nadřazenou síť (kromě brány a na internet ale ano). Chtěl bych to bez natu (ano vím, že nařazená síť NAT určitě používá).

Samozřejmě to jde zprovoznit tak NATovaně (1:N - PNAT - překlad portů i adres), že dhcp klient na vnějším rozhraní si vezme 192.168.xxx.xxx a na vnitřním pojede DHCP server  třeba 172.16.0.xxx, a oba budou oddělené.  a samozřejmě se přidá pravidlo do iptables (-t nat - A POSTROUTING -i in0 -o out0 -j MASQ.)

Zajímá mě druhé (vlastně jediné)alternativní řešení a SICE 1:1 natem (defacto jen NAT, pouze překlad adres) s tím, že by vnitřní síť byla třeba 172.16.


Podmínka je, aby to fungovalo bez žádné konfigurace klientských PC (ty se ostatně stejně budou připojovat na vnitřní rozhraní.

To taky vylučuje, že by se tedy klienti připojovaly rovnou do vnější sítě.
Taky jsem zavrhl vytvoření bridge. Má někdo názor, že by to bylas chůdná cesta (ale muselo by se dát hodně pravidel to ebtables, jestli to nazývám správně) ?

Dál bych se chtěl zeptat, zda k tomu budou potřeba věci jako
- IP Scope (to je co zač? neříká to, že adresa je platná jen v rámci  rozhraní, to by umožnilo mít 2 různé sítě např 192.168/16, který by ale spolu nemluvily, neboť by jejich hranice končila rozhraním ; nebo scope global či jiný?)
- DHCP relay (pro to a aby stroj mohl dělat ty kouzla s DHCP, že se bude snažit u nadřazeného DHCP vyjednat 192.168.200.xxx, ale klientům posílat zůženou masku sítě /24 místo /16 a )
- je potřeba dávat do iptables nějaká pravidla, nebo definice sítí je dostatečná, aby zařízení o existenci nadřazené sítě neměly páru (to koliduje s adresou brány) a zároveň ,aby zařízení z nadřazené sítě kromě brány nemohly komunikovat s mojí sítí?
- nazývá se toto podsíť/ subnet?

48

Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)

« kdy: 05. 05. 2020, 10:06:33 »

Môžeš mi vysvětlit, jak wireshark dekoduje WPA2 traffic, ked nepozná EAPOL handshake? Nepozná ho lebo  ho nestiahne lebo EAPOL nevyhovi filtru TCP. Nechci být zlý, ale pokud pokud bys tvrdil, že  tam žádná problém není , tek neznáš základy ty. Není možné zároveň zachytit EAPOL paket, který je nutný pro rozšifrování, pokud capture filtr je TCP. Protože EAPOL není TCP (nezachytí EAPOL) a bez EAPOL nerozšifruje komunikaci a ... Nebo wireshark snad magicky udeli vyjimku pro capture filtr, aby zachytil handshake EAPOL?

Připouštím, že neznám základy capture filtrov (toto "link layer applied in wrong context" me celkem vydesilo), ale wireshark ovládám ako pokročilý.

wlan dir 3

Odkial znas tyto filtre? Kde se daju najit?

diplomovka_szarkova pdf

Těch 90 stránek jsem prošel za 4 minuty. nedozvedel jsem se nic nového (okrem prehledné tabulky DA/SA/BSS,TA). A z oblasti capture filtru wiresharku tuplem nic."Diplomka" prilis popisuje obecne veci ,  prokousal jsem se jimi, ty nehodnotim, byt jsou celkem korektni, ale s bidou bych to uznal jako balalarku. Co hur, tyka se jen WEP.
je z roku 2007, je tam zmíněn Ethereal (wireshark), slovo filtr se tam vyskytuje 5x, capture 0x, bpf 0x.
Pro mě bezcenné.

49

Software / Re:Wireshark: capture filtry pro monitor mode;nefungují=žádné zachycené pakety

« kdy: 04. 05. 2020, 20:56:03 »

Pokud zadám jakýkoli filtr (zkoušel jsem wlan type 2 nebo tcp*), wireshark nezachytí žiadný paket.

*  je to validní filtr? Protože je to problém slepice a vejce: aby bylo možné dekódovat wlan traffic je nutné zachytit handshake (samozřejmě jsem se associoval po spuštění wiresharku, i přesto jsem nevěřil, že to bude fungovat). Jenže handshake není TCP, že áno.

50

Server / Re:Tor exit node ; používá multihoming ? (jiným uchem ven než dovnitř)

« kdy: 04. 05. 2020, 19:50:42 »

Když jsme u těch exit nodů , zajímalo by mě ,jak je typické nebo nutné  nebo zbytečné,aby měl multihoming ? Tzn, že do internetu se připojuje jiným připojením než do sítě tor? Alias jestli připojení k exit nodu z TOR klienta je stejné/jiné než to, kudy se on sám připojuje do internetu.

Je vůbec smysluplné, aby exit nody byly do internetu připojené pouze jedním připojením.

51

/dev/null / router" Podivné ICMP na WAN: dovnitř Unreachable port 137,ven,80,443 DNS rebind

« kdy: 04. 05. 2020, 18:28:27 »

Tak upřesňuji ty podivné ICMP pakety. ono jich je víc skupin. obojí se odehrává pouze na rozhraní "ven" (192.168.1.5).

směrem z routeru :

 DNS (port 53) dotazy klientů "router" přeposílá na zvolený DNS server na internetu. Na A dotazy přijde v pořádku odpověď. Na AAAA dotazy přichází odpověď Refused, Additional Record Name explanation.invalid a zpráva TXT "blocked by DNS rebinding protection".  Následně na tuto DNS odpověď pošle router ICMP Port not reachable (a kopii paketu DNS odpovědi)
-Proč DNS server posílá tohle? Kde je problém?
-Jak zablokovat, aby se "router" ptal na AAAA dotazy, stejně IPv6 nemám a nepoužívám a mám ho zakázaný.
- Proč se to týká jen DNS AAAA dotazů? a Proč na ně odpovídá? Kde je problém a co s tím?
-Souvisí to nějak s tím, že  dnsmasq  je spuštěn s parametrem --stop-dns-rebind)? Ale nerozumím jak, když  ten text o prevenci dns rebind nejprve přijde v odpovědi.


- ( port  SSL 443) pakety.   - jde o různé pakety HTTPS komunikace, většinou  se to odehraje na pakety vyznačené černě (spurious retransmision,, Dup) nebo s příznaky FIN PSH, ACK., nebo RST,ACK  Vrací Host unreachable. je jich asi 80% ze všech ICMP.

- to samé na Port HTTP (80) -identická situace (až na to že jich není tolik ,HTTPS je častější než HTTP)


Pakety směrem dovnitř:

Nevím jak to možné, ale na notebooku připojeném notebooku k routermjsem si  pustil ivysilání české televize. Proč to píšu, protože mi přišly ICMP pakety z nějakého cdn ČT ICMP Port unreachable na  UDP komunikaci daného ntb mezi porty 137-137..  Co je tohle k sakru zař?


Přitom, všechny weby a ivysílání jdou jak po másle

52

/dev/null / prohlížení webu na klientu - "router" posílá serveru ICMP Not reachable

« kdy: 04. 05. 2020, 14:50:51 »

Dobrý den, zprovoznil jsem linuxový router, který je připojen do  "do internetu" *** (sítě ven) a zároveň se na něj připojit přes wifi (v režimu master-hostpad), je routováno přes net.ip...forward=1. Použit je dnsmasq (-b -D alias --bogus-priv --domain-needed --stop-dns--rebind)

Wwebové stránky HTTP i HTTPS se v pohodě načítají. no problem. Jenže sám linuxový router někdy cílovému serveru posílá ICMP pakety Not reachable (source: ip adresa  linux.routeru na rozhraní do stíě ven 192.168.1.5, destination je IP serveru ). Zkoušeno na víc klientech. Nějak to snad asi může souviset s firewallem. Policy mám accept/accept, a klasické pravidlo pro masquerade (-t nat -A POSTROUTING -i phy0wlan0inner -o wlan phy0wlan1outer -J MASQUERADE) .  Stává se to zhruba po ukončení http spojení a odeslání fin paketů

Samozřejmě jsem na to pustil wireshark(pro vnitřní síť i vnější současně). Na vnitřní síti je vše korektní. Na vnější síti tam po (connection=close) nebo po nějaké době(keepalive timeout) u tcp zakončovacích paketů je toho hodně černého jako retransmision, dup....  a hned poté ty ICMP (tady to asi bude chtít trochu upřesnit, co za pakety nebo důvod označení černě konrétně... doplním... ) ... Ale opakuji prohlížení webu je naprosto OK.


Proč to dělá? Jak se toho zbavit.?



*** onen router používá privántní rozsah (172.16.0 /24 např)pro klienty a proužívá NAT na překlad  (MASQUERADE). Je připojen na další router (192.168.1.1 (/16) , ip např 192.168.1.5) ,který  dělá další NAT  a možná ještě je tam třetí NAT. Tak to je, nejde s tím nic udělat. Nemyslím si že je to příčina , jen to uvádím pro úplnost. Ostatně nikdy jsem si podobného nevšiml když jsem také měl víc natů a sniffoval na jiné síťové situaci .

53

/dev/null / PTR DNS ...udp.z.y.x.z.in-addr.arpa prochází na druhé rozhraní i zpět vč.odpověd

« kdy: 04. 05. 2020, 12:46:31 »

mám bridge na 2 sítích. jedna síť je vnitřní (privátní 192.168/16), druhá vnější.  dnsmasq obsluhuje vnitřní rozhraní (argumenty dnsmasq -k -dhcp-range=192....,255.0.0 -D - b -i eth0 --server 8.8.8.8 - tedy statická konfigurace bez načítání konfigurace ze souboru. )

1. Co je zač DNS PTR dotaz {lb,b,db}._dns_sd._udp.0.0.168.192.in-addr.arpa ? Resp. proč se ptá na 192.168.0.0 ?
2.  Z jakého důvodu (doufám že dnsmasq) posílá dotazy ven?
3. Z jakého DNS dotazy posílá rovnou na  rozhraní (8.8.8.8 definovaný pro  zařízení na eth0, ale proč i na 192.168.2.1  , což je "upstream DNS"  na vnějším rozhraní, které bylo přiřazeno z dhclienta)
4.  Co je přesně zač volba -b (--bogus-priv) ? Dle manu "Bogus private reverse lookups . All rev.lookups are answered nxdomain rather than forwarded upstream)...  Tedy  uvedení této volby by mělo zabránit tomu co se děje, nepletu se



Otázka mimo: je lepší dnsmasq a nebo isc-dhcp-server ?

54

Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)

« kdy: 03. 05. 2020, 20:06:14 »

No je to takové polovičaté. První funguje, druhé nefunguje.
Navíc to má nějaké odlišné názvy parametrů (odlišná syntaxe je očekávatelná). Nelze tam vkládat libovolné pole (napadl mě například) dokonce mám takové nemilé tušení, že to umí jen úzký obor polí.

Jak například vyberu pakety na kanálu 48, / pakety na kanálu >66, broadcast pakety s SSID hodnotou "VOIP"?


Mimojiné mi wireshark častokrát spadne při manipulaci s textem v poli pro filtr (opakovaný backspace, když nezbyde žádný znak například)

55

Software / Re:Wireshark: capture filtry pro monitor mode (radiotap)

« kdy: 02. 05. 2020, 17:01:02 »

Nevíte, zda proběhl nějaký vývoj v této věci? (Jestli už existují capture filtry pro kartu v režimu monitor modu)

56

Sítě / Re:Síťovka Ralink se nepřipojí k AP ; přes wpa_supplicant -c <() vyřešeno

« kdy: 02. 05. 2020, 16:59:43 »

a v ramci zkusil??

Vím, že dorážíš a jsi netrpělivý , když jsi nabídl své řešení a čekáš jak to dopadlo. Já jsem psal, že jsem to zatím nezkoušel a současně na netu narazil na ten návod wpa_supplicant s argumentem -c <(wpa_passphrase ssid heslo).  (jak jsem psal v příspěvku)
Mezitím se věci hnuly. Já jsem zkusil to wpa_supplicant -c a jsem s tím spokojený, takže tvé řešení jsem už nezkoušel.
Ale stále visí ve vzduchu otázka, proč to nejde přes iw ap connect ... Invalid argument...
Pro upřesnění : z dané wifi karty to nejde na na žádnou wifi síť, ale z jiné karty to jde na libovolnou síť....

57

Software / Zachování h264@youtube s blokovanými cookies : místo addonu h264 užij userscript

« kdy: 02. 05. 2020, 15:50:27 »

Vrtalo mi to hlavou, proč na jiném PC to na youtube jde H264  i s blokovanými cookies (což jsem zjistil, že byla příčina, že to hrálo VP9).
Řešení je použít místo rozšíření H264ify identický userscript h264ify od stejného autora (přes správce userscriptů v rolirozšíření Tampermonkey ; ale chrom by uměl umět i userscripty nativně ) .
Dobré vědět

58

Sítě / Re:Nelze přidat Wi-Fi STA/IBSS do bridge

« kdy: 02. 05. 2020, 15:40:06 »

Jenže tady se nehledá nějaký vhodný výklad, podle toho na "jakou realitu ho chceš napasovat". (Askubuntu - nelze dát STA do bridge).

Evidentně to musí jít, když provedu "logický AND" (ve linuxu jde jen AP-Master a v windows jen STA-klient). S trochou nadstázky řečeno = ještě to neznamená že to půjde současně, natož když jde o 2 různé OS.

59

Sítě / Re:Síťovka Ralink se nepřipojí k AP

« kdy: 02. 05. 2020, 15:35:07 »

Tohle předpokládám je jen informace na rámec přepokládám (navázání na problém 2 pásem v těsné blízkosti), protože takovýhle problém vůbec nemám - já mám 2 fyzické karty.

60

Sítě / Re:Naopak na Windows LZE přidat Wi-Fi STA do bridge,ALE NE hostednetwork(Master)

« kdy: 02. 05. 2020, 07:30:41 »

Na windows to funguje uplně obráceně. Tam naopak do bridge NEJDE dát SW Accesspoint "Virtuální adaptér hostované sítě Microsoft" (vytvořený access point přes netsh wlan start hostednetwork).  Přesněji řečeno, nelze vytvořit most, pokud v jeden z členů je SW Accesspoint.

NAOPAK LZE vytvořit most z kombinace několika Wifi klient adaptérů či Ethernetů  není problém.

Extra info: pokud vytvořím SW Accesspoint z fyzické karty "Atheros 1234", přidám do mostu například ethernet+ bezdrátovou kartu "Atheros 1234"(tedy režim klient), dojde ke zrušení SW Access pointu, ale mohu ho ihned znova spustit a nic se nerozbije(samozřejmě v bridge nebude,nedával jsem ho tam ani nazačátku)

Jakou tohle má logiku???


PS: proč stavění a bourání mostu na Windows trvá minutu??? (Dialogové okno "Počkejte prosím probíhá vytbváření připojení přes mosty...") To při tom přepočítává ARP tabulku pro celý svět?