Broken HaaS and Honeypots

[JardaB]

Turris Omnia Turris OS version 5.3.5 HBS. Not all honeypots and HaaS works !

---

0 - reForis - Packages HaaS and minipots are enable
1 - reForis - Sentinel state - All is enable and running
2 - Last record Haas 2022-03-13 09:26:27, uptime 15d 17h 8m 54s
3 - Ports 21, 22, 23, 25, 587 - closed, port 80 - is open
4 - My sheduled tasks

17 */12 * * * /etc/init.d/haas-proxy restart
03 */12 * * * /etc/init.d/sentinel-proxy restart

5 - Diagnostics are saved, dtto schnapps image

---

This problem did not occur for the first time, in two cases more than a month ago. If I remember correctly, restarting services was not enough in the past, it had to be disabled and enabled (reinstall HaaS) - I’m not sure.

It surprises me in particular that the planned restarts of haas and sentinel-proxy did not resolve the situation.

I do not want to take any (inappropriate) action at this time. I will be grateful for recommending a procedure to analyze the problem.

[jada4p]

Are there any errors or warnings regarding HaaS in system log?

Ad scheduled tasks: isn’t it a typo? ie. spaces around character “/” in string “* / 12”

As far as I noticed problems regarding HaaS as well, I created script checking whether it is running and let it check especially after reboot (clause “@reboot” in cron file)… see “What is happening with HaaS? - #21 by jada4p”

[JardaB]

spaces around character “/” in string “* / 12 … those gaps were created during the copying process … it’s unusual and I didn’t notice it

Except traditional and lingering buzz …
Mar 17 16:16:08 Turris_JB haas-proxy-start [5365]: 2022-03-17T17: 16: 08 CRITICAL twisted 'channel open failed, direct-tcpip is not allowed’
… lets haas no other mistake

It started without my intervention (I stopped scheduling restarts after the problem was detected)

2022-03-16 21:28:57 ARG - 186.58.83.134 1 root root
2022-03-16 21:28:56 ARG - 186.58.83.134 1 root root
2022-03-16 21:28:44 ARG - 186.58.83.134 1 root root
2022-03-13 09:26:27 185.244.167.13 0 ubnt ubnt
2022-03-13 07:59:04 CHN - 36.110.228.254 1 root root
2022-03-13 07:59:03 CHN - 36.110.228.254 1 root root
2022-03-13 07:59:02 CHN - 36.110.228.254 1 root root

[JardaB]

Outage yesterday - HaaS doesn’t work. Haas and honeypots ports are closed. /etc/init.d/haas-proxy restart and /etc/init.d/sentinel-proxy restart (or /etc/init.d/haas-proxy reload) do not change anything.

Disable - enable haas_proxy - no effect, helped only to disable-enable Minipots in reForis - Sentinel

How to analyze the problem?

[DIKKEHENK]

If you check luci>sytem> processes, does it run? And what happens you restart it there?

[JardaB]

Do you mean restart the router? I’m not trying. What they cannot analyze is that both Honeypots and HaaS always fail at the same time.

Haas-proxy and sentinel-proxy are running in the processes and I just tried restarting haas-proxy and sentinel-proxy. the action in terminal takes place without an error message. After all, even scheduled restarts after 12 hours have no effect

17 */12 * * * /etc/init.d/haas-proxy restart
03 */12 * * * /etc/init.d/sentinel-proxy restart

I don’t know the links between HaaS and Honeypots, but there is always a failure of both. Only disable / enable Minipots will bring improvements … this indicates a problem with Sentinel. I don’t know how Sentinel is connected to HaaS … I thought HaaS was independent and independent of anything else.

After all, I can only find the outage by checking the HaaS records on the server or by checking whether the ports 21,22,23,25,80,587 are open using GRC | ShieldsUP! — Internet Vulnerability Profiling  

[DIKKEHENK]

No, just have a look in Luci>status>processes There you can see if all is actually running or not, and there you can also restart both haas en Sentinel?

Haas and sentinel are 2 different processes. Not dependent. You can also see in luci>status>realtime graphs>connection is the connection between your router and the .cz mothership is active?

[JardaB]

Yes, I know where to look at processes and restart them
192.168.2.1/cgi-bin/luci/admin/system/startup or 192.168.2.1/cgi-bin/luci/admin/status/processes
I don’t quite understand the second part of the question - I don’t know from the head of cz.nic IP servers. You would need to be specific with an IP or name address.

In addition, Honeypots and HaaS now work - if they don’t - ports 21,22,23,25,80,587 should still be open.

It is possible that HaaS and Honeypots are not related, but the dysfunction occurs at the same time and it is removed (except for the router restart) only with disable/enable Honeypots in reForis.

[DIKKEHENK]

interesting… your 10.X subnet is connecting to turris.cz, but your 192.x isnt? over here the ip connecting to turris.cz is the ip nmr i get from my ISP?

[JardaB]

This is not the way to go, it’s just the first few lines, the connection list is pretty long … . Otherwise, it is interesting whether I am alone with this “problem” or whether others are less observant.

If the error lasts for 3 days and the HaaS output is not checked, no one will find out. Processes are running and not working

[Skippi]

It seems that your Turris received private IP address (10.48.210.230).
Can you check it using ubus call network.interface.wan status | grep address?

In this case it is quite normal that you cannot see anything in HaaS - you are not connected directly to public Internet, so only other users from your ISP are able to reach your TCP port 22.
And GRC ShieldsUP! is not checking ports on you Omnia, but port of your IPS router.

[JardaB]

this IP address is determined by my internet provider as the IP in its LAN. … it is based on the router settings.

At the same time I am assigned a fixed external IP for the Internet 93.91.50.207. I don’t know what method the provider used, I’m not an expert (NAT translation?). This topic does not solve the problem

[jada4p]

I got simmilar situation - HaaS log is full of messages like

2022-04-25T18:24:38 CRITICAL twisted ‘channel open failed, direct-tcpip is not allowed’

Last few of log lines which are not simmilar to above displayed error are

Traceback

builtins.KeyError: 4294967295
Traceback (most recent call last):
File “/usr/lib/python3.7/site-packages/twisted/internet/tcp.py”, line 243, in doRead
File “/usr/lib/python3.7/site-packages/twisted/internet/tcp.py”, line 249, in _dataReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py”, line 703, in dataReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py”, line 728, in dispatchMessage
— —
File “/usr/lib/python3.7/site-packages/twisted/python/log.py”, line 103, in callWithLogger
File “/usr/lib/python3.7/site-packages/twisted/python/log.py”, line 86, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/python/context.py”, line 122, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/python/context.py”, line 85, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/service.py”, line 45, in packetReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/connection.py”, line 295, in ssh_CHANNEL_EOF
builtins.KeyError: 0
Traceback (most recent call last):
File “/usr/lib/python3.7/site-packages/twisted/internet/tcp.py”, line 243, in doRead
File “/usr/lib/python3.7/site-packages/twisted/internet/tcp.py”, line 249, in _dataReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py”, line 703, in dataReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/transport.py”, line 728, in dispatchMessage
— —
File “/usr/lib/python3.7/site-packages/twisted/python/log.py”, line 103, in callWithLogger
File “/usr/lib/python3.7/site-packages/twisted/python/log.py”, line 86, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/python/context.py”, line 122, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/python/context.py”, line 85, in callWithContext
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/service.py”, line 45, in packetReceived
File “/usr/lib/python3.7/site-packages/twisted/conch/ssh/connection.py”, line 308, in ssh_CHANNEL_CLOSE
builtins.KeyError: 0

Aren’t there some problems with HaaS? On HaaS device page for my TO (5.3.8 HBT, 2GB, WiFI, Sentinel, HaaS, RIPE Atlas, lxc) there are some entries, i.e.HaaS is running…

Where is the problem? What can/should I do to solve it?

[JardaB]

Again (repeatedly) I am in a state where Honeypots and HaaS do not work because they have closed ports. In reForis everything is installed and enabled, in the processes they are visible as running.

Last attemp in HaaS is this 2022-05-04 13:52:48 45.9.20.25 0 web qwerty1
x
xxx

---

The last recorded IP address 45.9.20.25 is special
“This IP was reported 65,513 times. Confidence of Abuse is 100%.”

This almost indicates that Honeypots and HaaS were to blame for this address

Abongo IP Address Report on 45.9.20.25

https://www.abuseipdb.com/check/45.9.20.25

---

xxx
x

Commands

root @ Turris_JB: ~ # /etc/init.d/haas-proxy restart
root @ Turris_JB: ~ # /etc/init.d/sentinel-proxy restart

it won’t change anything. In the past, only the reinstallation (disable and subsequent enable in reForis) of Honeypots in reForis helped. I tried to restart today - it helped.

It seems like a serious matter to me, it happens again and I can’t diagnose the problem (some debug).

===#

===#

===#

===#

[DIKKEHENK]

Normally i test it with putty from another ip to see if 22 is open.
But my suggestion towards the turris deathstar HQ, is to combine HaaS with the sentinel FW. So, get all honeypots in one application, instead of 2 differente ones.
Might save us a lot of trouble in the future?

Best, Dikke

[JardaB]

As I wrote at the beginning … I find out the problem by chance because I either lack records on the HaaS server, or I test the ports HaaS and Honeypots (21,22,23,25,80,587) at adress
https://www.grc.com/x/ne.dll?bh0bkyd2

so now everything is fine (port 587 is blocked by my email client)

reForis pretends that everything is working according to the plan Unfortunately, I can’t make any diagnostics that causes the problem

[JardaB]

Outage

[Ritchy]

Probably not right here, but does HaaS work for you? Login has been reporting to me for quite some time:
Internal system error
Sorry, but something went wrong. We have logged the error and will look into it.