Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Ucel tohoto clanku neni prednaset nejake rozumy..na to nemam znalosti:)....spis bych byl rad, kdyby se pod nim rozjela diskuze na tema zabezpeceni serveru..a ja, popr dalsi zacinajici admini..by si z ni mohli odnest maximum...a tak prijit k dalsim znalostem..vedle tech co si nastuduji sami. Takze strucne popisi co jsem si na serveru nastavil ja...a budu to prokladat dotazy, o kterych bych se rad pobavil.
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
Hezci mi prijde povolit navazani spojeni na konkretni portynapr. 4x za minutu z konkretniho IP. Pomoci modulu recent se toho da dokazat snadno.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT
Jak to resite vy? Co vam prijde lepsi?
#!/bin/bash
# based on iptables found somewhere in the internet ;))
modprobe ip_conntrack_ftp
IPTABLES="/sbin/iptables"
INTERFACE=$1
if [[ "$INTERFACE" == "" ]]
then
echo "INTERFACE variable unset! Aborting"
exit 1
fi
echo -n "Attempting to bring up firewall on $INTERFACE: "
#Flush old rules:
$IPTABLES -F
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
iptables -N icmp-chain
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type echo-reply -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type echo-request -m limit --limit 5/s -m state --state NEW -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type destination-unreachable -m state --state NEW -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type time-exceeded -m state --state NEW -j ACCEPT
$IPTABLES -A icmp-chain -i $INTERFACE -p icmp --icmp-type timestamp-reply -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A icmp-chain -j DROP
$IPTABLES -N services
$IPTABLES -A services -p tcp -i $INTERFACE --dport 22 -m state --state NEW -m recent --set
$IPTABLES -A services -p tcp --dport 22 -i $INTERFACE -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
$IPTABLES -A services -p tcp -i $INTERFACE --dport 22 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p tcp -i $INTERFACE --dport 80 --sport 1024:65535 -m state --state NEW -j ACCEPT
$IPTABLES -A services -p tcp -i $INTERFACE --dport 443 --sport 1024:65535 -m state --state NEW -j ACCEPT
a dalsi sluzby...
$IPTABLES -A services -j DROP
$IPTABLES -A INPUT -i $INTERFACE -p ip -f -j DROP
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -i $INTERFACE -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPTABLES -A INPUT -i lo -s 127.0.0.1 -j ACCEPT
$IPTABLES -A OUTPUT -o lo -d 127.0.0.1 -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A OUTPUT -m state --state NEW -j ACCEPT
$IPTABLES -A INPUT -p icmp -j icmp-chain
#ports allowed cos of port sentry
TCP_PORT_SENTRY="1 11 15 79 111 119 540 635 1080 12346 20034 27665"
UDP_PORT_SENTRY="1 7 9 69 161 513 635 640 641 31335 32770 32771 32772"
for watch in $TCP_PORT_SENTRY; do
$IPTABLES -A INPUT -i $INTERFACE -p tcp --dport $watch -j ACCEPT
done
for watch in $UDP_PORT_SENTRY; do
$IPTABLES -A INPUT -i $INTERFACE -p tcp --dport $watch -j ACCEPT
done
$IPTABLES -A INPUT -i $INTERFACE -m state --state NEW -j services
echo "done."
Tiskni
Sdílej:
for watch in $UDP_PORT_SENTRY; do $IPTABLES -A INPUT -i $INTERFACE -p tcp --dport $watch -j ACCEPT done
PS: ano, ja vim ze toto neni 100% reseni, ale ja opravdu radeji jednoduchy system ktery dela to co ma bez zbytecnych "blbinek" navic.
.
U SSH doporučuji kromě standardních opatření použít direktivu AllowUsers (popř. AllowGroup) na povolení přístupu k SSH ze strany pouze některých uživatelů. Pro každý případ.
Monitoring. Vlastní skripty parsující logy, logcheck, logwatch. Občasné použití chrootkitu a rkhuntera nezaškodí. Aktivní IDS nepoužívám, můj server by to nezvládal, a i kdyby ano, vzhledem k topologii sítě by nebyl efektivní.
Kernel. Líbí se mi grsecurity, ale bez oficiálního zdroje pro Debian s binárkou určenou pro mou architekturu budu raději používat distribuční kernel.
Díry. Ano, audit pomocí Nessusu či dalších nástrojů pomáhá, jinak hlavní je (kromě správné konfigurace) častá aktualizace (v mém případě jednou denně).
Modul recent používám pro ochranu SSH, ale v mém případě moc využívaný není. Démon mi totiž nevisí na portu 22, kam směřuje většina automatizovaných útoků. Na portu 22 mám tarpitJakym zpusobem vytvarite tuto past? Ja pouzivam tinyhoneypot ale hledam neco lepsiho, vite o necem?.
Nicmene je to skutecne tak zhave?Já myslím, že vůbec ne. Dokonce bych řekl, že pokud nepoužíváte vyloženě slabá hesla a máte vypnutý PermitRootLogin, můžete mít SSH klidně na portu 22, firewallem k němu přístup nijak neomezovat, a přesto být v relativním bezpečí. Mít SSH na jiném portu se hodí (pouze) k odražení automatizovaných útoků, protože ty v drtivé většině případů portscan neprovádí a předpokládají, že SSH bude na portu 22. Když ho u vás nenajdou, půjdou "o dům dál". Zkušený útočník bez problémů najde SSH na kterémkoliv portu. Pokud použije sniffer, odhalí třeba i port knocking. Nicméně, podle mého soudu, i zkušený útočník bude dávat přednost strojům se slabším zabezpečením, protože mu průnik do nich zabere mnohem méně času a úsilí. Pokud tedy nebude mít nějaký explicitní důvod, proč se probourat zrovna na váš server.
mam za to, ze kdyz mam zakazane prihlasovani pres heslo...a svuj klic mam chraneny passphrase...tak clovek, ktery by se byl schopen lognout by musel byt takoveho kalibru, ze nejake pasti v podobe toho cos rikal ho asi neprekvapiPřesně tak. Tohle zabezpečení je více než dostatečné. Ono v pohodě stačí i silnější heslo a přihlašování bez klíče. Samozřejmě je třeba dbát zejména na to, odkud se hlásíte (keylogger, apod.).
nebo je to snazsi nez sem si myslel? prolomit ssh??Neřekl bych. Zejména pak, pokud pravidelně aktualizujete.