Hello, I’m a newbie. Please tell me how to block certain sites on the green network. I tried the opaque mode, but it doesn’t block websites. I’ve tried categories and it doesn’t block either. Judging by the messages here, you need to set up a proxy on each computer to block websites, but is there any way to do without it?
I am aware of two ways. One, use a paid DNS service with such features. Two, set up firewall rules that block the IP belonging to said websites. Assuming it is a static IP.
Do you mean blocking web traffic?
To be functioning
- all devices on green must use the proxy, see documentation about this in the community and wiki ( “force proxy usage” may be a aearch pattern )
- all traffic between green clients has to go through IPFire; this not necessarily true for connection with switches ( standard construction of ethernet networks )
BTW: which rules did you try?
1 Like
Please tell me how to block the IP addresses of websites. I can’t figure it out.
First, you need to find the IPs. You can search “find IP of website” in your favorite search engine. Assuming the website uses a static IP or a small block of IPs, this is doable. If they are on a rotating set that is not regular, this may be difficult or impossible, or if it’s a shared IP, you may block other websites pointing to the same IPs.
Second, you need to set up a firewall rule using Firewall Groups. There is documentation online for setting up firewall rules. You can also search “ipfire block ip address” to get you started.
1 Like
This is true.
Yes WPAD
4 Likes
For effectiveness of WPAD the clients to green must be forced to use the proxy (no access to port 80, 443, … on RED is allowed by the firewall).
2 Likes
Is there a way…
yes, but you will have to execute it at every boot time. So you would have to place this code in /etc/rc.local:
iptables -A OUTPUT -p tcp -m string --string "block-me.com" --algo kmp -j REJECT
I haven’t poked around to see if you can just add the iptables rule in the web gui, but this is how you add it if you didn’t have web a front end.
Isn’t a better place firewall.local - www.ipfire.org - firewall.local? You lose anything in rc.local if the firewall restarts.
Would PiHole or Adguard Home, or other DNS blackhole/filter be a easier solution? They are both free. I’m not sure how much OP needs to lock it down, but that would be my first thought. Doing it by domain is so much easier than researching IP scopes.
Blocking using firewall rules and string matching is, in general, a horrible solution IMHO. It may work with http/https but little else. It can work with DNS but then you should not restrict the protocol to TCP, and you may want to block the INPUT chain. Then you get all the attendant problems of DNS tunnelling like DoH.
Better is the RPZ solution which still has DNS bypass issues but is easier than the firewall and less prone to false positives (the firewall rule above will block plain-text emails containing the block-me.com string anywhere in the body if mail is sent unencrypted), but there is no perfect solution.
3 Likes
DNS bypass can be handled by Force clients to use IPFire DNS Server
2 Likes
Yes, that would be a better place to put that.
IP Tables method has always been the standard way to block a URL.
Btw, I really don’t know why they made the iptables page in the web GUI but don’t have a way to add entries to the iptables.
- iptables operates on IP addresses, therefore any extensions using URL(pattern)s request a functioning and intact DNS system.
- iptables is really complex, you can do many things which are not really good. Because iptables ( the firewall! ) is the intrinsic functionality, it is no good idea to allow ‘destruction’ through the WUI.
1 Like
-m string --string “example.com”
-m : match item in packet (have to declare type string or int)
–string : The entry to filter (type string)
This has been around for a while and some routers use this under the hood to block urls.
It still doesn’t make sense not to use it, nor does it make sense to me that there is not a way to add entries to it in the web gui.
But yes, I can see why one would think it couldn’t do block by strings and just ip numbers only.
As far as IP Tables are concern. Everyone that runs this program should learn it since its the core engine to it all. Otherwise, IPFire would just be a switch os.
Sorry, I didn’t lookup the match operation. Thx for the information.
But, matching strings demands the unencrypted contents of the packet. This makes the string match usuable for a subset of packets, only.
well if the intention is to block a url from a client, this is the function.
headers don’t get encrypted until it passes through the DNSSEC server
same with the other direction too, otherwise, the functionality of Nginx hosting multiple web sites wouldn’t work because it uses the header information.
The only thing that stays encrypted in the TLS connections is the message body.
The string match option works but can give false positives as it also detects in the body of mail messages, as an example. It is very resource intensive as it has to look through the whole data stream and not just the packet header. Even Snort/Suricata tries to limit itself to the first X bytes of a stream and not the whole stream.
3 Likes
Back to the initial question.
If I understand the opening post, the topic is to block green clients from accessing nonsense.biz.
Because mostly the process is
- resolve nonsense.biz to an IP
- build up a connection to this IP
I recommend solutions, which deny the resolution of those unwanted URLs.
1 Like
That is interesting because i would think it wouldn’t be resource hungry.
But I will analyse the metrics with it.
the source libs:
pcap.h
ip.h
tcp.h
if_ether.h
the c function of parsing the whole packet, even though refined code would just focus on the header pointer for filtering:
void analyse(struct pcap_pkthdr *header, const unsigned char *packet, int verbose) {
ip_size = sizeof( struct ip );
tcp_size = sizeof( struct tcphdr );
/* Assign each pointer its correct value **/
const struct ether_header *ethernet = ( struct ether_header* ) packet;
const struct ip *ip = (struct ip*) ( packet + ETH_HLEN );
const struct tcp *tcp = (struct tcphdr*) (packet + ETH_HLEN + ip_size );
const char *payload = ( packet + ETH_HLEN + ip_size + tcp_size );
}
This should typically take 12-20 nS to process. So just the header should be less.