Edvard Rejthar na blogu zaměstnanců CZ.NIC představil svou aplikaci SlideRshow (GitHub). Funguje jako prohlížeč fotek, ale i jako jejich organizér a prezentátor. Neinstaluje se, běží přímo v prohlížeči. Bez serveru. Offline.
Kermit, tj. protokol pro přenos souborů, vznikl před 45 lety. Při této příležitosti byla po 15 letech od vydání poslední stabilní verze 9.0.302 vydána nová stabilní verze 11 implementace C-Kermit. S podporou IPv6.
První verze konverzního nástroje Pandoc byla vydána před 20 lety. Jeho autor John MacFarlane při tomto výročí rekapituluje jednotlivé etapy vývoje a přidávání nových funkcí – rozšíření nejen Markdownu a podporu mnoha dalších formátů.
Srpen přinesl nejen další spalující vedro, ale také Virtuální Bastlírnu s neméně žhavými novinkami. Využijte tedy předpovědi na deštivý čtvrteční večer a od 20:00 se připojte online k tomuto neformálnímu setkání kutilů, techniků a vědců, kde se strahovskými bastlíři proberete nejzajímavější věci, na které jste narazili za poslední měsíc. Pokud jde o novinky, řeč zcela jistě přijde na systém INDX pro tiskárny Průša, který na konci
… více »Firma T-Mobile blokovala „dezinformační web“ AC24 bez toho, aniž by k tomu měla závazný pokyn orgánů veřejné moci. Píše to ve svém rozsudku Městský soud v Praze, který po čtyřech letech uzavřel kauzu blokace zmíněného webu. Operátor musí uhradit škodu ve výši 35 tisíc korun. Advokát společnosti T-Mobile se snažil i u odvolacího senátu argumentovat tím, že firma jednala v dobré víře, když na stránky omezila přístup poté, co ji k tomu vyzvalo
… více »Padla obžaloba v bitcoinové kauze. Státní zástupkyně chce pro Blažka 6,5 roku vězení, pro Titze 8 let.
Z aktuálních globálních statistik společnosti Statcounter: na desktopu má Linux celosvětově podíl 7,53 % (USA 11,92 %, Česko 4,31 %, Slovensko 4,36 %) a Firefox celosvětově podíl 6,51 % (USA 10,86 %, Česko 11,07 %, Slovensko 13,61 %).
Na GitHubu byl publikován seznam 55 kritických bezpečnostních chyb v SQLite s přiřazenými CVE čísly. JFrog Security informuje, že se jedná jenom o AI slop, části kódu na které CVE odkazují, v daných verzích vůbec neexistují. Upozorňuje také, že čísla CVE jsou přiřazována bez ověřování.
Příspěvek na blogu Google Security popisuje, jak tým Chrome Security využívá umělou inteligenci k zásadnímu zrychlení a zlepšení procesu odhalování, třídění a opravování bezpečnostních chyb v prohlížeči Chrome. Díky AI byla nalezena kritická chyba, která byla v kódu přes 13 let. Ve verzích Chrome 149 a 150 bylo opraveno více chyb než v předchozích 23 verzích dohromady.
Firmy v EU musí počínaje dnešním dnem označovat obsah vytvořený umělou inteligencí. Znamená to povinnost informovat uživatele, že člověk komunikuje s chatbotem či jiným systémem AI. Rovněž obrázky, audia či videa, které jsou vytvořené nebo zmanipulované pomocí umělé inteligence a které mohou působit jako autentické, musejí být jasně označeny jako uměle vytvořené.
192.168.2.180 a open vpn ip 10.0.1.1
routa 192.168.1.0 255.255.255.0 10.0.1.100 10.0.1.1 1
Server
ip 10.0.1.100 a i 192.168.1.34 s gw 192.168.1.1
na pc za vpnserverem je ip 192.168.1.38 a pridal jsem tam routu
route add -net 10.0.1.0 netmask 255.255.255.0 gw 192.168.1.34
tohle mi uz bez problemu jelo, problem je v tom, ze jsem preinstaloval pc za vpnserverem (ip 192.168.1.38) a uz to nejede, nechapu proc. Firewall tam neni.
openvpn server
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 * 255.255.255.0 U 0 0 0 tap0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
pc 192.168.1.38
Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 192.168.1.34 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
ani nevim jak sledovat kam to chodi, pomoci snort jsem zjistil, ze kdyz zadam u klienta 192.168.1.38 tak to dorazi na 10.0.1.100 a dal uz nevim jak. Traceroute nic neukazuje
(akorat bacha - tcpdump sedi na sitovce - pakety prichozi ze site slysi DRIV jak firewall, kdezto pakety odchazejici slysi PO firewallu. Takze jeden vidi prichozi paket, tcpdump ho ukaze, ale hned zanim ho tise zahodi firewall...
)
V tom navodu je pouzit tap interface... tam nevim. Pouzivam tun.
Mel jsem za to, ze pokud se pouzije tap, tak by mely byt pocitace jakoby ve stejne siti (tj. pak chodi broadcasty a spol). Pri pouziti tun, by se naopak melo openvpn chovat jako dalsi propojeni dvou odlehlych siti a pak se k tomu pristupuje jako k routovane siti. (push-route v konfigu serveru a podobne)... ale za toto tvrzeni bych pracku do ohne nadal...
ping cilovy_stroj, tak by Ti po ceste mel
tcpdump -i eth0 -n host cilovy_strojmel ukazat asi toto:
18:59:55.014080 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 1, length 64 18:59:55.014345 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 1, length 64 18:59:56.014399 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 2, length 64 18:59:56.014655 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 2, length 64 18:59:57.014400 IP 192.168.2.1 > 192.168.2.99: ICMP echo request, id 34585, seq 3, length 64 18:59:57.014647 IP 192.168.2.99 > 192.168.2.1: ICMP echo reply, id 34585, seq 3, length 64... v tomto pripade sly packety jen na sousedni masinu a eth0 je interface, pres ktery to melo jit. a opakuji - pri prichodu na masinu je tcpdump pred firewallem a pri odchodu je zanim.
192.168.2.180
-------------------------------
| PC1 winxp,opevpn client |
-------------------------------
|
|
|
-------------- -------------- --------------
| hw router |---------| internet |--------| hw router |
-------------- -------------- --------------
|
|
192.168.1.34, 10.0.1.100 |
------------------------------- |
| PC2 Debian,opevpn server |---------------------|
------------------------------- |
|
192.168.38 |
------------------------------- |
| PC3 Debian,Gnome |---------------------|
-------------------------------
Routovaci tabulky
PC2 - Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 * 255.255.255.0 U 0 0 0 tap0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
5.0.0.0 * 255.0.0.0 U 0 0 0 ham0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
PC3 - Směrovací tabulka v jádru pro IP
Adresát Brána Maska Přízn Metrik Odkaz Užt Rozhraní
10.0.1.0 192.168.1.34 255.255.255.0 UG 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
v pripade ze na PC1 zadam ping 10.0.1.100 nebo ping 192.168.1.34 tak dostanu odpoved, v pripade ze zadam ping 192.168.1.38 tak jsem pomoci SNORT zjistil, ze na PC2 to dorazilo, ale dal uz nevim co s tim.
)
Na serveru pak muzes prubezne zkouset sedet s tcpdumpem na interfacech, pres ktere by_to_melo_jit(tm) a divat se jestli to opravdu jde a nejlepe v obou smerech.
Sranda je v tom, ze Ty na serveru jadru sice reknes, kudy routovat, ale je mozne, ze to nepozna "uvnitr" vpnka... (pokud to teda neni ten firewall
)
A z opacneho skopka: na svojem stroji mam v konfiguraku serveru pridane cca toto:
push "route 192.168.1.0 255.255.255.0" client-config-dir ccd route 192.168.2.0 255.255.255.0to push "route..." rika klientom, ze do 192.168.2.0/24 .... "na mne" a v /etc/openvpn/ccd (zalozit rucne) je soubor, pojmenovany podle klice klienta (kdyz byl klic pri vytvareni pojmenovan kareL, tak se soubor musi menovat kareL - vcetne velikosti pismen , predpoklada, ze kazdy klient ma SVUJ jedinecny klic) s obsahem:
ifconfig-push 10.8.0.18 10.8.0.17 iroute 192.168.2.0 255.255.255.0Nutno podotknout, ze ja sedim na tun interfacu a sit openvpnka mam na 10.8.0.0/24. To ifconfig-push slouzi k prideleni pevne adresy v ramci openvpn (aby po restartu serveru dostal stejnou), iroute nakrmi openvpnko (tj. ne primo kernel) informaci o tom, kam v ramci toho openvpn ma paket dal jit. V dusledku tim jde rozjet routovani i mezi klienty. Za potencialne nevhodnou syntaxi ifconfig-push se omlouvam, ale ted nemam tap kde vyzkouset (ano, su liny, nechce se mi ted budovat dalsi server) ... v Tvojem pripade to bude rozhodne v segmentu 10.0.1.0/24. Osobne jsem domaci server budoval podle navodu primo u atoru Za narknuti s wc3 se omlouvam, ale pisatel se tam taky domahal odpovedi. (v jeho pripade tam pred tim par doporuceni padlo ale vysledky nenapsal ...) Vyzkousej a dej vedet.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes 23:33:45.755624 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 10496, length 40 23:33:51.187211 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 10752, length 40 23:33:56.686788 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 11008, length 40 23:34:02.188073 IP 10.0.1.1 > 192.168.1.38: ICMP echo request, id 1024, seq 11264, length 40na [PC3] se mi v tcpdump plete ssh, takze to leti moc rychle, nevim jak to odfiltrovat pouze na ICMP, ale i tak si myslim ze to tam nedorazi
tcpdump -i eth0 -n icmp and host 192.168.1.1preventivne bych doporucil sednout na tom pc2 i na druhy interface, at vis, ze ma snahu to poslat dal. (-i eth0) ....a uplne hloupy dotaz: mas na tom serveru povoleny forward?
cat /proc/sys/net/ipv4/ip_forwardby melo vypsat "1"...
Sam nejsu zadny odpornik, takze urcite bude dost lidi, ktere napadne jeste neco, co se muze zkusit.
(osobne jsem taky parkrat poslal prispevek o chvilu pozdej protoze mi trvalo nez jsem pocetl zelou diskusi a nasledne sesmolil odpoved
)
v pripade ze na PC1 zadam ping 10.0.1.100 nebo ping 192.168.1.34 tak dostanu odpoved, v pripade ze zadam ping 192.168.1.38 tak jsem pomoci SNORT zjistil, ze na PC2 to dorazilo, ale dal uz nevim co s tim
Co vám na PC2 řekne cat /proc/sys/net/ipv4/ip_forward ?
echo 1 > /proc/sys/net/ipv4/ip_forward
/etc/rc.local a máte posekáno (nebudete to muset po každém restartu nahazovat růčo).
Tiskni
Sdílej: