A segítségetekre van szükségem. Tesztelem a készülő ContainerSSH 0.4 preview releaset és tesztadatokra lenne szükségem. Kérlek, teszteld le:
TÖRÖLVE
Tetszőleges felhasználónévvel/jelszóval jelentkezz be és légyszi jelezd ha találsz valamilyen anomáliát. Egy bugot már találtunk, MacOS/kitty kombóban a prompt kétszer jelenik meg.
Ha találtál valamit, légyszi küldd el az oprendszeredet, terminálod típusát, a teszt időpontját, az IP címedet, és egy képernyőképet a handshake@containerssh.io cimre. Igény szerint megtalálod a GPG kulcsunkat itt.
Az adataidat természetesen töröljük amint a release elkészült, illetve igény szerint értesítünk arról, hogy mi volt a probléma.
Köszönöm szépen a rászánt idődet.
Update: köszönjük tesztelést, a honeypotot lekapcsoltuk.
Update 2: Megjelent, köszönjük mindenkinek a segítséget!
Hozzászólások
Egy 0.73 -as putty-al Win10 alól semmi extrát nem találtam. (emailt direkt nem küldök, mert nem fedeztem fel semmi hibát)
Pár parancsot futtatgattam, azt kb ennyi.
Köszönöm szépen a tesztelést. :)
Még egy serfish.com -os tesztem is volt előbb, (webes ssh .. brrr) ott sem volt semmi extra :)
Ismét köszi, a jövőben lesz beépített webes kliens, csak ez a release készüljön el. :)
Bejelentkeztem, éppen Win 10 alól, putty-t használva, hibát nem érzékeltem (ezért nem megy levél sem).
Köszi szépen!
Android 10 (kernel: 4.14.116), Reflection 1.6.0.86
Session handshake: Encryption key exchange with host failed.
Koszonom szepen, szerzek ilyen klienst es letesztelem, hogy miert nem sikerul.
Jónak tűnik.
Terminál: Yakuake 20.12.1
adam@adam-tp
OS: Manjaro 20.2.1 Nibia
Kernel: x86_64 Linux 5.4.89-1-MANJARO
Uptime: 20h 31m
Packages: 1341
Shell: bash
Resolution: 2820x1440
DE: KDE 5.78.0 / Plasma 5.20.5
WM: KWin
GTK Theme: Breath [GTK2/3]
Icon Theme: breath2
Disk: 55G / 211G (28%)
CPU: Intel Core i7-3740QM @ 8x 3.7GHz [54.0°C]
GPU: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
RAM: 5236MiB / 15716MiB
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
Koszi szepen!
A /home/-ba tehetnetek valami usert. Szoval ha bela/passwd-del jelentkezett be, akkor legyen egy /home/bela konyvtar, es onnan is induljon!
A sima ssh mukodott a desktop gepemen es a telefonomon. Viszont ha mountolni akartam, az disconnectalt. Nem tudom, hogy ez cel-e egyaltalan, hogy mukodjon, ha igen, akkor kuldok rola mailt (egyelore nem tettem). De az is lehet, hogy valamit felreirtam (sshfs-t scriptbol szoktam hasznalni, ezt is onnan vagtam ki). Repro:
nyos@hex:~$ sshfs -o reconnect,allow_other,uid=1000,gid=1000 194.182.184.97:/ testmnt/
nyos@194.182.184.97's password:
remote host has disconnected
szerk: scp sem megy, ez lehet, hogy megint nem baj:
nyos@hex:~$ touch /tmp/x
nyos@hex:~$ scp /tmp/x 194.182.184.97:/tmp/
...
unknown user 1000
lost connection
Mi a cel? Hogy probalja altalaban a tamado feltenni a rootkitjet a honeypotra? curl/wget (elobbi nincs fent, utobbi igen)? Vagy ramasolja valami massal?
A strange game. The only winning move is not to play. How about a nice game of chess?
Köszi szépen a visszajelzést, tettem bele usert és pár utilityt. Az SSHFS nem fog működni, mivel jelenleg nincs megoldásunk arra, hogy a konténerbe beproxyzunk egy SCP kapcsolatot, viszont az SFTP menni fog. Ha szeretnél feltölteni, akkor mindenképpen SSH multiplexálással próbálkozz, mivel a konténerek a kilépés után törlésre kerülnek.
A cél jelenleg az, hogy leteszteljük, hogy az interaktív konzol normálisan működik-e, illetve hogy valakinek sikerül-e megborítania a szervert.
Debian Buster
OpenSSH_7.9p1
Rendellenes viselkedés nem volt tapasztalható. Pár fura dolog viszont gyanús lehet a humán támadónak.
Szokatlan, hogy /-be léptet be és nem a home-omba.
Ahogy Nyosi írta, ha bela userrel lépek be, létrejöhetne a /home/bela és azzal indulhatna, mint working directory. Így ahogy most van minimum gyanút keltő.
pid 1-et írták már
de gyanút kelt az is, hogy szegényes a pid lista
/etc/fstab üres
/etc/mtab felfedi, hogy docker-ben vagyunk
(/.dockerenv eleve sejteni engedi mondjuk)
mount mond egy olyat, hogy:
/dev/vda1 on /etc/hostname type ext4 (rw,relatime)
wtf
Fura, hogy nincs mondjuk egy less
Nem tudom mennyire cél a nem lelepleződés és emberi támadó számára meggyőzőnek levés. Egy script nem valószínű, hogy törődik ezekkel, de aki szokott linuxra ssh-zni annak pár dolog feltűnhet.
Köszönöm szépen, ezek mind jogosak. Futott már egyszer ez a konfiguráció és emberi támadó nem volt tapasztalható az alatt a 2-3 nap alatt. Jelenleg egyelőre az a cél, hogy stabilan működjön minden egy elég nagy refaktor után, azért is kértem segítséget. Ha kész a release szeretnék egy hosszabb távú elemzést futtatni a bejövő támadásokról.
NetBSD-9.1/bash: ok
Koszonom szepen.
xubuntu 20.04, tilix
ok
Koszonom szepen.
Legutóbbi JuiceSSH/Android alól rendbenlévőnek tűnik, teszt userrel beléptem, pár parancsot próbáltam, aztán kiléptem...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Koszonom szepen.
Jonak tunik.
Koszi szepen.
Cuki a pid 1 :) De nem vagyok benne biztos, hogy nem vagy előrébb a dockerben levő dumbinittel (vagy tinivel, vagy a tök se tudja melyiket emelték bele végül). Illetve hosszasabb belegondolás nélkül egy kicsit furcsa, hogy a ppidje a valódi bash shellnek 0. Lehet, hogy nem egészen az történik ,mint amit gondoltál.
Illetve lehet, hogy egy unminimize ráférne, ha már interaktív. Pl man sincs így.
Egyébként nem verte ki a biztit semmi. yakuake meg konsole alól.
Köszi a tesztelést.
Az 1-es pidre már van az agentben support, csak ebbe a verzióba nem került bele. Hosszú távon az a cél, hogy az agenten kivül semmit ne kelljen betenned az imagebe.
Egyébként ez a default image, a use casek többségére az az elvárás, hogy saját imaget csinálsz. Nem akartuk a default image méretét túltolni.
Szerintem sikerült megborítanom, bár ez nem az ssh hibája:
cat /dev/zero > ~/zerofill
után nem tudok másik terminálbóé belépni
Permission denied, please try again.
Bocs :)
Egyébként Debian 10 latest és openSuse Tumbleweed latest alól minden más rendben.
Valoban, koszonom, mindjart tesztek disk space limitet a kontenerre.
Update: ez nemi kuzdes lesz ext4 folott, meg eltart egy darabig, ezt jo lesz dokumentalni.
Android JuiceSSH egy idő után aktivitás közben kidob. Saját nick-kel voltam ha néztek logokat.
Koszi, megnezem. Ha nem szakad meg a kapcsolat nem kellene kidobnia.
Mit tudom én mondjuk éppen könyvtárat listáztam amikor paff! Szóval nem idle timeout volt. Néha login utan 3-5 sec után. Éjjel még ránézek más klienssel is.
Koszi, az audit logbol ki fog derulni hogy mi tortent.
WIN10 + WSL: OK
Android + Termius: OK (a Juice-nak lehet nálam vmi baja ezekszerint, bár máshol sose jött elő)
FreeBSD + ssh: OK
Koszi szepen, attol meg erdekes, a Juice az egyik legismertebb mobilos SSH kliens, regebben en is hasznaltam. Probalok Android emulatort varazsolni hogy tesztelni tudjam.
Fedora 33, gnome-terminal, tmux: jonak tunt, probaltam kiiratni random binaris szemetet, azt is tulelte. Aztan kiprobaltam egy bash forkbombot, azutan szinte azonnal kidobott - szandekos?
Koszonom szepen.
25 MB a memoria limit a konteneren, valszeg az olte meg a kontenert, de mas is probalta mar, az audit log el van mentve elemzesre :)
win10 / putty: nem futottam hibába
far manager 3.x / sftp: csatlakozás/letöltés/feltöltés közben nem futottam hibába
// Happy debugging, suckers
#define true (rand() > 10)
Koszonom. :)
Üdv,
iPad 14.3 ios
prompt2 és WebSSH app, minden rendben volt.
Koszi szepen. :)
Minden session saját chroot-ot kap?
Nem, saját konténerben fut. Ez a szerver Dockerrel van konfigurálva, de Kubernetessel is működik. Gyakorlatilag az attach és exec API-kon keresztül közlekedik az IO.
2 kapcsolatot indítok. létrehozok egy fájlt az egyikben és nem latszik a másikban. Ez, akkor miért? Nem értem.
Masik konténer
Másik konténer, mindegyik kapcsolat sajátot indít.
Ahogy a kollégák mondták fentebb, a rendszer jelenleg két üzemmódot támogat: per-connection és per-session konténer. Az előbbi akkor csinál konténert amikor belépsz és kilépéskor takarít, az utóbbi pedig minden SSH-n belüli sessionnek csinál külön konténert. Tervben van egy olyan funkció ami perzisztensen meghagyja a konténereket, de ehhez a clusterezést végig kell gondolni. Egyelőre ez nem nagyon merült fel mint igény, mert ahol elvárás az adatok megtartása ott kintről kerül bemountolásra pl. a home könyvtár.
root userrel belepve nem tudok belepni a /root dirbe...
ilyet is ir:
arpi-i7MacPro:~ arpi$ ssh root@194.182.184.97
...
root@194.182.184.97's password:
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
ubuntu@bitcoin:/$ whoami
ubuntu
Köszi, ez elvárt működés, az autentikációs szerver mindenféle userrel beenged, de a container backenden ki van kényszerítve az 1000-es UID. Majd lehet, hogy csinálok egy szofisztikáltabb auth/config kombót ami szimulál root usert. :)
Linux Mint 20.1 ssh/sftp rendben minden.
Köszi szépen!
Windows 10 + mintty 3.0.6 (régebbi cygwin telepítés)
Beléptem, pár parancsot futtattam, kiléptem. Rendben lévőnek tűnik.
Zavard össze a világot: mosolyogj hétfőn.
Kiraly, koszi!
Android fronton csináltam két programmal tesztet:
illetve
Egyikkel sem volt probléma! ;-)
Koszonom szepen!
Win10 PS
miklos account-tal, megy hiba nélkül (ezért nem megy levél)
Juice (3.2.1) Android 10 (1+7)
juice account-tal, megy hiba nélkül (ezért nem megy levél)
Koszi szepen!
ssh pi@
loginolt usernev ubuntu. Mindig.
ubuntu@bitcoin:/$ last -10
wtmp begins Fri Jan 22 18:56:34 2021
ubuntu@bitcoin:/$ who
ubuntu@bitcoin:/$
Koszi szepen, igen, ez elvart mukodes ebben a konfiguracioban.
amugy ha en irtek botot ami probalgatja az ssh szervereket, tuti azt csinalnam, hogy eloszor valami biztosan rossz user+jelszo komboval probalkoznek es ha az is beenged akkor rogton tudom hogy ez csapda...
vagy az ilyen honeypot-oknak nem az lenne a lenyege, hogy megtevesztesig hasonlitson az igazi rendszerre?
Ez nem honeypotnak keszul. Csak a tesztkornyezet ilyen.
Btw. legfrissebb Juice, Android 9 - mukodik, par percig bent voltam,minden ok.
Valo igaz, jelenleg arra koncentralunk, hogy a release mukodjon, utana csinalunk egy komprehenzivebb honeypot default configot. De ez nem is az elsodleges use case. :)
Gentoo, xfce4-terminal. Ok.
Koszonom szepen.
Az ssh bannerjét szerintem érdemes lehet valami szokványosra, mondjuk OpenSSH-ra cserélni. Lehet, hogy van akit/amit már ez elijeszt.
Belépve is sok dolog van, ami feltűnhet. Pl. a gyanúsan kevés process, az init rendszer hiánya, a ssh-nál használt felhasználónévtől eltérő felhasználó, netstat nem mutatja az ssh-t, amivel bejöttem, nincs hálózat, a mount-ban rögtön elől az overlay. Ha kicsit is szétnéz a bejutott script, hamar gyanút foghat.
Koszi, igen, ezek konfiguralhatoak, jelenleg a releaset szeretnenk tesztelni.
hi!
win10, kitty 0.74.4.2p: OK
ubuntu 20.04 terminal-ról: OK
illetve két megjegyzés:
érdemes lenne kipróbálni screen vagy tmux terminal multiplexer is működik-e rendesen, bár a látottak alapján nem tűnik problémásnak.
X11 forwardingnak van értelme? lesz GUI-s workload a konténerben?
Koszi szepen, a kitty erdekes mert MacOS-en sorduplikaciot tapasztalt a kollega. A terminal multiplexer mukodik, ahogy pl. az mc is. Ez annak koszonheto, hogy SSH szinten semmi kulonoset nem kell beallitani hozza.
Az X11-nel lehet ertelme, hiszen a megjelenites a kliens gepen van, bar utoljara 10 eve lattam olyat aki szerverrol szeretett volna X11-elni. Ezt jelenleg nem tamogatjuk, ha lesz ra igeny akkor beepitjuk. A TCP forwardingra es SSH agent supportra valoszinuleg nagyobb igeny van.
debian alatt connect ok
tegyetek a usernek sudo jogot, had érezze a törődést
emulálni neki valami ethernet interface-t? ne csak a loopback legyen :)
wget az mukoggy bár letölteni nem lehet semmit, az még jó lenne ha működne, el lehetne kapni pár hasznos, haszontalan tool-t (is akár) plusz hozzá való usert, passt.
Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)
Koszi szepen. Jelenleg halozat nelkul fut a cucc mert ha a halozatot kiengedjuk akkor azt szurni kell hogy ott ne csinalhasson csunyasagokat. :) Ha magadnak telepited, akkor nyilvan ugy tudod konfiguralni ahogy jol esik.
Windows 10 alól a Windows Terminal 1.4
Nincs gond, de pl. a su root esetén, bruteforce működne? vagy kivág egy időután ha sokat próbálkozom?
Koszi.
A sudo kidobas csak akkor mukodne ha integralnam a kontenerben levo PAM-ot az SSH szerverrel. Jelenleg a kontener kulon eletet el.
Kedves mindenki,
köszönjük szépen a kiadós teszteléseteket. Az eredmények alapján megtoltuk a 0.4-es fejlesztést még egy ciklussal és jópár egyenetlenséget kiküszöböltünk, valamint kapott egy új és részletesebb szöveges logot is. A, remélhetőleg utolsó, preview release 0.4.0-PR4 megjelent, és ha nincs vele komolyabb gond, akkor ez lesz a végleges 0.4.0 is.
Köszönjük a rászánt időtöket, amint megvan a végleges release jelentkezünk. :)