There was a simple known method for blocking file downloading by extension described in MIKROTIK-WIKI at 2013
It seems that method was working when I have bought my first MIKROTIK router in beginning of 2015. The ROS Version was 6.20 or 6.21
Being learning and using MIKROTIK I have no need to use block downloading feature up today.
But Now I urgently need it.
So what I have:
HARDWARE:
3011UiAS, firmware 3.27
2011UiAS-2HnD, firmware 3.33
Both routers have latest stable ROS 6.35.1
The initial goal: to block downloading .exe file for any local IP.
The final goal: to block executable files downloading by their extensions (EXE, MSI, COM, SCR, etc) for all lan network (192.168.1.0/24) except administrators IP list.
The test download page: any legal with .exe, for example mikrotik downloads
The simple WIKI method by Firewall Filter rule DOES NOT work for any exe-file downloading:
Only blocking by name of url works. The rule is the first in the list.
I had nontrivial configuration in my router. So I backuped it and reset router to default configuration and create rule again. I still can’t stop downloading EXE file. Rule does not work.
Then I tried more complex method “Layer7 + Mangle + Queues” found here.
It does not work too.
Does something changed since old Router OS (where mentioned blocking methods worked) or am I doing something wrong?
Is there working method for current Router OS to block file downloading by their extensions except using WEB PROXY?
Your rule is fine (sort of, see below). If it does not work, you must have some other rule before it, which matches the packet (e.g. standard accept established connections) and it never gets to your blocking rule.
But if I was you, I’d just give up. First, trying to find “.exe” in all tcp packets (you do not have any port filter) will kill your router’s performance. And in the end, all effort is wasted anyway, because everything is slowly moving to https and you have no chance to use content matching there.
It is not the RouterOS that has changed, but the world has changed.
Now almost all connections are encrypted, so the router cannot look in the packets anymore and what you are
trying to do is now impossible.
Furthermore, I would not advise this method anyway as it will block any packet that happens to contain .exe
so you will have lots of false positives (e.g. when reading this message).
It is better to protect your computers another way, e.g. by using AppLocker policies or other software that protects
computers against unwanted executables.
This is pretty much a job for a dedicated filtering proxy host.
There are howtos on the Internet for configuring squid (a popular http proxy) + clamAV as a virus-filtering web proxy. Simply looking for .exe in URLs is a pretty weak method to stop users from downloading executables, anyway. What about FTP? What about email? What about other vectors? What about SSL? What if users connect via VPN to some outside location and download through that? What if the file has an intentionally-wrong extension (saved as .jpg - rename to .exe and run it after downloading)
If you want to govern network policy with an iron fist, then you need to use a SOCKS proxy and ONLY allow that proxy host onto the Internet, and ONLY allow users to reach the proxy host on certain ports where you intend to have allowed services.
That’s how it worked at Chase, and it was quite annoying as a user to have to set everything to use the proxy - (PERL CPan never quite wanted to work right with it, for instance) - but that’s how you have to do things if you want to really close off the Internet except for what you want.
I agree with most of the arguments. I just migrate from old Windows 2003 + ISA 2006 server that played a firewall-router-proxy-and-many-more roles in my network.
The blocking executable files was a policy of my ISA Server 2006 and it was effectively enough within several years.
Concerning FTP: By policy of my company FTP access was blocked for regular users.
Of course, the times have changed, and SSL comes everywhere.
But I wanted to protected my network not from deliberated attempts downloading executable files, but from accidental ones, especially at suspicious, untrusted, unsecured sites. I guessed the malicious minor sites unlikely will have SSL-certificate.
But finally you persuaded me not to find solution with mikrotik only.
By the way, what do you say about controlling internet traffic by union MIKROTIK+SQUID?
I have a brand new QNAP TS–451 NAS in my network. QNAP have SQUID application (but I din’t install it yet).
Several years ago I had initial and perfunctory test of SQUID at Ubuntu.
Is QNAP’s SQUID good enough for controlling traffic for 30-50 users network?
That is why I suggest you to take a look at AppLocker (unknown to most admins - standard component of Windows!)
and configure it at least to not allow executables to run in the %TEMP% directory or better the %USERPROFILE%.
Then the users who accidentally click something that is turning out to be an executable are protected quite well.
And it also works when the executable is in mail or is fetched over encrypted link.
I’m looking into subscribing to SpamHaus’s DBL - in particular, the RPZ feed.
DBL is their blacklist of hostnames / domain names which are hosting malicious content / spam landing pages / etc.
So if some spam message contains an image hosted on one of these domains, the email content filter can find this URL and determine that it’s spam.
RPZ is a form of “firewall rules” for DNS servers. RPZ allows you to override normal DNS behavior for various hostnames / domain names. This is how OpenDNS operates, for instance. If you request evilhost.evildomain.com then instead of getting its real IP back, the server responds with some other configured response such as “no such host” or possibly the IP of a walled-garden server you may build with a “you tried to go somewhere evil” page.
Subscribing to the RPZ form of the DBL and using it on your organization’s DNS servers is probably a great way to protect users from accidentally following malicious links on the Internet.
I recently started downloading and converting their drop and edrop lists into an ipset on my server, and in a week, it’s already denied 606 connection attempts.
Of course the problem with that is that it blocks overly wide, just like spam filtering with those systems does.
It blindly assumes that when a domain hosts one malicious file (or sends one spam mail), all other content from
that domain (or all mail from that host) is to be blocked as malicious.
This works in cases where a specific domain is created for malicious purposes, but it fails in cases where
malicious people obtain access to some system, maybe via a user account, to host that malicious file.
E.g. when a file is put on dropbox or google drive, it would have to block access to the entire system.
When you convert hostnames to IP addresses and block those, it becomes even worse: more than one site
may be hosted on the same IP address and you are going to be blocking completely unrelated sites.
For this reasons I don’t like this method. But more important: it is always after-the-mishap remediation, just
like a virus scanner. Useful for long-living static malware, but not up to par with today’s fast changing situations.
Therefore I always prefer to guard systems with policies that work equally well no matter what the source of
the executables is. I have used “Software Restriction” (now called “Applocker”) ever since deploying Windows XP,
after having used “trustnoexe” on Windows 2000. Ths sort of solution works, no matter where and how the
programs are entering the system.