[SOLVED] Custom line of code in squid.conf

[myksto]

I would like to add some lines of code at the bottom of squid.conf (e.g. "error_directory /usr/local/etc/squid/errors/it" or some other acl).

Is there a way to do that? Unfortunately everytime I make a change through the gui the "apply" button delete all my custom lines.

Thanks a lot.

[franco]

Hi myksto,

You can drop custom rules into the following directories, they are automatically included and not overwritten:

Code Select Expand

include /usr/local/etc/squid/pre-auth/*.conf
include /usr/local/etc/squid/auth/*.conf
include /usr/local/etc/squid/post-auth/*.conf

But please mention these in your bug reports as modifications can have side-effects.

If you, however, feel that a feature is missing or you would want to include it into the core templates, please open a ticket here:

https://github.com/opnsense/core/issues


Cheers,
Franco

[myksto]

I really thank you Franco, it works like a charm.
In my case the "post-auth" folder fits my needs by now.

Cheers, Michele.

[franco]

Hi Michele,

Splendid, thanks for the follow-up. :)


Cheers,
Franco

[tux.JCC]

Hi Franco!

We did a simple SubTab that does it (screenshots attached).

If you want we can share the code with you.

Regards!

[franco]

It's not our favourite solution to enable custom file dumps, but if you open a PR on GitHub we can discuss it and optionally hide it under an advanced setting.

https://github.com/opnsense/core/pulls

I just did a similar thing for NTPd cause instead of raising tickets for features people keep asking for a custom block and we would rather add easy features for everyone that can be documented and improved.


Thank you,
Franco

[fabian]

We did a simple SubTab that does it (screenshots attached).

If you want we can share the code with you.

We know how to do that and there is a reason not to do it - It is dangerous for multiple reasons:
* It makes it easy to break the service (results in lots of questions and hard to debug).
* It allows remote code execution (Squid has lots of commands which allow execution of binaries on the system. You effectively allow a user who can do that shell access (probably without knowing that) and therefore it might be possible to compromise the machine.

Regards

Fabian

[tux.JCC]

@Franco, thank you! But I don't want to cause any annoying new thread with a new feature and break the project's  philosophy!

@Fabian, we' made a fork that runs only on our UTM appliances platform, so as a Managed Security Services Provider, who has the root/admin privileges on it is only our trained analysts, so we don't have so much reasons to not to do that, so we do it!  :)

In past, I've worked with BluecoatSG Proxies appliances and they have something they call CPL (Content Policy Language), maybe we can consider something similar, in this way an interpreter do the job of filtering what is danger to apply to daemons config files. Just an idea!  :D

Thank you!

Regards!

[franco]

Hi tux.JCC,

We have rules to build a flexible environment, that in part means we have to adapt rules from time to time. Starting a discussion, adding a disputed PR can both help change views and find other solutions, in the end a better way forward.

The best way is to take a tiny PR and see how that goes and move on from there, making larger code inclusions, etc. :)

So for "CPL" it's like a rules engine in the background and squid only pushes the user account and connection info?


Cheers,
Franco

[allexBR]

Hi guys,

I would like to know if anyone managed to solve the following problem...

In squid.conf, the ACL remote blacklists are evaluated before the "Auth plugins" include, which has the custom whitelists:

https://github.com/opnsense/plugins/issues/1111

Thanks!