To bych netvrdil 
Tipuju, že si Surricata musí přidat háček do iptables, aby měla přehled o provozu a to se zdá nepovedlo.
Jinak potvrzuji, že restart Surricaty, celého routeru ani reinstalace situaci neřeší.
Průběh je stejný, jak popisuje @cmkaho
Stav po cca. 20 hodinách:
root@turris:~# pakon-show
no records to show
Dobře, můžete mi prosím poslat výstup z:
iptables -nvx -L suricata
ps | grep suricata
Podle toho by se dalo poznat jestli Suricata běží a má dobře pravidla v iptables.
Další možnost co mě napadá je starý konfigurák Suricaty (jednou jsem to řešil a zatím nechápu důvod). Zkuste prosím, jestli existuje /etc/suricata/suricata.yaml-opkg:
ls -l /etc/suricata/suricata.yaml-opkg.
Díky za pomoc s debugováním.
root@Cm_Inet:~# iptables -nvx -L suricata
Chain suricata (3 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2/0x2
154544 162163317 NFQUEUE all -- br-lan * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 10 bypass
162964 137079035 NFQUEUE all -- * br-lan 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 10 bypass
0 0 NFQUEUE all -- br-guest_turris * 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 10 bypass
0 0 NFQUEUE all -- * br-guest_turris 0.0.0.0/0 0.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 10 bypass
root@Cm_Inet:~# ps | grep suricata
4238 root 9728 S /usr/bin/python3 /usr/bin/suricata_conntrack_flows.py /var/run/pakon.sock
root@Cm_Inet:~# ls -l /etc/suricata/suricata.yaml-opkg
ls: /etc/suricata/suricata.yaml-opkg: No such file or directory
Takže surricata běží a v iptables taky je.
/etc/suricata/suricata.yaml-opkg tak nemám. Jen bez -opkg.
root@Cm_Inet:~# ls -l /etc/suricata
-rw-r--r-- 1 root root 3533 Jul 27 09:02 classification.config
drwxr-xr-x 1 root root 0 Dec 12 03:16 conf.d
drwxr-xr-x 1 root root 42 Dec 15 16:28 output_conf.d
-rw-r--r-- 1 root root 1375 Jul 27 09:02 reference.config
-rw------- 1 root root 50260 Dec 12 03:16 suricata.yaml
-rw-r--r-- 1 root root 1651 Jul 27 09:02 threshold.config
Jsem na drátě - můžeme testovat skoro online.
Suricata neběží, to by ten výstup z ps vypadal jinak. Můžete mi ještě poslat log suricaty, z /var/log/suricata/? Mělo by stačit posledních pár řádků…
Děkuji.
Aha, moc tam toho není:
root@Cm_Inet:~# cat /var/log/suricata/suricata.log
15/12/2017 -- 16:33:13 - <Notice> - This is Suricata version 4.0.0 RELEASE
Po restartu surricaty přibyl jen další identický záznam.
Mám se pokusit ji přeinstalovat?
Bohužel zatím netuším čím by to mohlo být. Poslal jsem Vám zprávu (tady přes fórum), hodilo by se mi víc informací, abych to dokázal zdebugovat.
Díky za pomoc.
Když smažu pravidlo o přesměrování portu 22 na 2525, tak na portu 22 nic neposlouchá.
A to ani po restartu.
Já myslím, že @commar měl ny mysli to, aby jste smazal z FW pravidlo, které bylo potřeba pro přesměrování do starého honeypotu (tj. WAN 22 -> 58732).
Nový honeypot (služba HaaS) již toto pravidlo nepotřebuje, za prvé proto, že haas-proxy na routeru naslouchá na portu 2525 a za druhé proto, že si správné přesměrovávací pravidlo sama přidává pomocí iptables do FW v okamžiku svého startu (v init scriptu).
Pokud jste to staré pravidlo jen upravil ze starého stavu (22->58732) na nový aktuální stav (22->2525), máte ho tam duplicitně … tedy za předpokladu, že ho tam init script haas-proxy úspěšně přidá, což není vždycky jisté a někde tady na fóru o tom diskutujeme, že stávající řešení není moc spolehlivé.
Děkuji kolegovi za doplnění, ještě přidám, po restartu routeru se mi stalo že haas-proxy neběží a bylo potřeba ručně restartovat /etc/init.d/haas-proxy restart
Teď jsem to opět zkoušel, moje pokusy se připojit se na haas.nic.cz objevují, ale nic jiného. Žádná další aktivita.
EDIT:
toto je pokus o připojení na port 22… z logu… vypadá to na Rusko nebo Ukrajinu…
Na haas.nic.cz je neobjevil, možná se to zahazuje…
2017-12-18T08:34:42+01:00 info twisted[]: [haas_proxy.proxy.ProxySSHFactory] disabling non-fixed-group key exchange algorithms because we cannot find moduli file
2017-12-18T08:34:42+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] kex alg, key alg: diffie-hellman-group14-sha1 ssh-rsa
2017-12-18T08:34:42+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] outgoing: aes256-ctr hmac-sha1 none
2017-12-18T08:34:42+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] incoming: aes256-ctr hmac-sha1 none
2017-12-18T08:34:43+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] NEW KEYS
2017-12-18T08:34:43+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] starting service ssh-userauth
2017-12-18T08:34:43+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,2,185.110.132.49] admin trying auth password
2017-12-18T08:34:43+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,2,185.110.132.49] admin authenticated with password
2017-12-18T08:34:43+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,2,185.110.132.49] starting service ssh-connection
2017-12-18T08:34:43+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] Got remote error, code 11
2017-12-18T08:34:43+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] reason: Bye Bye
2017-12-18T08:34:43+01:00 info twisted[]: [SSHServerTransport,2,185.110.132.49] connection lost
2017-12-18T08:34:44+01:00 info twisted[]: [haas_proxy.proxy.ProxySSHFactory] disabling non-fixed-group key exchange algorithms because we cannot find moduli file
2017-12-18T08:34:44+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] kex alg, key alg: diffie-hellman-group14-sha1 ssh-rsa
2017-12-18T08:34:44+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] outgoing: aes128-ctr hmac-md5 none
2017-12-18T08:34:44+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] incoming: aes128-ctr hmac-md5 none
2017-12-18T08:34:44+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] NEW KEYS
2017-12-18T08:34:44+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] starting service ssh-userauth
2017-12-18T08:34:44+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,3,185.110.132.49] admin trying auth none
2017-12-18T08:34:44+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,3,185.110.132.49] admin trying auth password
2017-12-18T08:34:44+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,3,185.110.132.49] admin authenticated with password
2017-12-18T08:34:44+01:00 info twisted[]: [SSHService ssh-userauth on SSHServerTransport,3,185.110.132.49] starting service ssh-connection
2017-12-18T08:34:45+01:00 info twisted[]: [SSHService ssh-connection on SSHServerTransport,3,185.110.132.49] got channel direct-tcpip request
2017-12-18T08:34:45+01:00 alert twisted[]: [SSHService ssh-connection on SSHServerTransport,3,185.110.132.49] channel open failed
2017-12-18T08:34:45+01:00 alert twisted[]: [SSHService ssh-connection on SSHServerTransport,3,185.110.132.49] Traceback (most recent call last):
2017-12-18T08:34:45+01:00 alert twisted[]: [SSHService ssh-connection on SSHServerTransport,3,185.110.132.49] Failure: twisted.conch.error.ConchError: (3, 'unknown channel')
2017-12-18T08:34:45+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] Got remote error, code 11
2017-12-18T08:34:45+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] reason: disconnected by user
2017-12-18T08:34:45+01:00 info twisted[]: [SSHServerTransport,3,185.110.132.49] connection lost
2017-12-18T08:34:52+01:00 info twisted[]: [-] exitCode: 0
2017-12-18T08:34:52+01:00 info twisted[]: [-] sending request exit-status
2017-12-18T08:34:52+01:00 info twisted[]: [-] sending close 0No ja jsem zkusil pravidlo nejdrive disablovat, nasledne uplne odstranit a port 22 zacne fungovat pouze pokud restartuji haas-proxy …
Zrušil jsem přesměrování v LuCi, ve Forisu jsem odinstaloval “SSH Honeypot”, počkal jsem na odinstalaci a potom “SSH Honeypot” opět zaškrtnul.
A HaaS funguje.
Nicméně na http://haas.nic.cz vidím stále jenom moje testovací připojení - možná kvůli dlouhým odezvám.
A po odpojení mi PuTTY stále hlásí “Connection to haas-app.nic.cz closed.”.
V jiné části fóra je informace, že za problémy může nepředvídatelná chyba na straně serveru, která se projevila až po připojení Omnií. Není to jeho technickými parametry či výkonem. Oprava bude trvat delší dobu, nebudou to jednotky dní.
Tak me tento postup nefunguje - pravidlo puvodniho honeypotu jsem smazal, potom ve Forisu ssh honeypot odinstaloval,pockal na odinstalovani a nainstaloval zpet. Stale po restartu TO pripojeni na port 22 hazi connection refused. Po restartu haas-proxy se jiz pripojit da.
I po startu TO vidim spusteny process “/usr/bin/python2.7 -m haas_proxy -n --pidfile=/tmp/haas.pid --syslog haas_proxy --device-tok”. Co je zvlastni - pridal jsem do /etc/init.d/haas-proxy do start_service() logger Token:$TOKEN,Port:$PORT,Fw_setup:$FW_SETUP,WanIP:$WAN_IP
no a pri restartu haas-proxy se to spravne zaloguje, ale po startu TO v logu zadne entry neni
No ono to funguje a nefunguje.
Po restartu haas-proxy jsem se úspěšně připojil, zadal pár příkazů a zase odpojil. Znova se připojil a fungovalo to. Chvíli jsem to tak nechal a pak to zase zkusil. A už to nejelo. Musel jsem znova restartovat haas-proxy.
Takže to vypadá, že hass-proxy prostě potichu umře. A je otázka, zda je chyba jen v haas-proxy, nebo to má souvislost i s problémy na serveru.
Ano … chová se mi to úplně stejně!
Jak psal @cynerd … moc se ten přechod honeypotů na HaaS nepovedl.
Musíme si ještě chvíli počkat, než se vychytají mušky a masařky.
Zatím ne. Počkal bych, až tým prohlásí Haas za stabilní a pak se v tom můžu začít vrtat. Předpokládám, že na tuhle chybu během ladění narazí.
Dokonce si myslím, že o ní již Turris team ví.
Jen nám to zatím nedal vědět, protože správně předpokládá, že jsme jasnovidní. (co všechno nás ty roky s Turrisem nenaučí?)
Ale z vyjádření @cynerd někde tady na fóru, že se start HaaS ve spojení s Turris a Omnia moc nepovedl bych soudil, že tomu tak je!
Tohle podle mně nemá cenu řešit do doby, než se opraví server.
V noci se mi haas-proxy asi nějak rozbil.
Proces sice běžel, ale na portu 22 nic neposlouchalo - chyba connection refused.
Pomohl až restart (/etc/init.d/haas-proxy restart), který vygeneroval tohle:
2017-12-19T08:52:48+01:00 info twisted[]: [-] Received SIGTERM, shutting down.
2017-12-19T08:52:48+01:00 info twisted[]: [-] (TCP Port 2525 Closed)
2017-12-19T08:52:48+01:00 info twisted[]: [-] Stopping factory <haas_proxy.proxy.ProxySSHFactory instance at 0x1035610>
2017-12-19T08:52:48+01:00 info twisted[]: [-] Main loop terminated.
2017-12-19T08:52:48+01:00 info twisted[]: [-] Server Shut Down.
2017-12-19T08:52:53+01:00 info twisted[]: [-] Log opened.
2017-12-19T08:52:53+01:00 info twisted[]: [-] twistd 16.0.0 (/usr/bin/python2.7 2.7.12) starting up.
2017-12-19T08:52:53+01:00 info twisted[]: [-] reactor class: twisted.internet.epollreactor.EPollReactor.
2017-12-19T08:52:53+01:00 info twisted[]: [-] ProxySSHFactory starting on 2525
2017-12-19T08:52:53+01:00 info twisted[]: [-] Starting factory <haas_proxy.proxy.ProxySSHFactory instance at 0x165f840>
To odpovídá mému včerejšímu testu - po nějaké době přestane haas poslouchat.
Můžeš to hodit jako issue na gitlab? Uděláš radost @RadoslavCap 