Hi,
I want to block web traffic (http and desirable https) made directly to ip addresses, requests from browser or from tools like wget/curl:
wget http(s)://1.2.3.4
I'm using hAP AX2 at home (15 devices on the network).
Is this possible on Mikrotik ?
If yes, can someone help me with the firewall rules i need ?
Thanks
If you have a domain with web pages served from a hosting provider, this will demonstrate the behaviour you require. Which makes me think that this could be managed by the web server. You may need to generate a basic web page to tell people to go away if they try to access the IP address.
I want to block all web requests to any ip address, but allow normal web traffic to fqdn's.
If i type http://x.y.z.w (any ip address) in browser, i want the request to be blocked but if i type http://example.com, i want the request to be allowed.
This type of traffic is also used by malware to download second stage payloads.
Sorry, I hope it's clearer now. I edited the title, also
Generally, no. Many firewall products allow you to something like this, but Mikrotiks are not the device of choice for these purposes.
The way this usually works is that the client is forced tonuse the dns resolver integrated in the firewall, which then tracks the IP addresses returned, then it selectively allows requests only to those addresses. If I recall correctly, there was someone who implemented something similar with Mikrotik DNS and address lists, but as I remember, it had problems.
I searched the forum but found only old threads from 2014/2016 with different types of use cases.
I thought that it should work with an regex for ip address on L7Protocol used on a firewall rule on forward chain but can't find a proper regex to match .... also red that MT is using a custom/old/special type of regex (posix ??!!!!???).
Maybe "TLS Host" and "Content" fields from firewall rules can be used ? but i'm struggling to put them together and decided to ask here.
What you’re asking is illogical.
The connection takes place first and foremost exclusively via IP addresses...
Then >and I wrote then< the system asks what you want to get,
not before. I wrote: not before.
So, by that point, the connection has already been established...
I think you will be out of luck if you are expecting that from the firewall, because the firewall trades only in IP addresses and tcp/ip as protocols.
The more I think about it, the more it looks like this: DNS is resolved for the client machine, so whether the client called on a FQDN or an IP address, the FQDN would not be known outside the client machine, all that would be passed at the level of tcp/ip protocols is the IP address.
The fact that hosting providers will serve out a 'go away' page for a request by IP address but can serve out any of a large number of websites for requests by FQDN indicates to me that the FQDN or IP address will be included within the http[s] request. As http[s] are higher protocols, the packets containing the FQDN or IP address are completely encapsulated within the tcp/ip packets and not normally accessible to a firewall, unless you can do dedicated deep packet inspection. This would be poor design from a performance point of view, because all of your traffic would have to be checked for being http[s] prior even to the firewall using http[s] protocols to unpack whether the request was by IP or FQDN
I would say your appropriate course of action is to harden the webserver to this kind of attack. You just need to detect it in the webserver, probably as an error, and deal with it. You could try finding the IP address of a FQDN addressed substack page for example and make a request to the IP address to see how that system responds. If it works for substack, it is probably plenty good enough for you
I wonder why, first of all, the others didn't answer you about how things work.
requests made directly to any IP address instead of a FQDN
You'd better study how TCP/IP and HTTP(S) works first...
Especially because the connection takes place between IPs, not FQDNs...
The FQDN is just a human-friendly (often abused) way to avoid having to memorize an IP address...
@cibi I understand what you want to achieve - forbid HTTP(S) request that has IP as host in URL, but that it is not possible to do in ROS for HTTPS connection because it is encrypted, only for unencrypted HTTP it could be made using L7 filter with regex that matches if host HTTP header in payload is IP address. Still it is a half of solution and even for HTTP can be bypassed for eg. with VPN.
Such traffic inspection requires more advanced firewall (L7 protocol detection and MITM decryption) which ROS doesn’t have natively and device with a lot of resources.
I fiddled with doing this a while ago and did a write-up. I wouldn’t recommend actually doing this in production, but it illustrates the lengths needed for this sort of thing.
@ghostinthenet This is not for the OP, but for your article that you linked: There is a trick so that the script that copies the DNS cache is not needed (does not require the scheduled script with 1s interval) and should consume fewer resources because only newly resolved entries are added at a time without needing to rescan the whole cache:
But last time I tested, it only works when the upstream resolver is DoH (can also be multiple resolvers, see Strange warnings in the DOH logs - #21 by CGGXANNX).
Thank you all for your time and sorry for confusion.
i want to achieve what @optio said.