gowenfawr

Hey @Paulster2 - @Tom noted here that he didn't realize tire issues were off topic. But the "What types of questions should I avoid asking?" in the help center doesn't mention tire issues or reference the relevant meta post. Perhaps the help article should be updated with this specific guidance?

Philip Pullman's His Dark Materials? Or is that too dense for an 8-year-old?

And apparently the answer to this question is U+2019, RIGHT SINGLE QUOTATION MARK.

@MechMK1 tried to address your comment in the answer... does that help?

@Jenayah anyhoo thanks for cluing me in on the context for the first comment on that answer. Removed my quibble and marked your comment as no longer needed.

@Jenayah I would guess OP went with <code> because he had three short lines, and in regular quotes that turns into either a run-on blob or lots of extra white space between lines. <code> allows you to have string<newline>string<newline> and just get one line after the other.

@Jenayah they look very much like what I'd expect from a D&D style manual, I would not be surprised to find that those numbers originally come from the B5 Roleplaying Game and Fact Book.

@Jenayah also not trying to start an edit war; the paucity of quote capabilities on SE make for a lot of sad compromises.

@Jenayah some people do prefer <code> formatting for things that come out of manuals and RFCs, because of likeness with the source material.

Likewise, for desktop hardening, auto-upate and limiting services is pretty much all I do or see, because when you want to go deeper than that you start impacting the user. Most of the insecurities I've seen in Linux deployments boiled down to accommodations made for the user :)

The first question is kind of hard to answer. I used to do hard core hardening with LIDS (a mandatory ACL and kernel hardening system). As things like SELinux and AppArmor got more common, that sort of hand-hardening went away. Nowadays hardening is 1. auto-update, 2. 2FA, and 3. limit services. Paranoid is setting up FIM to alert you when everything else has failed.

I'm afraid I haven't been on the buying end - more the trying-to-sneak-past end (I'm currently in a Red Team role).

Incidentally, there's a shift away from signature-based anti-virus towards "endpoint protection" like Crowdstrike, Carbon Black, Ensilo etc. which focus more on what code /does/ than what it looks like. It's early, but I'm seeing more willingness to extend those out to Linux because they're perceived to have value that signature-based AV doesn't.

Not a significant threat on Linux, and not very likely to be caught by AV (arguably, fileless malware exists primarily to evade AV).

Residing on a filesystem only poses risk of execution if clients capable of executing it have access to that filesystem :)

(Possibly, the exception being, blocking CIFS to avoid malware that can spread that way -and, again, that only applies if the infected host can execute the malware, enabling it to try and pivot via CIFS, and Linux doesn't do that.)

No - while network segmentation is a good thing, it's generally required to limit active attackers, rather than malware.

And, taking this back to PCI, they absolutely recognize that, with their language of "systems commonly affected by malicious software".

Correct, it's not poisonous, it's not going to infect anything just by being there. It needs to either get copied to a vulnerable system, or to execute on a vulnerable system. Linux doesn't execute almost all viruses, so we're reduced to looking at the copy problem, and that's where the question of "Is it worth it to run it?" comes in.

A file server, which stores files that are access by Windows users (via CIFS or NFS) should also be running AV to screen all those files, for the same reasons.

The same is true for Browser exploits... evildoers will weaponize for Chrome on Windows, not for Linux.

ah - PDF, "the device in question" - you bring up another good point. The other side of the coin is that almost all malware is written for Windows. If there's a PDF exploit, and you open it on Windows, boom. If you open it on Linux, it does nothing. (Which is why, in the beginning, the criteria for caring was "how much does this machine share files with actual Windows systems?")

If you mean when I say "the efficacy is normal" - the generally accepted number is that AV catches about 30% of the malware out there. Some are better than others; interestingly, Windows Defender is one of the more effective ones out there right now.

I assume there are a massive number of threats on my network. I also know, from experience, that AV will not help me with the majority of them. (One of my hats is Red Teaming, so AV evasion is one of the things I worry about to get my job done - but it's not a big worry).

@Motivated but that's not an antivirus argument, that's a pivot argument, so AV won't help you much there. Otherwise you need to put AV on your printers, network switches, mainframes, ...

@Motivated you need to look at each situation and determine the threat level. A software engineer's desktop, for example, may have very little intersection with Windows users or files. On the other hand, I'm sure some organizations are using Linux desktops as web clients for e.g. salespeople who interact with many other Windows users daily. The former might not need AV (and might not want it because CPU cycles are precious to the build cycle), the latter might need it - and the way PCI works, you document your case and present it to your auditor, and see if you can convince him.

@Motivated the point was that unless a Linux server is actually serving files to Windows systems (via CIFS, for example), there's no driver to scan files on that system for Windows viruses. You can't take the threat profile for one type of server (mail servers handling mail for Windows clients) and blindly apply it to servers that may have nothing at all to do with Windows clients.

It accurately describes my company and several others I know to be PCI compliant. In particular, our auditor tried to push the AV-on-Linux issue last year, and cited some web site about the number of viruses detected by different software where the Linux AV packages were pretty high on the list. I pointed out that was because mail gateway AV and file server AV have high detections but that it meant nothing about Linux systems not being used as servers for Windows files, and in the end he accepted our interpretation.

@Joshua #3 may or may not be a really bad idea, but there are a surfeit of vendors (Websense, Netskope, ...) who happily provide it to enterprises who happily use it. A good list of problems is here... but don't expect your boss to change his mind based on it.

And if that conversation gets carried forward, all the traffic is encrypted, and completely useless to the attacker.

And only if both legitimate server and customer share that secret, can the conversation move forward

But only the legitimate server can decrypt that secret

That's correct

which part of it do you want to expand upon?

ok

If it's your certificate, then they'll fail to verify it and stop before sending the secret.

If it's the company certificate, you can't then decrypt that secret, which is required to move forward.

and encrypt the secret with it

The certificate isn't just a pretty bow sitting on top of the handshake. It's an integral part of the handshake, designed to guarantee that they're talking to someone that has the private key that corresponds to the public key that somebody important (the CA) signed for them to verify.

If you use the valid real company certificate, they will verify it, accept it, and encrypt a secret with it. They then send you the secret. That secret is the key that the two of you will use to encrypt and decrypt all future traffic. But if you sent them the valid company certificate, you can't decrypt that packet and retrieve the secret key. Since the very next packet requires you to have that secret key, the handshake will fall apart and terminate.

If you use your own certificate (public key), they will notice that it's not a valid certificate for the domain they think they're going to, and they'll refuse to continue.

You need a certificate to set up SSL.

But you can't.

But who are they actually talking to in your scenario? You, the attacker?

(if the real server is still the endpoint, then they're simply snooping on encrypted traffic, where the whole point of snooping is to make it unusable to someone who's snooping on it.