[jabroni_salad]

coming from the IT Operations side of things, most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall much less any kind of OS-level control scheme like selinux or applocker.

Watching a 15 minute selinux tutorial video will give you a moat ahead of 90% of the community but it won't matter because management kind of agrees that anything that slows you down has to go, and security policy is ultimately just a type of insurance rather than a revenue generating activity. Disabling selinux reduces cost today so we might as well go for it.

I do think it is worth having on any public webserver since it's only a matter of time before your app gets popped and you want that sucker in jail, but I gave up on internal servers a long time ago.

[xorcist]

As an ops person, is it not your profession to make applications work in the real world with firewalls, load balancing, certificates, and mandatory access control? I have never worked somewhere where that wasn't part of the sysadmin/ops/SRE/devops role. Where devs do it, it's only because you're small enough to lack the specialists.

[Conan_Kudo]

Yeah, when I was an infrastructure engineer, this was definitely part of the work I was expected to do, though eventually I turned it into educating and supporting developers in understanding security technologies and leveraging them for their application development. But that's just because I wanted to do it that way.

[kjs3]

most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall

What sort of disaster area do you work in where it's the developers job to tell security ops how firewalls work?

[StressedDev]

Typically, developers have to tell the operations/sys admin/devops people a lot of things to get their application running in test/pre-production and production. Here are some examples:

- Network ports the service listens on - What security permissions does the application need - What commands have to be run so the application starts - What platform does the service use? Java, Node, C#, C/C++, Go, something else? - What GIT repository or repositories contains the service's code? - How does the build work? - What needs to deployed to the machine? - Any configuration changes the application needs

There are also a lot of join decisions where the operations engineer and the software engineers have to work together. Here are some examples: - What cloud will the team use? (AWS, Azure, GCE, etc.)? - What cloud technologies will the team use? - What database will the team use? - How will logs and alerts work? - How will the on-call rotation work?

My main point is you cannot just tell an operations person to deploy something and expect good results. They will have a lot of reasonable questions and software engineers should be able to answer them.

[jabroni_salad]

When we onboard, say, M365, they provide a list of 50 or so URLs that we can expect their service to use. Sure we could get the common ones out of the way on our own but 3 months from now someone is going to click a weird button that deeplinks to some oddball one-off domain that they had lying around for some reason. It's nice of microsoft to let us know all the URLs they are associated with in advance.

Is there any reason that you do not know what your application can be expected to connect to? You wrote the thing, right?

I work with a lot of external vendors who offer self-hosted software and a really common refrain is "it must be a network problem" but these guys are universally unable to describe their application's networking requirements.

[DyslexicAtheist]

"tell me what outgoing ports the application needs" is what results in blank stares the most. its embarrassingly basic, but maybe it has something to do with "senior" devs only being on the job for mere 5-8 years. that is the amount of time good cybersec people spend on understanding security after a decade in dev (or in ops).

[rescbr]

Ohh! I’ve been at the other side of this discussion.

It usually goes like:

“What are the outgoing ports?” “1024-65535, I mean, the app is using X language’s standard library to make an HTTPS request.”

“What are the IPs we have to whitelist?” “You can either allow app.example.com or take AWS’s IP range JSON file and allow all of those, we don’t control what IP gets assigned to AWS’s API Gateway service”

Then some cloud provider’s SA/SE gets looped in to say the same stuff to the security team.

Some exec then gets escalated and approves this as a risk.

Tale as old as time.

[camgunz]

Yeah, OS firewalls have limited use in the modern app stack. It's not just HTTP(S), you've got cache and database in there too. If any ops person asked me this question I'd take it as a bad sign. Like, you're worried about exfil on an application by application basis in your prod deployment, which I assume is all VPC'd and not SSHable? There are better ways to spend your time.