it is not wise to block port 8291, because the exploitable service is on http port 80 tcp.
The worm uses port 8291 to identify possible victims (when it can connect to port 8291 it assumes there is a MikroTik router on that address), then attacks it on port 80 and some other ports that people may likely have set as an alternative for HTTP access to the router (8080 etc).
So blocking port 8291 effectively blocks the worm in its current version, while not destroying the useful port 80. Of course experience with earlier events like this shows that such a worm typically evolves and may skip the port 8291 scan later, rendering this block ineffective.
For now, I have blocked access to port 8291 from addresses outside AMPRnet on our gateway. Of course this restriction will be lifted when/if this worm stops operation.
It appears to be controlled via a peer-to-peer network and it looks like it is a version of an existing worm that has been active on network cameras/recorders, routers from other manufacturers, etc, all running embedded Linux.
Rob
Hello,
I recommend disabling the access to unneeded management services and to the remaining ones, restricting the access to them from the networks used by the administrators.
Something like this at the command line (also available in Winbox/Webfig in the IP->Services menu):
/ip service set telnet disabled=yes set ftp disabled=yes set www address=44.158.0.0/24,192.168.0.0/24 # Change this address blocks to fit your networks set ssh address=44.158.0.0/24,192.168.0.0/24 # Change this address blocks to fit your networks set api disabled=yes set winbox disabled=yes set api-ssl disabled=yes
regards! 73!
On 2018/03/28 21:46, Rob Janssen wrote:
it is not wise to block port 8291, because the exploitable service is on http port 80 tcp.
The worm uses port 8291 to identify possible victims (when it can connect to port 8291 it assumes there is a MikroTik router on that address), then attacks it on port 80 and some other ports that people may likely have set as an alternative for HTTP access to the router (8080 etc).
So blocking port 8291 effectively blocks the worm in its current version, while not destroying the useful port 80. Of course experience with earlier events like this shows that such a worm typically evolves and may skip the port 8291 scan later, rendering this block ineffective.
For now, I have blocked access to port 8291 from addresses outside AMPRnet on our gateway. Of course this restriction will be lifted when/if this worm stops operation.
It appears to be controlled via a peer-to-peer network and it looks like it is a version of an existing worm that has been active on network cameras/recorders, routers from other manufacturers, etc, all running embedded Linux.
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Blocking port 80 and 8291 is a very good idea and should be standard. You only allow access to those ports (and in fact all services on the router) from certain management ranges. You don’t block it in the forward chain but in the input chain. Make sure you allow “related,established” connections in in the input and forward chains as a first rule.
You never leave any mgmt ports or services on your router open to the world, that is basic security and should be common sense :)
Ruben - ON3RVH
On 29 Mar 2018, at 00:04, Pedro Ribeiro ct7abp@gmail.com wrote:
Hello,
I recommend disabling the access to unneeded management services and to the remaining ones, restricting the access to them from the networks used by the administrators.
Something like this at the command line (also available in Winbox/Webfig in the IP->Services menu):
/ip service set telnet disabled=yes set ftp disabled=yes set www address=44.158.0.0/24,192.168.0.0/24 # Change this address blocks to fit your networks set ssh address=44.158.0.0/24,192.168.0.0/24 # Change this address blocks to fit your networks set api disabled=yes set winbox disabled=yes set api-ssl disabled=yes
regards! 73!
On 2018/03/28 21:46, Rob Janssen wrote:
it is not wise to block port 8291, because the exploitable service is on http port 80 tcp.
The worm uses port 8291 to identify possible victims (when it can connect to port 8291 it assumes there is a MikroTik router on that address), then attacks it on port 80 and some other ports that people may likely have set as an alternative for HTTP access to the router (8080 etc).
So blocking port 8291 effectively blocks the worm in its current version, while not destroying the useful port 80. Of course experience with earlier events like this shows that such a worm typically evolves and may skip the port 8291 scan later, rendering this block ineffective.
For now, I have blocked access to port 8291 from addresses outside AMPRnet on our gateway. Of course this restriction will be lifted when/if this worm stops operation.
It appears to be controlled via a peer-to-peer network and it looks like it is a version of an existing worm that has been active on network cameras/recorders, routers from other manufacturers, etc, all running embedded Linux.
Rob
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
Callsign: CT7ABP QRA: Pedro Ribeiro GRID Locator: IM58mr QTH: São Francisco, Alcochete, Portugal NET: http://www.qrz.com/db/CT7ABP CT7ABP is also home station of CR7AJI Diogo =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Pedro Ribeiro -
Rob Janssen -
Ruben ON3RVH