Turris OS 3.10.2 released

release

#1

Dear Turris users,

we just released another update. This version is fixing few issues that you helped us discover. Nothing big, just few minor issues. Full release notes follow.

  • haas: fix firewall integration
  • ucollect: more robust start
  • updater: fix collisions when updating from old versions
  • dvbsky: fix driver compilation
  • nut: fix update
  • kernel, nextcloud: update

As always, if you encounter any issues, let us know.


Turris OS 3.10.2 vydáno
#3

#4

Does not appear being fixed but further confused.

Port scan showing wan port 22 open but it is not reachable (probably missing forwarding). Instead the honey pot can be reached on the wan port 2525 only, which is albeit stealth on a port scan.


Output from haas-proxy.postinst:
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.


Whilst showing in LuCI

Chain zone_wan_prerouting (References: 2)
Pkts. Traffic Target Prot. In Out Source Destination Options
838 48.77 KB MARK tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 MARK set 0x10
838 48.77 KB DNAT tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* haas / to:[wan.ip]:2525
5369 262.71 KB prerouting_wan_rule all * * 0.0.0.0/0 0.0.0.0/0 /
!fw3: user chain for prerouting */

there is no such output from iptables -S and iptables -S zone_wan_prerouting reveals

iptables: No chain/target/match by that name.


HaaS does not log [WORKAROUND]
#5

confirmed, HaaS still seems to be non functional in 3.10.2.


#6

It’s working here? I checked it yesterday ( en just now ) right after the update, and it’s bingo time again? running 3.10.2. Had to X mark the "'send login cred ‘’ in foris again though, that was set off.

From HaaS
2018-06-19 11:44:59 x - xxx.150.60.69 x
2018-06-19 11:44:53 x - xxx.150.60.69 x
2018-06-19 11:44:45 x - xxx.150.60.69 x
2018-06-19 11:44:38 x - xxx.150.60.69 x
2018-06-19 11:44:31 x - xxx.150.60.69

Keep reading this though… “'err nikola[]: (v42) turris firewall rules might not be active”’


#7
Update notifications

Updater selhal:

unreachable: https://repo.turris.cz/turris/lists/base.lua: name lookup timed out


#8

There are log entries appearing on HaaS again but are you certain those are from the intended (ssh) port 22 and not by chance from (its proxy) port 2525? The HaaS log is not providing such information, it just assumes it is port 22.

Did you try to sftp/ssh into port 22 on your wan and reach a login bump? Is there an entry for ports 22/2525 in iptables -S or in the routing table. If neither than chances those log entries are representing attacks on port 2525 rather than port 22.


#9

When my haas / honeypot was actually working I naively assumed that the firewall was really tight and provided 100% protection against the router / network itself being hit by a port 22 or other port attack… Judging by the above thread entries I am no longer sure! Surely any honeypot needs to have cast iron security?? Some reassurance from the Turris team seems appropriate together with a timescale as to when these haas / firewall issues will be fixed. I purchased the TO for its high level of securtity.


#10

Uhm, bit of a nOOb here… but i find this rule?
719 40.42 KB DNAT tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* haas */ to:my own ip:2525


#11

HaaS should not be listening on the wildcard 0.0.0.0, which includes the WAN side but be confined to the router’s lan ip, or perhaps an alternatelo ip. I had this discussion with the HaaS developers but they are not interested to considering such option.


#12

that can be, i’m also not into that. But afaik, it works again after the update.

Also, if i look at the cmd’s that are entered at HaaS, that looks like the evil visitor seems to think it is entering p22.


#13

Don’t panic. Worst case that could happen and what happened before this release was that the forwarding rules didn’t apply often and attacker would be blocked by default firewall on Omnia (unless you manually opened the port) and wouldn’t reach the Honeypot and just hit the firewall. If you have data collection enabled, it will then be collected as attacker trying to get through the firewall (less score than honeypot, but still a bad guy).


#14

I’ve been getting this a lot too since 3.10.1. The updater seems much more sensitive to network disruptions than it used to.


#15

Did you by any chance modified heavily your firewall configuration like deleted some zone pre-setuped by OpenWRT?


#16

Neither should have an impact on HaaS and did not prior to TO 3.10.1


#17

port 22 is opened when HaaS installed but the forwarding to port 2525 is not working. Whilst it does not reach the honeypot any attacker has made it hrough the firewall on port 22 by then and could try to find ways to exploit the system.

For that reason I am removing HaaS, for civis duty certainly not going to comprise the router’s security.


#18

No. All interaction Haas does with firewall is forward port 22 to it’s 2525. So if this fails, default rules apply which block port 22.


#19

I am afraid that is not true - remove HaaS and wan port 22 is closed, install HaaS and wan port 22 is open.
Port opening and traffic redirection are different, I am sure not needing to explain that to you.


#20

Depends what disabled those rather incongruous firewall rules sets means. Default Omnia after factory reset has zone_wan_prerouting chain in nat table. Do you have any idea why your doesn’t?


#21

If you are scanning from the outside, that is the behavior you would observe, but if you check your iptables, you’ll see that the port 22 is not opened, but redirected to 2525. If you try to connect to it, you wouldn’t see your Turris ssh but honeypot. Or you can stop haas-proxy and run socat on 2525 to test.