Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
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
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.
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"...
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: