Hey folks, very much not a security expert but how does one decide on requiring AntiVirus on virtual servers? We are a payroll company that will accept files from trusted partners and are currently running on Windows but are about to shift/upgrade (however you like to think ) to Linux. I’m not totally sure of the previous reasoning about installing AV’s on all the instances other than thinking it’s a de facto Windows thought. Reasons I’m leaning towards saying no are:
• We don’t run anything on the machine that isn’t ours or from untrusted sources
• We are accepting text files (xml) files only
• We will be using aws linux provided ami’s and despite malware existing I don’t see us being susceptible
• Our current AV provider causes high CPU usage and can trigger alarms which means verifying false positive alarm
• I feel more secure with Live Patching
• SEL but I’m again no expert in this configuration Things that would make me say yes are simply Security Certificate standards like SOC, SOC2, etc.
Are there other important factors I’m not considering
Could you consider a file transfer process that includes scans on third-party provided content, rather than an always on server-wide thing that would use up CPU and disk i/o?
It’s best to scan and validate the input assuming everything else is locked down
Yeah that is definitely a consideration and the more I think on how we can do it, I like it regardless of the effort/complexity. I needed somewhere to talk and not have bias Thanks peeps.
check if your AV is checking the XML files as well upon upload. it may be a safeguard and in your implementation under linux you will have to think more about defusing some xml functionalities which tend to be used in malicious manner. So (depending on your implementation) migration to defusedxml (python based library) or alternative is worth considering.
I’m curious about this too … I’m being told for HiTrust that we must have AV on servers, but these requirements are really aimed at physical infra or people’s “workstations”. Putting mcafee on a t3.nano instance hosting a backend web app seems like a recipe for disaster
The S3 bucket where Twilio host their JS SDK had pubic write access for five years
me: I can’t believe they made such a BAD and OBVIOUS mistake
also me: (nervously checking all of my bucket permissions)
heh, just implemented some checks for it in OPA
At current gig we have an s3 bucket module with sane defaults out of the box, not open to the world. Obvs can still force it though so an OPA policy denies it
Looks like this one was a mistake when trying to make the bucket public read, which is a totally valid use case, but they added write too
Yup, easily done
Great office hours btw :–1:
The scammers have raised $20,000 — and rising — in less than an hour.
what waf is everyone using? kubernetes friendly ones would be nice
I don’t get your point with k8s, they should not be linked
We use Cloudflare btw
Is Kubernetes the right layer for a WAF? Wouldn’t it be nicer to push it out to the edge? E.g. cloudflare
we have one currently deployed as a sidecar to the ingress controller
WAF and rate limiting, CIDR blocks, etc, should not be in you application stack, but as much possible before
yeah that is a valid point. Have you guys investigated AWS WAF?
Ya one thing is if the objective is just to block certain kinds of low volume attacks, but to block any kind of DoS attack, in cluster WAF is too late
@btai few metrics, rules are not flexible, no default ruleset, AWS WAF is really expensive and not really handful
true, i guess the focus was on things like sqli, suspicious activities, etc.
more expensive than cloudflare?
DOS = layer 4, WAF = layer 7
We have not only because haven’t liked using the ALB ingress controller since it deploys an ALB for each ingress. Also waf only works with ALB and not NLB
@btai can’t tell you, I never compared the bills
but if you’re richie rich, Akamai for DOS protection and WAF
do u know the pricing model for cloudflare? we’re paying a ton for sigsci (not my decision) and they charge per request
and since it sits behind our ELB in the ingress controller we get charged for ELB healthchecks and other constantly running requests (for example push notifications)
it depends your company size
and your needs
i dont see anything about charging per request
don’t know for WAF
@Issif does cloudflare charge for bandwidth ?
doesn’t specify that they do in the pricing plan but some companies leave things like that off sometimes
I can ask tomorrow, 1am in France right now
@btai bandwidth is free with Cloudflare
that’s the insane thing.
thanks @Issif and erik!
are you using cloudflare as well erik?
prob gonna check out both fastly and cloudflare
Love using their edge workers too
Fastly TBH is a little bit cooler since it’s built on varnish under the hood. But with the advent of workers, a lot of what I would have wanted from Fastly is moot.
will check out both. if there’s not much of a feature or cost advantage between the two, theres def an advantage of sweetops user adoption (goes to cloudflare currently)
Fastly does charge for transfers, so that’s one reason they can be come more expensive quickly.
The CloudFlare free tier service offers unlimited bandwith while other CDNs charge starting at about $.10/gb. CloudFlare does not have bandwidth limits. As long as the domains being added comply
must be running all of cloudflare on on spot ocean
@Issif i mentioned to Erik already that because of the nature of our business (saas), our clients wont be ok with us introducing a 3rd party that can terminate tls (cloudflare) so I’m investigating AWS WAF (which all our clients approve before signing) and they now have managed rulesets u can purchase from reputable security companies and also AWS managed rulesets. Still much more expensive than cloudflare though (priced per million requests)
It makes sense
SigSci + using the CDN as the first WAF…ends up being a great combo
@btai i didn’t have a great experience with the WAFv1 Managed rulesets a 1.5 years ago. Let me know if current Managed rulesets look good to you on the AWS WAF. My biggest issue with the Managed rulesets a while ago was that if something got blocked, there was no way to figure out why it was blocked by the Managed rules, since the rules were a complete blackbox.