Barracuda VPN on Linux permanently and silently changes resolv.conf

I routinely make /etc/resolv.conf immutable to avoid anything touching it (not VPNs, just systemd and every other random bit of software).

  # chattr +i /etc/resolv.conf
  # lsattr /etc/resolv.conf 
  ----i---------e------- /etc/resolv.conf

You'd probably want to first check that /etc/resolv.conf is a real file, first. SystemD has a nasty habit of replacing it with a symlink. That prevents "chattr" trick from working.

1. it is systemd-resolved, not "SystemD"

2. it is not a nasty habit, but a configuration. If you do not want it, you can configure systemd-resolved not to do this.

3. it is for a very good reasons, and there were written pages and pages about the issues, what those are; so when you understand why, you won't reconfigure (2) anyway.

~~Keep in mind that making a file immutable doesn't prevent it from being unlinked. That can be removed and modified all the same~~

If this is a real concern, I'd be more mindful of what's being given privilege. It's atypical to chase - going as far to remove bad actors

edit: Wrote this while still half asleep, tested - wrong lol. Keeping to prevent more folly

Something with privilege could usually just remove the immutable flag and then go on and do whatever dumb stuff it wants to do... But they usually don't.

My corporate macbook was at its most stable when I had set /etc/hosts immutable and the corporate chef got stuck and nobody yelled at me. Of course, a couple months later I did a mac os update and some corporate spyware interfered with the gpu driver... would have been updated if chef had run in the past three weeks. Whoops.

Bloody good idea.

While it would be prudent to have the uninstaller clean up, this is a losing battle. It's basically become normalized that any package can and will overwrite resolv.conf at any time without necessarily clean up afterwards. It's seen as ephemeral.

I find it kind of baffling that as an IT contractor you've managed to go months without changing it since (:

Someone else mentioned making it immutable, which is not a bad idea if only editing it manually is what you want.

Next step if you still want it dynamic would making it owned by the designated user of the process making the changes you actually want (e.g. NetworkManager/systemd-networkd/netctl/whathaveyou).

Ha :-)

Well, I run Tor on my system, and all traffic goes through that; all other outbound traffic is blocked. Tor provide DNS, so all I ever do with resolv.conf is point it at localhost and that's it.

chattr +i /etc/resolv.conf not working?

it could be just a case of incompetence.

seems to me like you still have open ticket with them and some email exchange, so its not like they have sent a hitman to silence you...

I opened the ticket, received a request for the product serial number - which I did not have, being only an end user - and after that, never heard from them again.

I have replied to their auto-emails, and to the chap who asked for the serial number. Nothing ever came back.

The ticket is a red herring, I would say.

I may be wrong, but given the need for the serial number, Barracuda have chosen block all but paying customers, regardless of the issue. This type of behaviour I think is common in larger companies.

What it means for end users like you or me is the need to be warned by others about issues in the product.

As an aside, I think I recall security issues in their products - ah, mmm, searching finds a ten year old article, which speaks of long-lasting intentional SSH backdoors in multiple Barracuda products.

https://krebsonsecurity.com/2013/01/backdoors-found-in-barra...

Still, that was ten years ago - but OTOH, we have this astounding resolv.conf behaviour today.

So what? This is pretty common behavior for corporate VPN clients. When you VPN in, how else are you going to resolve internal DNS?

It's not that the change is or is not necessary; it's that it is silent and permanent.

We must also note that change interfered with the existing system configuration, by rendering one of the existing DNS servers unusable.

And I've just noticed the formatting for the resolv.conf file is buggered, and it's too late to edit =-)

nameserver [German company DNS IP #1]

nameserver [German company DNS IP #2]

nameserver 127.0.0.1 nameserver

::1

search [an IP name from German company]

Are you certain that those changes were not made manually when initial setup needed some tweaks to get working, perhaps?

Yes. It's my laptop; no one else touched it.

What’s stopping you changing it back?

That I did not know it had happened, as it was a silent change (and indeed, a change which survived uninstallation of the VPN).

So in the end, when I stumbled across it, I did change it back - but I had a malformed DNS config for the months before, by chance, finding the change.

That I could change it back isn't much use when I had no idea the change had occurred.

With VPNs implementing split-horizon / internal DNS, all of them will change the resolver config. There's no way around it really without more hacky solutions. It definitely should revert the config on each disconnect, so maybe it's just a bug.

There are pretty defined ways how to handle this, just communicate with NetworkManager, set up the DNS info on your link and it will do the right thing (any desktop machine from the last 10 years, which is going to have user-managed VPN is going to run NetworkManager); modifying resolv.conf is the hacky way.

Yes - this articulates my expectation of a VPN client.

DNS should be modified when and only when it is running.

That is not the case here.

>That I did not know it had happened, as it was a silent change

So no HIDS like Samhain or OSSEC in place?

I'm not that strong a user, I'm afraid.

Just an ordinary person, living in fear of VPN clients :-)

No problem try to make resolv.conf immutable with:

chattr +i /etc/resolv.conf

Not even root can then change it without removing the attribute (-i)

However HIDS are really nice to detect stuff like that...and they are not that complicated (OSSEC or samhain)

I'd actually not heard of HIDS before, so now I'm aware of them, I can look into them when there's a good moment to Google a bit. All part of that learning curve :-)