28 Mar
2018
28 Mar
'18
4:46 p.m.
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
28 Mar
28 Mar
6:02 p.m.
New subject: MikroTik worm - please check your RouterOS version!
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:
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net 
29 Mar
29 Mar
12:25 a.m.
New subject: MikroTik worm - please check your RouterOS version!
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(a)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:
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2480
days inactive
2481
days old
2 comments
3 participants
participants (3)
-
Pedro Ribeiro -
Rob Janssen -
Ruben ON3RVH