HN Explorer

Barracuda VPN on Linux permanently and silently changes resolv.conf

18 points by Max-Ganz-II ↗ HN
I work occasionally, as an IT contractor.

I recently completed a contract for a large German company, who will remain nameless. Nice bunch, nothing wrong with them, and I would not want to embarrass them.

Said company provides to its remote staff a VPN, Barracuda VPN, and the VPN is available for Linux, which in my case means a Debian package.

I installed, never needed it, six months later contract complete uninstalled.

A few months after this, I stumbled across the fact that my resolv.conf had been altered, to that given below, and not reverted by uninstallation;

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]

The VPN installer had prepended its DNS to resolve.conf

I may be wrong, but I understand resolv.conf uses servers in the order they are given, and uses only the first three servers.

(The final line, "search", causes any DNS IP name lookup which fails to be retried with the given IP name appended.)

These behaviours occur whether or not the VPN is active, and where resolv.conf was not reverted by uninstallation, continue occurring after the VPN is uninstalled.

I contacted Barracuda about this matter, explaining and questioning what had happened.

The initial reply was prompt, and asked for a serial number.

I replied I had never been given a serial number, just the package, and I had left the company concerned some months before (and of course, had only noticed this problem afterwards, as it is a silent and unexpected change).

There was no reply, but since then, I've received automated emails telling me I have a ticket, and that it is awaiting a serial number (to which I have replied, to no effect or response).

Barracuda have a second email address, for security issues. Email to this address has gone unanswered.

25 comments

[ 4.0 ms ] story [ 63.6 ms ] thread
iExploder
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...

Max-Ganz-II
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.

nixgeek
What’s stopping you changing it back?
Max-Ganz-II
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.

viraptor
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.
vetinari
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.
Max-Ganz-II
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.

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

So no HIDS like Samhain or OSSEC in place?

Max-Ganz-II
I'm not that strong a user, I'm afraid.

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

nix23
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)

Max-Ganz-II
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 :-)
Max-Ganz-II
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]

zaktoo2
Are you certain that those changes were not made manually when initial setup needed some tweaks to get working, perhaps?
Max-Ganz-II
Yes. It's my laptop; no one else touched it.
rwmj
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
nousermane
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.
vetinari
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.

bravetraveler
~~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

toast0
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.

3np
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).

nix23
chattr +i /etc/resolv.conf not working?
Max-Ganz-II
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.

Bluecobra
So what? This is pretty common behavior for corporate VPN clients. When you VPN in, how else are you going to resolve internal DNS?
Max-Ganz-II
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.