Dobry den, pokud si ve Forisu povolim pro MiniPot logovani i jmen a hesel, mohu se nekde dostat k tem jmenum a heslum, která byla utocnikem na Telneti port 23 mého Turrisu pouzita?
Dobrý den,
zatím to možné není, ale je to v plánu. Rádi bychom publikovali i nějaké veřejné statistiky získané z této metody, ale nejprve chceme probrat, jak k tomu budeme přistupovat - například je zde nějaká šance, že při neopatrnosti uteče i samotnému administrátorovi zařízení nějaké heslo. Zhodnotíme rizika a promyslíme, co s tím půjde dělat, pak by se mohlo na webu něco objevit.
Dobry den,
nejde to ani v pripade, ze jsem se prave neopatrne a omylem prihlasil na port 22, kde mi bezi Honey pot, se svym pravym heslem? Nebo se to tyka jenom portu 23?
Rad bych to heslo dal pryc.
Myslím, že se NONES ptal na něco jiného - pokud mu rozumím správně, jde mu spíš o to si v datech brouzdat, ne je upravovat. Odpověď na Vaši otázku máte
u předchozího příspěvku.
Ano, mně šlo o následnou analýzu dat zjištěných a zalogovaných minipotem. Pokud je to v plánu (třebas formou veřejné statistiky), je to prima. Díky!
Ještě bych měl jeden malý dotaz ohledně "plnotučného" SSH honeypotu - v dokumentaci k němu píšete, že "... aby měl uživatel situaci plně pod kontrolou, je honeypot ve výchozím stavu dostupný pouze z vnitřní sítě na anonymním portu 58732 ..."
Mně se ale z vnitřní sítě k tomuto portu na routeru připojit nedaří - při pokusu o TCP připojení z vnitřní sítě na router port 58732 se tento jeví jako nedostupný. Přitom se zdá, že zvenku běží vše jak má, při on-line scanu mé WAN IP adresy routeru pomocí on-line scanneru (např.
pentest-tools.com) se jeví TCP port 22 jako otevřený a při podrobnějším zkoumání běžící služby je na něm tímto scannerem detekována "Kojoney SSH honeypot (protocol 2.0)"
Ano, je to chyba, honeypot poslouchá pouze na IP adrese WAN rozhraní (viz výpis netstat). Díky za upozornění, opravíme.
Včera jsem si také aktivoval SSH honeypot a z jiné veřejné adresy jsem se do něho "vlámal" ale v datech z našeho routeru se stále na záložce "Zaznamenaná sezení" nic nezobrazuje. Kde může být problém?
Pokud to bylo (cca) před půlnocí, data by tam dnes měla být. Můžete mi prosím napsat detaily do mailu (jan.cermak@nic.cz) - kdy to přibližně bylo a z jaké adresy by ten přístup měl být? Zkusíme se podívat, zda není někde chyba.
Pěkné ráno,
dneska už tam moje pokusy "o hack" jsou zalogované. Vše tedy funguje správně.
Dobrý den,
koresponduje Vám počet zachycených spojení z firewallu na port 22 vs SSH honeypot? Děkuji
No, mám tam malou záhadu. Od doby aktivace SSH honeypotu nemám zalogováno nic a v zachycených paketech firewallem nemám na TCP port 22 a 23 taky nic. Do doby aktivace SSH honeypotu nebylo dne, kdy by firewall na tyto porty neco nezachytil. Někdy to byly dokonce výherci žebříčku portů.
Spíš si myslím, že otevřením těchto portů na firewallu je router přestal zahazovat a tím pádem logovat a logování v SSH honeypotu funguje blbě. Ale je to pouze moje domněnka z indicií chování na mém routeru.
U mě je ale situace taková, SSH honeypot běží od úterý a FW na portu 22 aktuálně zachytil 32 paketů (9.6.) a 22 pak. (10.6.).
V zaznamenaných sezeních o nic ale zmínka není.
EDIT: Podle scanneru WAN je otevřený minipot (port 23), na který se můžu "přihlásit"
SSH podle něj ale neběží, a při pokusu o připojení dostávám Connection refused.
EDIT 2: Po obnovení továrního nastavení a nastavení služeb již Honeypot funguje, alespoň podle scanneru WAN.
Hmmm, taky zajímavé ...
Apropo, při připojení zvenku na ssh dostávám: Connection refused (potvrzeno tech. podporou UPC
)
Tak to já ne - když se připojím zvenku na WAN port mého routeru, vlezu normálně do toho honeypotu - tedy aspoň si to myslím. Každopádně se mi tam nabídne SSH shell, kde se mohu přihlásit a "řádit" si tam. Jen se mi to bohužel neprojeví v zaznamenaném logu z SSH honeypot aktivity. A podle on-line scanneru portů mi na 22-ce sedí Kojoney SSH honeypot service, což by mohlo být to avizované Kippo, které v CZ.NIC používají - viz
Wikipedie
mozna proto, ze honeypot se aktivuje pouze na uzivatele "root"?
pokud se pripojim treba jako uzivatel "apache", tak me to nepusti pres heslo, ale FW samozrejme packet zachyti.
Mě to bere i admin/admin, apache neprojde...
Ano, taky mě to napadlo. Dle statistik (www) je podíl ssh útoků vedeno pod uživatelem root v počtu 84% ze všech přihlášení. To samozřejmě nemusí být můj případ.
Opraveno. Děkujeme za upozornění.
OK, já děkuji za rychlou opravu. :-)
Ještě bych měl dotaz, jak a kdy se tato oprava projeví. Vyzkoušel jsem připojit se z mého NB připojeného kabelem do LAN portu routeru na IP adresu mého routeru na TCP port 58732 - a výsledkem je Connection refused - Připojení se nezdařilo. Když se zkusím připojit např. na TCP port 22 mého routeru, vesele se ohlásí SSH Server.
Malé nedorozumění - ta oprava se týkala dokumentace. Na tom, že mitmproxy (aplikace pro přesměrování provozu do SSH honeypotu) poslouchá na IP WAN rozhraní se nic nemění. Opravdu se tedy musíte připojovat zvenčí.
Aha, tak to jsem opravdu Vaší předchozí odpovědi neporozuměl správně. Teď už je mi to jasné a docela i chápu smysl tohoto řešení.
Díky za dovysvětlení.
Dobrý den,
nedaří se mi přidat forward pravidlo do firewallu. Všechno vyplním tak jak má být, dám "Save & Apply", případně jen "Save" a seznam přesměrovaných portů je stále prázdný.
Tuší někdo čím to může být.
Myslím, že už jsem na Turrisu něco podobného řešil a problém byl v nastavení práv na soubor v systému.
Ale než se v tom začnu vrtat, tak se raději ptám.
Díky
Mareg
Pravděpodobně nestisknete vpravo tlačítko Přidat...
Ano, je to tak
, díky.
Jde nějak otestovat funkčnost, když nemám připojení z jiné sítě?
Vzhledem k tomu, že oprava toho, aby honeypot konec tunelu na routeru - tj. TCP port 58732 - byl dostupný i v rámci LAN se jaksi nepovedla dovést do zdárného cíle, pravděpodobně tuto možnost zatím nemáte. Stejně jako já
Jak jsem psal
vedle, opravdu je nutné připojení z vnějšku. Můžete ale použít nějakou službu typu online nmap (například tu, kterou odkazoval NONES) a ověřit funkci tím.
jeste nesedi casy "zaznamenanych sezeni" + casy jednotlivych prikazu..
O problému víme, ale kolega, který honeypoty řeší, má do konce týdne dovolenou. V pondělí se na to podíváme a časy v databázi opravíme.
Problém už by měl být od včerejška vyřešen.
Není zvláštní, že ač má SSH honeypot aktivovaný od úterka, nemám stále žádný záznam o pokusech o připojení v zaznamenaných sezeních? Že by mne Ti "bad-boys" měli tak rádi?
Je to možné - je tam jeden testovací přístup z IP adresy z rozsahu UPC a na firewallu už žádné pokusy o přístup na port 22 blokované nejsou. Pokud se tedy zatím nikdo nezkoušel připojit, jen prováděl port scan, v honeypotu nic nebude.
Aha, tak co blbnu, klidně můžu začít používat pro SSHčko k uživateli root heslo password, nebo 12345. Jsem dítě štěstěny, tak nač si pamatovat nějaký dlouhý a šíleně složitý hesla. Nebo nedej bože generovat klíče pro ještě bezpečnější přístup!
Já taky ne, ale podle pentest-tools.com to běží, ale pri pokusu o připojení zvenčí to hází Connection refused
Z mého pohledu vše funguje, za to Connection refused tedy nejspíš může něco v síti, odkud se tam snaží dotyčný připojit, nebo bude problém (s odpuštěním) mezi klávesnicí a židlí ;)
Tak blokuje to něco v síti v jiné už nebyl problém.
nemůže být problém ve změněném host key? U mě to (správně) zahlásí tohle:
$ ssh NEKDE.NECO...
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for NEKDE.NECO... has changed,
and the key for the corresponding IP address <<IP>>
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:aa.
Please contact your system administrator.
Add correct host key in /home/USER/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/USER/.ssh/known_hosts:9
RSA host key for NEKDE.NECO... has changed and you have requested strict checking.
Host key verification failed.
Abych to mohl vyzkoušet, musím na chvíli odebrat patřičný řádek z .ssh/known_hosts.
Je možné že při nějaké nastavení ssh clienta to prostě jenom odpojí a nic neřekne...
otestovat lze pomoci telnetu na port 22
jinak neni potreba mazat zaznam z known_hosts, staci:
ssh -lroot x.x.x.x -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
jojo... jenže odebrat na moment patřičný řádek bylo rychlejší než hledat v manu :) ... ale tohle je jasně elegantnější...
Chtěl bych se zeptat jaké příkazy se zaznamenávají v houneypotu?
Když jsem spustil, tak jsem hned musel otestovat, ale vše se neprojevilo co jsem zadával.
Určitě jsem dával curl, které ale není podporováno, pak jsem dával wget, snažil jsem se něco nainstalovat, logout a exit, ty ale nefungují, a pak omylem jsem se snažil připojit na jiné ssh.
V logu mám jen první 4 záznamy.
co jsem postrehl, tak prikazy se zaznamenavaji do logoutu (prepadu na "druhy" honeypot - zde co se zada uz se nezaznamena).
Nějak už se v tomto vláknu začínám utápět ...
Asi by bylo vhodné aby honepot hned po přihlášení na sebe neprásknul, že je turris. Možná by mohl jako hostname hlásit něco neutrálního, třeba localhost. A jestli je možné nějakým scannerem možné zjistit, že se jedná o honeypot, tak to taky asi není moc dobré.
Dobrý den
O honeypot se stará kolega, který tu zrovna není, tak to není úplně autoritativní odpověď. Ale čekal bych, že ta detekce nebude úplně triviální a že ti boti, co útočí, jsou velmi primitivní a takovou věc nikdo nikdy neřešil. Celkem běžně v datech vidíme věci jako že se něco přihlásí s jménem „cisco“ a poté pouští příkazy, které jsou očividně pro SuSE Linux.
Jo, ten scanner je docela komplikovaný a má v sobě znalostní databázi různých verzí operačních systémů a honeypotů. Jediný, co nezná, je váš nově vyrobený minipot pro Telnet port, ale hned si vyrobí jednoznačnou identifikaci tohoto systému a žádá uživatele, aby tuto informaci (otisk) pojmenoval. Pokud to provede, pro příště už bude vědět, co je to zač.
Jen pro zajímavost - scanning provádí i u většiny online služeb na pozadí aplikace
nmap, která v sobě má databázi fingerprintů služeb (spuštění s flagem
-sV). Teoreticky by to pak mělo být možné obejít. Zvážíme, zda by bylo zajímavé to implementovat, ale z velké části platí to, co psal Michal Vaner.
nevidm svuj vcerejsi pokus do ssh honeypotu ve statistikach.. je to OK?
Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill
