this is not something I would expect from the support staff of a well know Linux VPS service:
username Linux Expert commented 15 hours ago
Hello,
Thanks for getting back to us and providing those logs. I actually think we may be unable to open .tar files that have been sent over as attachments.
the support desk inteface would not accept any archive format as an attachment, so a link was provided. The archive format was .tar.xz due to the uncompressed size.
I really dont know what else to say, except that I had to say something, somewhere …
If they have a company policy about potentially executable attachments not being allowed to be opened (and thus executed), there’s very little that support rep can do. I don’t know whether or not this is the case, but you may want to cut that rep some slack here. At least they told you the real problem (plenty of stories around telling otherwise!). You may want to exchange these logs via a sharing service, like Dropbox or even Google Drive.
Under what conditions does a Linux VPS company not allow its support staff to open any.tar format archive when investigating log files from a known Linux installation?
Because they don’t know that it’s actually log files inside until they open/unpack them?
Do you also open random attachments to emails you can’t be sure of the content just because some random guy on the internet tells you it’s just a text file? I hope you do because… y’know, I wouldn’t know what else to say.
Might not only be a “do not open any attachments” policy.
Sometimes the internal security only allows basic tools to be installed, like windows default unzip, no 7zip or other “advanced” tools that could deal with .tar, .gz or .xz.
This reads like he did not even try or does not know if he would be allowed to, so better not do anything.
Or it might be a missing competency on the other end.
I once had to send a log file to one of our well trained - OSCP certificate owning - security guy, answer was short “could not open file extension” … I had sent a “logs_from_whatever” file, instead of “logs_from_whatever.txt”
They could at least verify that the person is who he claims to be: A customer with a certain ownership, trustworthy to the point of “we know who he is”, as most require to enter to some extent validated personal data for registration.
My recommendation @paulwratt, ask them for how they would like you do exchange those logs, or simply add them below the mail inline.
And what do they get from that? Just because they know who you are doesn’t mean they know you can be trusted. Company policies are there for a reason and usually that reason is because shit happened in the past.
Maybe some people should start realising that not every company is out to get you, they just need to protect their assets too.
True, they only get information that you are who you claim to be, can put your location in a risk group and decide based on this. Can understand why nothing like this happens, and the default of “do not open any attachments” is used as it is most of the time more reasonable.
Is blocked in some companies that want to protect their IP,as people might “leak” data through it.
I don’t share this threat model, but can see why some do have the policy of only accepting eg. mircosoft secure share or other tools that have built in virus scanning (well knowing that mail servers having the same capabilities, but the sales person of M$ made this solution sound so much better).
Cool. Except that costs money (not to mention you need a privacy policy for that to even build and/or get a risk score from a third party), and not accepting attachments is free.
Re: attachments in email … it’s possible that from their own perspective they’re not interacting with you via email, at all,
Often times when dealing with customers, there’s a ticket somewhere and email is just an API to a ticketing system the reps interact with using a web app.
This happens to increase security, but is done primarily to allow reps to be interchangeable and pick up each others open tickets/cases.
How ticketing system parses email and what it supports, and how whatever frontend sandboxes the contents of what you’re sending tends to be pretty arbitrary.
I don’t work in tech, but our email system at work will automatically remove all archive and executable files. We also used to have a 10 MB file size limit in place on all emails as well. The former was strictly security related, the latter security and to not fill up the email server.
We have a size limit becuase people Will use the email server as a drop box, even if the have access to personal shares, and group shares…
I don’t know if the server dedupes, but sure hope it does…
My SO works in finance - and works on a team that interacts with many other teams in other companies via email. As there’s money involved, she’s required to have backing for her decision to e.g. transfer money around, in some cases for many years into the past. I don’t know what’s considered state-of-the-art opensource or corporate email solution these days, but as of last year everyone on her team was on their internal wall of shame because they used to fill about 20GB worth of email per month and their admins didn’t really know what to do with exchange in that situation.
They’d still needed to coordinate “archiving their inboxes” - which sounds very last century TBH.
IMHO, any modern email solution should treat email as a simple database and store things like email bodies and attachments in some “scale-out” friendly manner.
I’ve personally written a trivial SMTP mailbox server in Go at one point with the idea of extracting attachments and storing them in git. … It shouldn’t be “that hard” to upload messages into some kind of simple object store instead, maybe ipfs, maybe something smarter. Writing this kind of “don’t care about email size or inbox size” email server should be real easy these days.
If trying to open a tar file directly from the email it will not work. However you need to save the file to disk and if you have a tar reading program on your system it will open.
In the enterprise, yeah. Nothing wrong with that. VMs are a thing as well as verticals/dev boxes in “ze clowd”.
Also WSL/WSL 2. VS Code and Vim are cross platform. 7zip can extract tar.
Why didn’t you follow the instructions the support person gave?
Your conclusion seems a bit silly, though. Just because they won’t open your attachment doesn’t mean they’re using Windows. Malware exists on Linux. It’s pretty easy, depending on the DE and OS.
It’s standard practice for the first level support to not really know jack shit and just do as they’re told. And at these companies, they are trained to not just open things willy-nilly that they don’t understand because that’s how you get malware.
There is no need to get butt hurt over support just doing their job and being cautious. All one has to do is calmly follow their instructions and everything should turn out fine.
I haven’t read every post in the thread, nor shall I, however, I can say that simply reaching out to what formats for them are acceptable will usually suffice.
) of the Level1Techs forum.