Sounds like this could be from a potential scan. The record is useless as 0.0.0.0 doesn’t go to anything.
We can block this type of behavior by blocking inbound DNS request. Change in-interface to your interface or change to an interface list.
ip firewall filter add chain=input protocol=6 dst-port=53 in-interface=ether1 action=drop ip firewall filter add chain=input protocol=17 dst-port=53 in-interface=ether1 action=drop
Note that there are a couple of limitations of using the Cloud Hosted Router (CHR). The main issue is that the default license doesn’t allow for more than 1Mbps on each interface.
Download the VDI version of CHR from the Mikrotik downloads page.
Mikrotik has instructions for installing CHR in VirtualBox, so this post is more of just a summary.
https://wiki.mikrotik.com/wiki/Manual:CHR_VirtualBox_installation
The easiest way to spin up more vm’s to right click on the VM and Clone.
We’ll create a tunnel between two Mikrotik RouterOS routers. Once we have the tunnel connected, we can then route traffic between them.
Note: You can add Preshared keys, but we don’t cover that in this post, just to keep things simple. Check out the following post if you want to add Preshared keys.
How to Create a Preshared Key for Wireguard
Here is how we will want our routers set up. The WireGuard PtP IP is the IP addresses used on both ends of the tunnel. The WAN IP is the IP of each Router. Local IP on Host B is setup to distribute DHCP.
Host A
WAN IP: 172.16.0.1
WireGuard PtP IP: 10.1.1.1/30
Host B
WAN IP: 10.0.0.2
WireGuard PtP IP: 10.1.1.2/30
Local IP: 192.168.0.1/24
We need Host A to be able to access Private IP’s (192.168.0.0/24) behind Host B.
We’ll pretend that the 172.16.0.1 address is a public IP, and Host B, is behind some sort of NAT network.
To create the Point-to-point, or PtP, we will create a WireGuard VPN tunnel, and then add routes from Host A to Host B.
For each Mikrotik we need to create a WireGuard interface, and then a peer. One of the peers needs a keep alive if we are behind a NAT.
Here is an overview screenshot of what our WireGuard settings will look like. Host A is on top, and Host B on the bottom. On the left are the WireGuard interfaces, and the right contains the Peers.
We copy the Public Key from the remote WireGuard interface, to the Public Key on the local Peer. I.e. The Host_B Peer contains Host_A’s Interface Public Key and vice verse
If you want to, you can use the WinBox GUI to setup and configure the router.
Create the WireGuard interface
/interface/wireguard/add name=wireguard-Host_A disabled=no
Add IP address 10.1.1.1/30 to the newly created WireGuard Interface in /IP/Address
/ip/address/add address=10.1.1.1/30 interface=wireguard-Host_A disabled=no
Create WireGuard Peer, WireGuard -> Peers
interface/wireguard/peers/add interface=wireguard-Host_A public-key=HOST_B_WG_PUBLIC_KEY allowed-address=10.1.1.0/30,192.168.0.0/24
Add route for 192.168.0.0/24 to point to 10.1.1.2
/ip/route/add dst-address=192.168.0.0/24 gateway=10.1.1.2
*The Allowed Address sets which addresses work on the other side of the tunnel. If we don’t specify 192.168.0.0/24, then we won’t be able to route to those addresses. If we don’t add 10.1.1.0/30, then our tunnel won’t work at all. Since we only need to route to the 192.168.0.0/24 network from the Host A side, we don’t need this IP range on Host B.
Create the WireGuard interface, WireGuard -> Add
/interface/wireguard/add name=wireguard-Host_B disabled=no
Add IP address 10.1.1.2/30 to the newly created WireGuard Interface in /IP/Address
/ip/address/add address=10.1.1.2/30 interface=wireguard-Host_B disabled=no
Create a WireGuard Peer, WireGuard -> Peers
/interface/wireguard/peers/add interface=wireguard-Host_A public-key=HOST_A_WG_PUBLIC_KEY endpoint-address=172.16.0.1 endpoint-port=13231 allowed-address=10.1.1.0/30 persistent-keepalive=00:00:30
That should be it. Verify that there is a connection. From Host A, ping 192.168.0.1 or any other remote device.
Unfortunately, there appear to be some wonky bugs with WireGuard on RouterOS. It does appear to be getting better, but here are a couple things to check if the tunnel is not connecting.
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
Things to harden
Before deleting the default admin user, create your own user account.
/user/add name=MyUsername group=full password=mylongsecurepassword
Note: running /user/add will prompt you for the rest of the options.
Delete the default admin user with
/user remove admin
We want to delete the default admin user for two reasons. 1. There is no default password for this user. 2. It is a default username which means it will be targeted for brute force attacks.
Consider using the /users/groups for more granular control.
In the following, we disabled all services except SSH and Winbox. We also limit access to those services only from private “RFC 1918” IP addresses. Customize as needed.
/ip service set telnet disabled=yes set ftp disabled=yes set www disabled=yes set www-ssl tls-version=only-1.2 set ssh address="set winbox address="192.168.0.0/16,172.16.0.0/12,10.0.0.0/8" set api disabled=yes set winbox address="set winbox address="192.168.0.0/16,172.16.0.0/12,10.0.0.0/8" set api-ssl disabled=yes tls-version=only-1.2
for www-ssl and api-ssl, tls-version is not a required argument, but you may consider using it if you need the API or Webfig.
/ip/ssh/set strong-crypto=yes allow-none-crypto=no always-allow-password-login=no host-key-size=4096
And regenerate the SSH host key. It will prompt for a [y/N], hit y to regenerate.
/ip/ssh/regenerate-host-key
Unless your device is being used as a DNS resolver, it is best to disable the “Allow Remote Request”
ip dns/set allow-remote-requests=no
If you do need it enabled, then be sure to add some firewall rules to keep your router from being used in amplification attacks.
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp
You can configure interface lists in /interface/list or Interface -> Interface List in the gui
Or you can change to in-interface and specify the WAN interface directly. You could also set it to !LAN if you have a LAN interface list set up.
Mikrotik Recently patched CVE-2023-37099 which was a way someone with an admin account, could escalate to a “super admin”, or jail break a router.
It appears the technique has been around for about a year.
Affected versions: < 6.49.7
The good news is that someone would already have to have an account to elevate permissions. If your routers have been using strong passwords or SSH public/private keys and have internet management disabled, then you are probably fine.
https://help.mikrotik.com/docs/display/ROS/OSPF
Setting up OSPF between Mikrotik routers is not too difficult. The following commands should work with RouterOS version 7+. Run these commands on each Mikrotik changing out the router-id.
First it would be a good idea to create an loopback interface that will stay up. We’ll use this address as the router-id. This should be unique per router.
/interface/bridge/add name=loopback
/ip/address/add address=1.2.3.4 interface=loopback
Now lets setup OSPF.
First we’ll create the instance. Use the address from the above loopback address. Technically you can use whatever id you want as long as it is a 32 bit “address” and is unique.
/routing/ospf/instance/add name=default router-id=1.2.3.4
IMPORTANT NOTE: If this router is also the default gateway, you’ll need to specify the “originate-default=always” option to share the default gateway over OSPF to the other routers. You don’t have to do this if you don’t want to share the default route.
Now we can create an OSPF area. For a simple OSPF setup, we’ll just use the default 0.0.0.0 area.
routing/ospf/area/ add name=default area-id=0.0.0.0 instance=default
Now we can add an instance. This is responsible for what networks get shared with OSPF. If you want to do all the addresses on the router, then use 0.0.0.0/0. If you only want to do specific networks, run an entry for every network, changing 0.0.0.0/0 to the network of interest.
/routing/ospf/interface-template/add networks=0.0.0.0/0 area=default
After that we can check to make sure things worked.
/routing/ospf/neighbor/print
You should see at a neighbor. It can take a little bit for the neighbors to show up.
You can also check the routes on the router.
/ip/route/print
OSPF has a default distance of 110, so checking the routes is a quick way to verify the routes are getting updated. Do note that if you have a static route in with a lower distance, that will take precedence over OSPF.
The goal for this script is to alert us if a remote site looses power. We can do this using a Mikrotik that has two PSUs. One is plugged into battery backup and the other in the non battery plug.
In this example, we are using PSU2 “number 8” We can find the number using
/system/health/print
We can now create a new scheduler entry with the following. Change out the number 8 to your PSU number, and change the webhook to your Teams webhook.
:local curState [system/health/get value-name=value number=8]
:local name [/system/identity/get value-name=name]
:local webhook "https://teams.webhook.microsoft.com/webhook/more"
if ($curState != $lastState) do={
if ($curState = "ok") do={
/tool fetch http-method=post http-header-field="Content-Type: application/json" http-data="{\"text\": \"$name : Power is on.\"}" url="$webhook"
}
if ($curState != "ok") do={
/tool fetch http-method=post http-header-field="Content-Type: application/json" http-data="{\"text\": \"$name : Power is off. On battery backup\"}" url="$webhook"
}
:global lastState $curState
}
Set to the appropriate interval (i.e. 5 minutes). The script will only alert once when the power state changes. This minimizes receiving an alert every 5 minutes while the power is off.
The purpose of these scripts is to update the local DHCP lease table with a remote IP Address Management (IPAM) system.
This little script is added to the scheduler and goes through the entire DHCP lease table and uploads each MAC address and IP address pair to a website.
Change out the top three variables. May also need to change out the URL depending on how the website receives data.
:local url "upload.incredigeek.com"
:local username "myapiuser"
:local password "passwordforapiuserwebsite"
/ip/dhcp-server/lease/
:foreach i in=[find] do={ :put ([get $i address]." ".[get $i mac-address])
:local ipaddress ([get $i address])
:local macaddress ([get $i mac-address])
/tool fetch url="https://$url/api/v1/network/ipam/dynamic_ip_assignment?ip_address=$ipaddress&mac_address=$macaddress&expired=0" mode=https keep-result=no user=$username password=$password
:delay 1s;
}
This script is to be used on the DHCP server script. Can add it by going to DHCP Server -> DHCP -> Double Click Server -> Script
Any time a new DHCP lease is obtained, this script is fired. Note that some of the variables like $leaseBound are specific to the script being used by the “DHCP server”
Also helpful to note that the script only runs if a new lease is obtained, or a lease expires and it disappears from the leases page. A DHCP renew does not trigger the script.
:local username "myapiuser"
:global password "myapipassword"
:global url "upload.incredigeek.com"
# The maximum retries
:local max 60
:local attempts 0
:local success 0
:do {
:set attempts ($attempts+1);
:if ($leaseBound = 0) do {
:do {
/tool fetch url="https://$url/api/v1/network/ipam/dynamic_ip_assignment?ip_address=$leaseActIP&mac_address=$leaseActMAC&expired=1" mode=https keep-result=no user=$username password=$password
:set success 1;
} on-error={
:log error "DHCP FAILED to send unassignment to $url on attempt $attempts out of $max for $leaseActMAC / $leaseActIP";
:delay 10s;
}
} else {
:delay 1s;
# see note below
:local remoteID [/ip dhcp-server lease get [find where address=$leaseActIP] agent-remote-id];
:do {
/tool fetch url="https://$url/api/v1/network/ipam/dynamic_ip_assignment?ip_address=$leaseActIP&mac_address=$leaseActMAC&expired=0" mode=https keep-result=no user=$username password=$password
:set success 1;
} on-error={
:log error "DHCP FAILED to send assignment to $url on attempt $attempts out of $max for $leaseActMAC / $leaseActIP";
:delay 10s;
}
}
:if ($success) do {
:log info "DHCP lease message successfully sent $leaseActMAC / $leaseActIP to $url";
:set attempts $max; # break out of the do..while loop
}
} while ( $attempts < $max )
}
The following is the correct syntax needed to send a message to Microsoft Teams from a Mikrotik router. You will need a valid Teams webhook to send to.
Change “Test Message” out for your message. You should receive a “status: finished” response.
/tool fetch http-method=post http-header-field="Content-Type: application/json" http-data="{\"text\": \"Test Message\"}" url=https://domain.webhook.office.com/webhook/long/string
Scripting in Mikrotiks can be a little interesting. This is a quick syntax note for using the foreach command to delete all simple queues.
:foreach queue in=[/queue/simple/find ] do={/queue/simple/remove $queue}