All practical general use firewalls are porous now for inbound traffic

There once was a time when you could more or less keep people from making holes in your firewall for inbound traffic, so you could be relatively confident that your systems were only being talked to through your designed access points and methods (and as a corollary you could log access and enforce things like MFA policies). Those days are over now, and probably have been for some time. If your firewall allows outbound traffic, as it must in order to be generally useful to people inside your network, people can easily set up things that bypass it. To stop this you'd need an extremely restrictive firewall or to simply not allow people to run programs on your inside machines.

The obvious source of inbound firewall bypasses are people who run things like user space Tailscale daemons or even tailcat on your machines. There are other mesh networking systems besides Tailscale, and I'm sure some of them have user space versions for ad-hoc usage; Tailscale is simply the most obvious and probably the easiest to find (both in terms of your people finding it in order to set up some sort of remote access thing for their own use and in terms of you finding it on your network). This can create a relatively broad inbound access through your firewall, including allowing people to use SSH in a way that bypasses your regular SSH setup and its settings (and its logging).

(At the same time, SSH connection sharing has always meant that you didn't necessarily separately authenticate and log 100% of SSH logins and SSH command executions.)

Another version of this is Cloudflare's "Tunnel" stuff, which allows people to expose things that exist inside your network to the outside world (ideally these are their own things, rather than your internal services). A third version is that there are an assortment of programs that will connect to various modern chat systems (Discord, Slack, etc), or old fashioned ones like IRC, and accept commands and requests from appropriate channels on them. What commands they accept and how secure this is depends on what people set up in these programs.

(In developer circles, "SlackOps" is definitely a thing, with developers wiring up automation to trigger various activities inside their network (ie, your network) that they find convenient and useful.)

The latest development in this is people running 'LLM agents' on your servers, either directly or through IDEs like Visual Code. These agents (and Visual Code itself) are typically run as backends to something running on the person's local machine, started and controlled through your regularly authenticated SSH connections, but once started they often have wide-ranging powers to run things on your machines as that person and may be relatively widely exposed to potential "commands" from things that people, say, simply look at. This can also be combined with any of the things above, of course; people may be running tunnels of various sorts to enable their local agents to have convenient access to their stuff on your machines.

It's important for system administrators and security people to understand that people aren't doing this because they maliciously want to bypass your firewalls. Instead, they're taking the easiest path to get their work done and in the process they're showing you their 'desire paths'. You're unlikely to change much of their behavior by either yelling at them or trying to put fences in the way, to the extent that this is even possible.

(You can block some simple and obvious stuff in firewalls, but this only pushes people toward less obvious and visible workarounds.)

PS: This doesn't necessarily mean that you should simply accept this and do nothing at all, but that's another discussion.

PPS: Firewall protections on inbound traffic still have an important purpose, even though they're porous; they work to avoid accidents, so that anything exposed to the world has been exposed intentionally by someone (even if that someone isn't the sysadmins and the security team).