Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Zdravím, potřeboval bych radu / nasměrování:
Situace:
- firewall se zablokovanými porty, s výjímkou vpn, ssh a VoIP telefonní ústředny povolenými porty:
- port ssh je 3232 a je přesměrovaný na server ve vnitřní síti, kde ssh běží na standardním portu 22
SSH server ve vnitřní síti (AlmaLinux) eviduje řadu útoků.
Root přihlášení pomocí hesla mám samozřejmě vypnutý, veškerou standardní ochranu (firewalld, selinux, fail2ban... atd., mám zapnutou.
Port na serveru jsem přesměroval na 3232 a od té chvíle se útoky znásobily:
Od posledního úspěšného došlo k 2233 neúspěšným pokusům o přihlášení
...Část výpisu
sshd[43922]: Received disconnect from 185.174.137.156 port 43838:11: Bye Bye [preauth] sshd[43922]: Disconnected from authenticating user root 185.174.137.156 port 43838 [preauth] sshd[43924]: Failed password for root from 58.230.203.182 port 50020 ssh2 sshd[43924]: Received disconnect from 58.230.203.182 port 50020:11: Bye Bye [preauth] sshd[43924]: Disconnected from authenticating user root 58.230.203.182 port 50020 [preauth] sshd[43928]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=211.252.87.118 user=root sshd[43928]: Failed password for root from 211.252.87.118 port 46264 ssh2 sshd[43928]: Received disconnect from 211.252.87.118 port 46264:11: Bye Bye [preauth] sshd[43928]: Disconnected from authenticating user root 211.252.87.118 port 46264 [preauth] sshd[43984]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.41.217.33 user=root sshd[43984]: Failed password for root from 124.41.217.33 port 56390 ssh2 sshd[43984]: Received disconnect from 124.41.217.33 port 56390:11: Bye Bye [preauth] sshd[43984]: Disconnected from authenticating user root 124.41.217.33 port 56390 [preauth] sshd[43986]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=131.186.47.190 user=root sshd[43986]: Failed password for root from 131.186.47.190 port 35196 ssh2 sshd[43986]: Received disconnect from 131.186.47.190 port 35196:11: Bye Bye [preauth] sshd[43986]: Disconnected from authenticating user root 131.186.47.190 port 35196 [preauth] sshd[43990]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.174.137.156 user=root shd[43990]: Failed password for root from 185.174.137.156 port 43858 ssh2 sshd[43990]: Received disconnect from 185.174.137.156 port 43858:11: Bye Bye [preauth] sshd[43990]: Disconnected from authenticating user root 185.174.137.156 port 43858 [preauth] sshd[43995]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=167.71.236.26 user=root sshd[43993]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.230.203.182 user=root sshd[43995]: Failed password for root from 167.71.236.26 port 59268 ssh2 sshd[43993]: Failed password for root from 58.230.203.182 port 50054 ssh2 sshd[43995]: Received disconnect from 167.71.236.26 port 59268:11: Bye Bye [preauth] sshd[43995]: Disconnected from authenticating user root 167.71.236.26 port 59268 [preauth] sshd[43993]: Received disconnect from 58.230.203.182 port 50054:11: Bye Bye [preauth] sshd[43993]: Disconnected from authenticating user root 58.230.203.182 port 50054 [preauth] sshd[43999]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=211.252.87.118 user=root sshd[43999]: Failed password for root from 211.252.87.118 port 59556 ssh2 sshd[43999]: Received disconnect from 211.252.87.118 port 59556:11: Bye Bye [preauth] sshd[43999]: Disconnected from authenticating user root 211.252.87.118 port 59556 [preauth] sshd[44012]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.230.203.182 user=root sshd[44012]: Failed password for root from 58.230.203.182 port 50086 ssh2 sshd[44012]: Received disconnect from 58.230.203.182 port 50086:11: Bye Bye [preauth] sshd[44012]: Disconnected from authenticating user root 58.230.203.182 port 50086 [preauth] sshd[44016]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=124.41.217.33 user=root sshd[44016]: Failed password for root from 124.41.217.33 port 40344 ssh2 sshd[44016]: Received disconnect from 124.41.217.33 port 40344:11: Bye Bye [preauth] sshd[44016]: Disconnected from authenticating user root 124.41.217.33 port 40344 [preauth]
...
Mohu server ještě víc obrnit, ale potřeboval bych pochopit odkud to jde.
- zvenčí to být nemůže (uvedené porty jsou zavřené).
- všechny win počítače ve vnitřní síti jsou aktualizované proskenované a chráněné pomocí Bitdefenderu.
- všechno o čem vím je aktuální
- zapadá mne: hacknutá telefonní ústředna? Nebo nějaká tiskárna? Nebo něco jiného..?
Jakým způsobem bych se dopátral kde je problém?
Přemýšlel jsem, že bych udělal nějaký honeypot server a zkusil to analyzovat.
Ale možná je nějaký jednodušší systém. Nevíte, prosím někdo?
Děkuji moc nasměrování!
Jedine co tym dosiahnes je frustracia ludi, co to musia pouzivat (potreba si pamatat port, manualne ho zadavat, a podobne)Od toho tu predsa mame
~/.ssh/config
. Ale inac suhlasim.
Zmena portu na ssh (a inych sluzbach) ti v nicom nepomoze.Všechny zdravím. Změnu čísla portu taky používám, ale pro ssh mám nastaveno přihlašování jen s použitím klíče. Nicméně ještě mi v domácí síti běží VDR s webovým rozhraním VDRadmin-AM pro nastavování nahrávání, kam se občas hlásím z venku a z různých adres. Z diskuse usuzuji, že to asi není moc bezpečné, takže prosím o radu, jak by to bylo lepší, napadá mne např. použít VPN či ssh tunel. Díky. Jirka
Napr. na svojom servri mam pristup povoleny z adries, ktore patria Slovenskym ISP.
Víte prosím někdo, kde získat aktuální seznam rozsahů českých IP adres? Já jsem našel tohle, ale ten web na mě moc důvěryhodně nepůsobí a navíc je ten seznam z roku 2016.
@[Jooky]: To do toho konfiguráku zadáváš úplně všechny ty rozsahy, nebo něco vynecháváš?
Vycházel jsem z toho, že normálně mám všude s sebou notebook. To je mé bezpečné pracoviště, v něm mám své klíče a z něj se připojuji kam potřebuji. Max jsou někde ještě stroje, za které zodpovídám bezpečnostně, nad nimiž mám moc a do nich si ty klíče mohu nahrát také. Odjinud se nikdy nijak nikam nepřipojuji. Připojení s heslem (silným) mám výjimečně povolené v nějaké nejmenší síti (domácí síť, VLAN v servrovně ap.) v níž je systém, čistě proto abych ve výjimečné situaci, když by něco bylo s klíčem tak se k systému dostal jsem-li fyzicky tak, aby bezpečnost byla zajištěna i jinak.
+1
Předně: Díky za snahu a za odpověď.
Moje cestování je na jiné téma.
- ano, všechny stroje jsou linux
- ano, jsem za ně odpovědný
- nevěřím, vím, že tam nejsou keyloggery
Notebook s sebou vždy vozti nemusím, práci mám uloženou v cloudu.
Tam ale klíče nahrávat nechci. Navíc, může nastat výjimečná situace, kdy se potřebuji připojit
a nemám s sebou notebook. Například na cestě, z tabletu a podobně.
Pokud se připojuji silným heslem, připojím se odkudkoliv.
Pokud to přehodím na klíče (což není technicky problém),
může nastat situace, kdy se z jiného zařízení nepřipojím,
si tam zapomenu klíče přidat.
Nebo musím vymyslet, jak klíče zabezpečeným způsobem
synchronizovat. Tomu se vůbec nebráním, jen jsem zatím neměl čas se tím zabývat.
Nebo musím vymyslet, jak klíče zabezpečeným způsobemTys s klíči nikdy nepracoval, že. Protože nevím o čem mluvíš. Jaké vymyslet "synchronizovat"? Máš systém A na kterém pracuješ a systém B (C,D) do kterého se loguješ s heslem.
synchronizovat. Tomu se vůbec nebráním, jen jsem zatím neměl čas se tím zabývat.
ssh-keygen
který ti lokálně vygeneruje klíče a na konci specifikuješ lokální heslo pro lokální otevření soukromého klíče. Na man najdeš, jak si navolit parametry pro generování klíče, ale i default je bezpečný.ssh-copy-id B
což je skript používající, kterému zadáš heslo k B a který ti nakopíruje na B veřejný klíč ssh tunelem (opět si přečti man). (samozřejmě lze klíč nakopírovat i přes sftp
) A to je vše.ssh B
chce nejdříve po tobě lokální heslo ke klíči, a pokud pracuješ tak, že se loguješ, odloguješ, znovu zaloguješ, atd. tak to otravuje psát znovu a znovu heslo a ssh-agent
ti na začátku klíče otevře s heslem a pak jednotlivé ssh si pro ně šáhnou do agentaPS: Ještě odpovídám, protože si vážím tvého času a odpovědí.
Nejde o to, že bych něco nechtěl sdílet, ale o to, že původní otázka byla o identifikaci útoků.
Řeším paralelně x věcí současně a v tomto případě mne ten tlak na přesměrovaný port prostě překvapil.
Jde o společnost, která měla v minulosti vážné bezpečnostní problémy,
mimo jiné hacknutý kamerový systém, který byl zneužitý k nebezpečnému provozu atd., atd.
Postupně se to dává celé dohromady. Souvisí to s energetikou a současnou bezpečnostní situací.
To je jedna velká oblast.
Druhá věc je nastavení mého pracovního ekosystému a jeho zabezpečení.
Třetí věc je jak to všechno bezpečně propojit.
Čili je to o dost složitější, na jiné téma, než byl původní dotan (nejde tedy jen o to jak nastavit klíče).
Díky!
Notebook s sebou vždy vozti nemusím, práci mám uloženou v cloudu.Ehm, toto vyzerá na zásadný bezpečnostný problém. Človek by mal mať svoj pracovný nástroj počas výkonu práce, a ten nástroj má spĺňať určité bezpečnostné štandardy. Nejaký kryptovací kľúčik alebo iný elektrický občiansky preukaz nestačí. Hint: keylogger na heslo alebo pin pre kryptokľúčik, hasák a podobne.
Rozumím. To už se ale bavíme IMHO o nějakém vysokém levelu armádního zabezpečení státního tajemství ( s tím hasákem).
Mně šlo o to - ale to už se odchylujeme od původní otázky - že pokud se přihlašuji se silným heslem, které znám jen já,
přihlásím se v případě krajní nouze odkkudkoliv na planetě.
Pokud vše nastavím na klíče a nebudu mít s sebou svoje zařízení, jsem v háji.
Většinu obsahu, který potřebuji k práci, mám na cloudu.
Jednotlivá zařízení, ze kterých pracuju, synchronizuji také tak, abych mohl na jednom přestat pracovat
a na druhém mohl pokračovat (jedno kde se geograficky nacházím).
Vše je samozřejmě šifrované, včetně disků a přenosu.
Takže by asi nebyl problém "synchronizovat" i klíče (čemuž logicky neporozumněl lertimir, protože jsem mu to dostatečně nevysvětlil).
Nechce se mi to tu celé popisovat, protože je to jiné téma než na které jsem se ptal.
Když to shrnu, přemýšlel jsem nahlas:
- Zaskočila mne úroveň útoků na přesměrovaném ssh portu, protože v ostatních případech se to v takovém rozsahu neděje.
- přemýšlel jsem (nahlas) o tom, jak to udělat, když vypnu přihlášení heslem a přejdu na klíče, abych si někdy nezapomněl
zařízení, a nebyl (typicky, když jsem hodně daleko), v háji.
Trochu se obávám svěřit tyto věci cloudu. Asi zbytečně, pokud šifruji přenos na straně klientů i serverů.
Byl to jen takový zbrklý "paranoidní" impuls. V podstatě to asi nebude problém.
Díky!
Pokud vše nastavím na klíče a nebudu mít s sebou svoje zařízení, jsem v háji.Tady je hezky vidět, jak každý uvažujeme v jiném bezpečnostním kontextu. Pro mne v kontextu, který popisuješ by vzniklo. Pokud nebudu mít dostatečnou konektivitu jsem v háji., protože se pohybuji i na lokacích, kde konektivita je mizerná - v hluboké přírodě. A proto představa, že nemám své zařízení je nemyslitelná. Nebo pokud ho nemám, nepracuji.
Většinu obsahu, který potřebuji k práci, mám na cloudu.
Jednotlivá zařízení, ze kterých pracuju, synchronizuji také tak, abych mohl na jednom přestat pracovat
a na druhém mohl pokračovat (jedno kde se geograficky nacházím).
Díky moc!
@[Jooky]: To do toho konfiguráku zadáváš úplně všechny ty rozsahy, nebo něco vynecháváš?Cele rozsahy pre koncovych uzivatelov. Udaje som si pozbieral sam. Napr. teraz som v sieti Antik Telecomu. Pozrel som si aku mam WAN a tu pohladal v ripe databaze. Vysledok:
inetnum: 88.212.36.0 - 88.212.43.255 netname: ANTIK_NETWORK descr: ANTIK PAT Customers country: SK admin-c: ATIN4-RIPE tech-c: ATIN4-RIPE mnt-by: ANTK-MNT mnt-domains: ANTK-MNT status: ASSIGNED PA created: 2012-08-15T09:53:43Z last-modified: 2017-08-10T14:43:47Z source: RIPE role: ANTIK Telecom IP Network Administrator address: Carskeho 10, Kosice, Slovakia admin-c: ZILL1-RIPE tech-c: ZILL1-RIPE nic-hdl: ATIN4-RIPE mnt-by: ANTK-MNT created: 2017-08-10T14:38:16Z last-modified: 2017-08-10T14:41:33Z source: RIPE # Filtered % Information related to '88.212.32.0/19AS42841' route: 88.212.32.0/19 descr: ANTIK_NETWORK_2 origin: AS42841 mnt-by: ANTK-MNT created: 2009-11-12T10:49:08Z last-modified: 2009-11-12T10:49:08Z source: RIPEcize medzi povolene ide 88.212.32.0/19 ... kedze viem, ze antik ma dva rozsahy, tak som si podobne pohladal druhy a oba mam v configu ... vynechavat z toho nema velmi zmysel, lebo na NAT a priradovanie IP nemam dosah u ISP.
OK, dík.
$ geoiplookup 124.41.217.33 GeoIP Country Edition: NP, NepalTo nevyzerá že by boli porty na exponované služby uzavreté. Najmä ak máš SSH exponovaný na WAN porte 3232 a cez PAT je presmerovaný na LAN port 22. Tie čísla portov z logu znamenajú niečo iné ako si myslíš. Skús si pozrieť čo s tými útokmi urobil fail2ban, logy sú /var/log/fail2ban.log* Ak ti vadí tak malý počet odrazených útokov, tak zníž treshold na ban, alebo si nastav geo-blocking firewall. Neviem si predstaviť kto chodí na služobky do Nepálu, Vietnamu alebo Kórei. To vyzerá na klasický útok z botnetu zloženého so zavírených počítačov.
Díky. Ještě jsem změnil port a koukám, že jsem zapomněl na změnu u fail2ban.conf. Takže jsem to napravil, právě to běží..
Ještě raději zkontroluji a poladím nastavení (time has too large deviation..).
Ano, mám otevřený port pro ssh na firewallu, který je nyní přesměrovaný na stejně vysoký port na ssh serveru.
Co, prosím, myslíš, tím, že čísla portů z logu znamenají něco jiné, než si myslím, že znamenají (chtěl bych to pochopit)?
Také si myslím, že je to klasický útok z botnetu ze zavirovaných počítačů.
Pokud by to bylo zvenčí, jak to, že se to dostane přes vysoký port "dovnitř"?
Myslel jsem, že botnety zkouší ssh útoky přes 22.
A pokud je to zevnitř, potřeboval bych právě zjistit odkud to jde.
Díky moc!
potřeboval bych právě zjistit odkud to jdePokiaľ tie IP adresy z logov nie sú z lokálneho rozsahu (ktorý určite poznáš), tak si si všimol príklad použitia príkazu geoiplookup. Len decentne podotknem že zadarmová databáza IP adries je "mierne" zastaralá, takže to občas hodí nesprávny údaj. Na mňa zopár krát vyštekol niekto z IP 179.60.147.159 ktorú to reportuje ako ruskú IP aj keď to podľa whois patrí Venezuelskej SAFE-VPN.MOBI. Na ten kontinent sa ešte rusko nedostalo. Keď som znížil počet pokusov na banovanie, tak to u mňa za posledné dni vyzerá top 5 krajín takto:
Country | Count |
---|---|
US | 237 |
VN | 136 |
RU | 101 |
CN | 83 |
BR | 46 |
Failed password for root from 58.230.203.182 port 50020 ssh2se tam nemůže vyskytovat. To lze jedině pokud se dostane přihlašování k heslu. Je to možná PAM autentizace. pokud si udelám
ssh localhost
a mám přihlašování jen klíči a samozřejmě nemám klíč u sebe dopadne to takto a žádné "failed password" tam není
lis 08 17:04:58 carbon sshd[29225]: Connection closed by authenticating user xxxxy ::1 port 36242 [preauth] lis 08 17:04:58 carbon kernel: audit: type=1109 audit(1667923498.616:188): pid=29225 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/bin/sshd" hostname=::1 addr=::1 terminal=ssh res=failed' lis 08 17:04:58 carbon audit[29225]: USER_ERR pid=29225 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/bin/sshd" hostname=::1 addr=::1 terminal=ssh res=failed'
AuthenticationMethods publickey KbdInteractiveAuthentication no ChallengeResponseAuthentication no PermitRootLogin no MaxAuthTries 3 MaxSessions 2
+
PasswordAuthentication=no
*Bez toho "=".
Tiskni Sdílej: