Allow squid transparent for SSL (blocking only)

Hello,

I just started w IPFire, and it’s cool!

I was hoping to selectively allow HTTPS outbound from green servers, for security reasons

No caching, no MITM. I just want to block all HTTPS sites by default, and allow only selected ones. This is possible with Squid’s SslPeekAndSplice

Is this possible with IPFire?

Thanks!

If the select sights have known fixed ip addresses than yes.

1 Like

Squid’s SSLPeekAndSplice is a MITM tool!
Do want that?

All I want to do is look at the SNI value and block or allow domains based on that :slight_smile:

1 Like

Ah, I think I can explain what @nrm604 is asking for, because I would like this option, too!

As an example, Fortigate firewalls have an option to do URL filtering on HTTPS URLs. Obviously, this doesn’t actually do proper URL filtering, since you can’t see inside the URL. What it does do is have an option to look at the SNI of the URL and if it meets criteria (blocklists, custom blacklist), it will block the site. The reason Fortigate has this as an option is so you can do blocking without needing a proxy set up.

To re-state, this isn’t proper URL filtering any more. However, it does allow blocking access to sites that are blacklisted. I think, perhaps, performing the blocking at DNS resolution (say, a PiHole) probably accomplishes the same task. But I think it would be really nice to at least have this as an option.

The work being done by @jon on RPZ should cover that then shouldn’t it?

https://community.ipfire.org/t/i-created-a-test-version-of-a-rpz-add-on-and-i-am-looking-for-feedback/11934

4 Likes

I’ll have to educate myself! Thank you! :slight_smile:

Edit: It does look like it’s doing the same effect as what was requested.

Would the unofficial plugin Banish work for you?

1 Like

As far as I know, IPBlock lists/ libloc blocks ASNs also. From timie to time there are discussions about blocking of IPs not found in the various IP blocking lists. The solution is mostly, that not the single IP is blocked but the ASN the IP belongs to.

The original request is about blocking by squid, means blocking web access.
The usual process of accessing web pages is

  • client requests a HTTP(S) connection to a FQDN
  • the FQDN is resolved by DNS to an IP
  • connection is established to this IP

To block the access to unwanted pages you can use blocking mechanisms of squid ( demands, the client uses the squid proxy ) or you deny the resolution of the FQDN to the real IP ( by means of the DNS resolver of IPFire device, the usage by the client can easily be forced ).
The latter approach is exactly the way PiHole ( on another LAN device ) or the RPZ functionality of unbound ( inside the IPFire device ) work.

@nrm604 this can also be done by eBPF with something like peetch/peetch/ebpf_programs/peetch_uprobes.c at master · quarkslab/peetch · GitHub to extract HTTPS server name (SNI extension) from TLS/SSL clienthello header, drop or allow based on the HTTPS site server name. ipfire kernel needs to enable eBPF feature though, I have eBPF kernel feature enabled in my ipfire clone GitHub - vincentmli/BPFire: BPFire development tree

actually I take back my initial suggestion on eBPF, if the SSL request is initiated from your server behind ipfire, you still need some kind of proxy/squid or MITM in ipfire, ipfire has no visibility to the SSL header since ipfire works at netfilter/iptables layer which simply forward the SSL request based on layer 3/4 iptables firewall rules. eBPF has hooks on XDP/TC layer where eBPF program could be attached to decode the SSL request that is in raw packet or SKB form, but this kind of eBPF program is hard to write and hard to pass eBPF verifier which make sure eBPF program to be safe to run, for example someone attempted here c - BPF verification error when trying to extract SNI from TLS packet - Stack Overflow.

it is possible to have eBPF based proxy to achieve this, I haven’t found any existing one, this is an interesting request worth doing some research :slight_smile:

1 Like

@nrm604 another option is you can block all DNS domain request from servers in green network, and only allow some DNS domain request go through, this can be done in iptables with hex string, for example Blocking DNS requests via IPTables - NOC Help Documentation

@nrm604 just FYI, I have added eBPF XDP DNS denylist feature in BPFire, for example, add example.com to the denylist, any sub-domain of example.com will be blocked, way much easier than IPTables. https://youtu.be/luFBhVU8FPM?si=qz3_HfJs-SfNda54, I also added Lunatik LuaXDP addon to BPFire, which can block TLS/SSL based on server name indication extension (SNI) without descrypting the traffic. users can write Lua script for TLS parsing and program kernel. Is eBPF driving you crazy? Let it run Lunatik instead! | by Lourival Vieira Neto | Medium

DNS denies can be easily implemented by RPZ lists for unbound ( IPFire’s DNS ‘server’ ).

IPFire’s standard policy is ‘allow traffic from WAN, if the connection is initiated from LAN’. Therefore suppressing unwanted connections can be done by suppressing DNS resolution. IMO

XDP does the same thing as RPZ list then, except XDP performs better than unbound since the DNS query has to travel through all the stack from driver to netfilter to UDP stack to unbound. XDP also uses Longest Prefix Match Trie Map, easier to block one domain and it’s sub domain

I think green0 network user could bypass ipfire unbound if the user configure an external DNS server say 8.8.8.8 instead of using ipfire’s , the ipfire unbound will not be able to process the DNS query. for XDP, as long as user use green0 IP as their gateway, every packet including DNS query has to pass through XDP, and it will be blocked by XDP.

Yes but you can follow this section in the wiki to prevent that.

Force clients to use IPFire DNS Server

2 Likes

got it, but with XDP, you don’t need to do anything :slight_smile:

Then if you want to follow up further with your XDP approach with IPFire you need to complete the development mailing list conversation you were having with @ms but you never came back to answer the questions that were raised in that thread.

As this is central to the security and core functionality of IPFire it needs to be fully discussed and understood that it is not going to allow any security issues with how the firewall works.

That may well involve a lot of back and forth discussion to get clarification on all questions etc.

1 Like

You have to install XDP and configure it. :wink: