I have what I think is a simple problem. We were given notice that a Copyright abuse claim was made against a public IP in our control. We do own the IP, though I cannot see where we route any traffic through it outbound and we have no service listening on it inbound. I can block it in a RAW filter, but I want to first see where the traffic was going, what the LAN IP was. I suspect we have a game console in the network and employees are streaming movies in off hours. By watching the connection tab in IP->Firewall on our public facing router and filtering for the public IP I want to see, I can see the connection come in but I cannot figure out how to see what my destination LAN ip is. I need that to track down the culprit.
All investigation so far has taken place on the FW. Our topography is as follows.
Internet - > CCR1036 (FW) → CCR1072 (Core Router) → RB2011UiAS (Department Router) → LAN
(1) Check entry/exit log to see which employees show up at work after hours.
(2) Install video cameras
In other words security and employee behaviour is not the IT responsiblity.
What you should concentrate on is understanding that you have done nothing wrong in the config.
a. there is no listening port so you are not allowing any traffic in to the router (input chain).
b. assuming you checked the /ip NAT rules, and confirmed that no ports are open for devices behind the network ???
c. only internal access from the admin/management network has access to config the router (input chain)
d. if there is remote access for config purposes, this is only done through VPN?
Mitigation Strategies, non-punitive
e. add schedule to usage of access to internet only (not lan to lan work) such that no employees have access after hours (except a few like the boss - unless he is a gamer jajajajajaja)
f. use redirect to force all users to use DNS of your choosing ( there are some DNSs out there that permit blocking gaming sites etc…)
g. Only make hotspot access available after hours, and limit bandwidth (queues) such that gaming/torrenting is not worthwhile.
h. Probably a few better ideas out there,
All good points. Logging physical access will not tell me what I need to know as I suspect the problem lies in our Fire Department, we are a municipality. The Firemen have the ability to use the network for gaming and personal devices use while on duty. Their Duty hours are 24 hours on and 48 hours off. We have tried to stop the use of personal devices and we were over ruled by management.
So, as we continue to get notices that an IP on our network is illegally streaming, it is up to me to find the information needed to point to an instance/person/persons and say “There, they did it.” That is why I am trying to pin point the local address that initiates the connections.
If nothing else it might be a compromised device and if so, I want to find it. We have buildings throughout town with each on unique ip schemes. Knowing the local IP will narrow down the search to a building for me.
ISPs often address this by dedicating a restricted range of ports for src-nat (masquerade) operation for every single customer who has a CGNAT or private address from them, as then the combination of public IP and source port directly identifies the client without any logging; this may or may not be feasible for you depending on the size of your network, as you need to give at least tens of ports to each client in order that it worked.
If you cannot do that, I would suggest to add log=yes to your src-nat (masquerade) rule, and to set up the Mikrotik to write log messages with topics=firewall to an external syslog server (or to an USB disk if it has a USB port). The src-nat rule is matched only by the first packet of each connection, so the amount of data will not be terribly high but still too much for the internal disk.
Bad news is I still do not know how I can trace a connection to it’s LAN source, but we did solve the problem.
Looking through routing a second time we discovered that the public IP was being routed to an isolated test server. I suspect that server had been compromised and was being used as a relay or proxy for streaming. The server was shut down, the address was disabled in the IP address list, the FW rules were removed.
The path the traffic was taking was found by following the OSPF tables through the network.
