Since I get Dynamic Public IP and I am running a web server I supposed that there will be some activity in HaaS log. But it claims that there is 0 sessions so far. It’s 3rd month I am open to the internet and nothing. Was I so lucky or something is not working?
TOS 3.10.1 brought also some changes to the firewall, if I am not mistaken, perhaps causing this. Apparently the ipt rules set by HaaS are not in play. Haven’t found a workaround yet.
It must have break with the updates. I did not change configs since I switched to rc.
I do get rqandom connectivity loss due to weak signal. But even now when there is internet acces and I hit refresh there is an error.
Will try to search in logs for related lines and update.
Now firewall works but not uCollect (its enabled and started in services)
I did also get:
2018-06-11 17:52:53 info kresd[10461]: [ ta ] next refresh for . in 24 hours
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘a.root-servers.net.’, type: 1
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘a.root-servers.net.’, type: 28
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘b.root-servers.net.’, type: 1
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘b.root-servers.net.’, type: 28
[…] ascending letters untill m[…]
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘m.root-servers.net.’, type: 1
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve address ‘m.root-servers.net.’, type: 28
2018-06-11 17:52:53 err kresd[10461]: [priming] cannot resolve any root server address, next priming query in 10 seconds
but when I try it manually, it works: root@turris:~# nslookup a.root-servers.net nslookup: can't resolve '(null)': Name does not resolve Name: a.root-servers.net Address 1: 198.41.0.4 a.root-servers.net Address 2: 2001:503:ba3e::2:30 a.root-servers.net
Right now I’m thinking about three issues, which can cause it.
You don’t have public IPv4 address
Your ISP is blocking port 22.
You’re behind NAT.
In 1st issue it’s should be easy to test it. You said that you have web server, if it is running on the Omnia and it works from the outside then you can try to access the SSH remotely. Probably in your case it won’t work. So the issue could be that your ISP is blocking some ports or you’re behind NAT.
ISP is not blocking that port I asked them to disable all filtering and I can ssh to the debian server in lxc container from outside (via VPN to avoid nat loopback). I forwarded ports in firewall settings to be able to do so and it works.
I am not behind NAT. I used to be but I have solved it to be able to host web server. I do have IP directly on the wan interface and it’s public ip.
So none of the three ;(
EDIT:
After some try outs (Thanks! @Pepe) I think the issue it that my ssh server on the router is "Refusing Connection"s on port 22 instead of silently routing it to the honeypot on port 2525.
Yup you are right. I looked at /etc/init.d/haas-proxy and then I tried to force the firewall rules by setting: uci -q set haas.settings.setup_fw=0 uci commit haas.settings.setup_fw uci commit firewall /etc/init.d/haas-proxy check_fw
but it doesn’t work as well. I have no more ideas what might be broken.
and I can see with netstat that haas-proxy is listening on port 2525. Seems like ssh server is not working for connections from outside or turris firewall rules are not applied to forward to honeypot or the problem in honeypot itself. I am not familiar with the implementation of that mechanism.
tcp port 2525 is the correct port for the HaaS socket to listen on. Traffic from tcp port 22 on your WAN ip is being forwarded to tcp port 2525 on your WAN ip.
The thing is that I do not have port 22 open to the public:
PORT STATE SERVICE
23/tcp open telnet
53/tcp open domain
80/tcp open http
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
2323/tcp open 3d-nfsd
3128/tcp open squid-http
8080/tcp open http-proxy
That is the point of HaaS, tcp traffic on port 22 is just being forwarded (as in redirected) to port 2525. At latter HaaS is then ingressing the traffic into the honeypot and letting the agents doing their probing to a certain extent and collecting the data you then can peruse on the HaaS website.
OK I found a reason and temporary solution. So in short why my haas didn’t work:
In /etc/init.d/haas-proxy in check_fw function there is a variable
WAN_IP=“ubus call network.interface.wan status | sed -n 's|.*address":[[:blank:]]*"\([0-9.]*\)".*|\1|p'”
and it returns no value for me. Thats why firewall rules are not applied.
I know its not good solution but I found a workaround to set WAN_IP to: WAN_IP="curl myip.dnsomatic.com" in my temporary /etc/init.d/haas-proxy_TEST.
after restart of that temporary test service I get port 22 open when I scan my IP with nmap and I could login to honeypot like that: areyouloco@frank:~ $ ssh root@mydomain.tld root@mydomain.tld's password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law. root@svr04:~# su root@svr04:~# cat /etc/*version Noneroot@svr04:~# timed out waiting for input: auto-logout Connection to haas-app.nic.cz closed. Connection to mydomain.tld closed
I think it might be the main reason for my other issues. I am sending my wishes to the TurrisTeam to help me find the exact issue. Willing to post logs, debug, break stuff. Thx!
EDIT:
Will post some results after few login attempts from the https://haas.nic.cz/ after it (hopefully!?) updates logged credentials.
YEAH! I got my first 3 sessions logged! So I know the workaround is working. So @Pepe it was reason no.1 but kinda hidden. i do get public IPv4 but it’s not shown in interface statistics.