I have an infected computer somewhere in the VM machines by look
I am getting lots of these packets at the router
output: in:(unknown 0) out:ether1, connection-state:invalid proto UDP, 0.0.0.0:9001->10.0.2.152:9001, len 1492
I can see it’s attacking 10.0.2.152 but how do I work out the source machine .. I really don’t want to crawl thru 200 VM machines 
Use Torch to find the source MAC address. If it hasn’t been spoofed (as that 0.0.0.0 source IP has) it’ll guide you to the matching VM configuration.
If the malware is smart enough and deeply enough dug into your systems that it can spoof the MAC, too, then it sucks to be you today. 
Sorry.
As usual, like the others, you don’t write what you’re talking about…
What is the version of RouterOS?
What does it take to understand that at least the hardware (in this case virtual machine used) and the RouterOS version must be specified?
The system hosting the virtual machines could also be infected…
output: in:(unknown 0)
in unknown???
If RouterOS is unable to define on what input the packet is coming from, probably is the RouterOS itself than generate the traffic…
If the NIC is used from more than one VM or the OS, can be leaked packet between os…
Sorry any omission in details is because we are newbie and don’t know any better
The mikrotik is a CCR-2004-16G-2S+ with O/S 7.6
To mix that up I put a CCR1036-8G-2S+ with OS 6.49.6
No difference both routers showed same behaviour
There are 6 VM’s all different hardware but all running VMWARE eXSI 6.5.0
I was about to say that we should focus on the fact it is in “output” chain and not in “forward” but then I tested it in lab and noticed that forwarded traffic with src-address 0.0.0.0 actually goes through firewall in the output chain! What the heck?
Right now I can’t remember which service is the one using UDP port 9001 with IP 0.0.0.0, something related to IPv6 tunnels?
But as pointed out by @vecernik87, they are packets generated by RouterOS and sent,
they don’t arrive from outside the machine where they are seen (or at most they leave in response of something).
If no RouterOS default services use them, the internal network is probably compromised.
One /export can generate some light.
This document says that UDP port 9001 is often used by tor …
mate, thats exact opposite of my post 
I originally also thought they are from the router, but I wanted to be sure so I tested it in lab, generated packets from a PC with 0.0.0.0 as src-address and sent them to 1.1.1.1 through the router. In ROS I created filter and mangle rules with action=log in each available chain.
It blew my mind that forwarded packet from LAN to WAN appeared in the output chain and not in the forward chain. For mangle (which has few more chains) it was prerouting, output, postrouting.. It did not hit the "forward rules" at all, despite the fact it was being forwarded.
On the other hand, I also had to disable my RP filter, otherwise these packets did not get to the firewall at all.
EDIT: somehow, I can't get the same result today. I promise I was not drunk last afternoon and I was certain that I got the result right....
But your packets had an “in-interface” in the logs, his packets list the interface as unknown, mate.
Vecernik87 is correct I can only filter the packets on the output stream .. the initial log was on the receiving tik
so you pick them up at source tik and drop them via
chain = output interface = the_interface src_address = 0.0.0.0/8
Now you get this log if you log it
output: in:(unknown 0) out:ether1, connection-state:invalid proto UDP, 0.0.0.0:9001->10.0.2.152:9001, len 1492
That drops CPU load by about a quarter on both TIKS .. which made me very happy
There is also possibly something in what Vecernik87 said that something triggers the behaviour because initially it doesn’t happen on site
After a while depending how many people are on network it starts
I thought it just took a while for the attacker to find the new tik which actually doesn’t make sense when I think about it because its the main gateway router.
Now a new piece to puzzle … If I exchange the TIK for a ubiquiti ER12 the behaviour hasn’t been seen in 2 days.
Unfortunately the ER12 is running at route limits and I can’t put queues on the ER12 or it totally bogs down so I can’t use it as a solution.
I am sort of at a loss and currently having to see if I can refurb an old cisco router because I need a solution.
If no-one else has seen the problem it must be my setup but WTF it is I am completely stumped.
Found it by accident it’s dropbox client that triggers the problem not sure if it’s malicious or just my setup
I have an IP4 only network and these are tiks in the middle of the network
The clients have IPV6 ethernet cards and the dropbox client can tunnel directly thru my IPV4 network it ignores all IPV4 queues limits, firewalls and everything
Those packets are max size because they are a tunnel to dropbox
I am guessing the log is sort of a IPv4 reporting an IPv6 packet bug … they just magically appear on the output filter and seem to report like that.
I have never stressed over the IPV6 firewalls especially on routers away from edge not really considering they were in play … wrong
I haven’t looked why the ubiquiti edgerouter doesn’t have the problem but I am guessing they have a default IPV6 firewall that drops all.
So anyone able to help with what I should have on the IPV6 firewalls to drop everything
From my post #6
That’s highly unlikely. In the vast majority of Internet-connected hosts, IPv6 is part of the OS kernel. The primary exception is if you have high-end network interfaces with TCP offloading. Otherwise, IPv6 is well above the level of the “Ethernet card,” which is most often just an IC on the motherboard these days, not a separate add-in card at all.
I’m not being merely pedantic: thinking unclearly about where IPv6 lives will lead you into misdiagnoses.
what I should have on the IPV6 firewalls to drop everything >
The fact that your local hosts all use IPv4-only addressing doesn’t mean you don’t need IPv6. You don’t control the Internet, which does increasingly use IPv6. Also, some LAN-bound applications will use IPv6 internally, amongst themselves, if allowed.
This is because, for about the last 15 years, client OSes have shipped with IPv6 enabled by default. This has a number of implications.
For one, it means that when an application program does a DNS request through certain standard APIs, it’s implicitly asking for any address, not just IPv4. It’s perfectly legal to have an IPv4-only LAN but for IPv6 network connections to go out through the gateway, fetch data from an IPv6 server, and deliver it into your IPv4-only LAN.
The only way to keep your head in the sand on this is to go around to every Internet client — even including things like IoT devices — and disable IPv6 to prevent them from even trying. Blocking IPv6 at the router won’t stop the clients from trying, leading to annoying timeouts: with IPv6 still enabled, they may try it first, then have to wait until they give up on it working before they fall back to IPv4.
Even if you do go and disable IPv6 on every LAN host, there’s an increasing chance that something will then mysteriously break, and then you’ll be back here with another bogus diagnosis about the reason why, having forgotten that you broke it yourself with your blinkered IT policies.
It’s perfectly fine to have an IPv4-only LAN config, but it’s getting increasingly hard to ignore the fact that applications and services will use IPv6 unless forcibly prevented.
Time to get on the train.
Sorry tangent your answer ignores reality
I don’t OWN any IP range in IPV6 how would I even know how to route it to where and why? <<<<
What I do own and control is IPv4 C class licenses and so I must knock down ANY and ALL IPV6 traffic.
At the end of the day I am at the internet edge not in the middle of it.
Whatever advantages IPv6 has is mute on me because I don’t own any range.
I get your bit about the equipment will turn up more and more so I am going to have to learn how to knock it down for now.
I will investigate what is the go with getting IPv6 range licenses but not a huge priority for a WISP.
@rextended yes you were on the money and I wish I had thought about that a bit more would have saved some time.
So we can all agree that your setup sucks.
In your world you can’t do anything on the internet without IPv6 and IPv4 licenses and most small last mile operations shouldn’t be there
or are you saying
Newbie Mikrotik users shouldn’t be allowed because Mikrotiks don’t start with everything locked off like other vendors?
It’s slightly more complicated than that. In modern IT era one can pretty well live without IPv6 … but since many devices now expect to have it, they try to use it. So either you have to try real hard to block/disable it or live with some nuances or embrace it (to certain extent). And the last option is the only future-proof option.
Yes I get that but as I said above the TIKs start in open to world so newbies to them will make mistakes and struggle with them.
Having used Ciscos, Junipers and Ubi Edgerouters for years it feels a bit like a crash test dummy with your first TIK.
If the supply chain strains of current never happened we would probably never have ever purchased a Tik and now we have around 40 of them
They have some nice features but you do fall down some holes as well
It’s currently free to get a /40 or smaller from ARIN if you already have a v4 block from them. If you’re elsewhere in the world, governed by a different addressing authority, there’s likely a similar policy.
You might not even have to go through that bit of bureaucracy. It is likely that your upstream ISP offers DHCPv6 and will give you a /64 or /56 for free. Ask. You might be surprised. This happens even for home ISP customers these days.
It’s the huge IPv6 space that makes this possible. An IPv4 “class C” (properly called a /24 now) is difficult to get and expensive because they’re both rare and economically valuable, creating a marketplace for them, whereas IPv6 is plentiful to the point of having zero market value.
There’s nothing saying you can’t have both IPv4 and IPv6. It’s called dual-stack, with lots of fun options atop that.
What I do own and control is IPv4 C class licenses and so I must knock down ANY and ALL IPV6 traffic.
That’s like saying “I own a BMW, so I must destroy all Chevies.” IPv4 and IPv6 coexist.
Thanks that is useful information and I will follow those up.
Yes what I was explaining is commercial reality the IPv4 /24 blocks are extremely expensive because there is huge demand at the edge.
Even if I could get IPV6 space many of my RF and Fibre Links can’t carry it because the equipment doesn’t support it.
Many of us at the edge would love IPv6 on our management networks because our public /30 links with tunnels consumes those expensive IPv4.
You run privates where you can but eventually you have to come out onto the internet to get back to NOC.
That is why it’s worth following up that I might be able to get IPv6 space.
Commercially unless all the end mile equipment is supporting IPv6 then the market will basically stay IPv4 based.
The is some of the newer stuff with IPv6 but remember we have networks with lots of legacy gear so commercially you just buy the IPv4 and be done with as it’s a cost you can factor.
Upgrading an entire network section would have so many unpredictable deployment costs and risks
For that reason I would start with our monitoring network because losing it for a day or two doesn’t affect customers.