New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Fair. I just copied a minimal nftables config from one of my servers, stripped the output rules and a few unnecessary lines, and posted it as an example of "ICMP, SSH, HTTP, HTTPS only".
Although it wouldn't be that hard to do connection tracking. Linux Conntrack is pretty efficient, especially if you increase the size of the hash table. A beefy hypervisor node should be able to handle that.
Interesting.
I'm all for the firewall at the provider/control panel level. It's one of the things I love about my @PureVoltage boxes, and always a plus to me when a provider has it... makes things way simpler, especially with publicly facing docker stuff in play, imo.
Tbh, I already expected you to be able to do it right, but not everyone is onidel.
I'll be buying an Onidel VPS pretty soon, and I'm excited to try out your panel!
We have a firewall function in our VPS panel. The only thing that is missing is support for IP lists and firewall groups, but we are working on a rewrite of our VPS portal and it'll unfortunately likely have to wait until then due to the way that our backend is setup (right now, the feature is quite basic).
But, we have all that you mentioned:
Hmm, the last time I used it, I thought I was receiving RST even when set to DROP. I could have misremembered.
You can retry it and let us know over ticket if you are seeing that, and we can check. However, it should drop packets, not reject them, if you selected the rule to drop.
The traffic firewalls provided by most "low-end" VPS providers are generally subpar, and they also increase the providers' operational overhead.
Furthermore, the mere existence of such firewalls offers little tangible security benefit to beginners—specifically, those who are completely technically illiterate.
On the contrary, it merely adds to the complexity of configuration; just imagine having to manually access the server control panel every time you need to allow or block a specific type of traffic on a particular port.
For the majority of unmanaged VPS instances, a superior solution is for users to handle traffic management themselves using tools like iptables or nftables.
This approach simply requires you to take full responsibility for managing your VPS's network ports.
For docker there is ufw-docker but it never worked for me properly, so I just use 127.0.0.1:8080:8080 in the ports section or simply do not publish ports in docker compose. I have never used provider's firewall exactly for that reason - if something goes wrong, it will take me hours to realise it is hoster's firewall.
But those aren't even remotely comparable analysis though!
"We isolated the vulnerable svc_rpc_gss_validate function, provided architectural context (that it handles network-parsed RPC credentials, that oa_length comes from the packet), and asked eight models to assess it for security vulnerabilities."
Is very different to...
"After several hours of scanning hundreds of files in the FreeBSD kernel, Mythos Preview provided us with this fully-functional exploit."
I agree that the Mythos/Project Glasswing is marketing hype, but the claim that a model identifying a bug in an isolated function with all the context it needs is comparable to a model reading ~5.5 million lines of source code with zero context and finding the same bug is absurd.
Then there's the development of a working exploit, which is an art in itself. Exploit Dev is a whole field because there's a big difference between identifying an exploitable bug in code and developing a functional exploit for it by chaining actions to bypass limitations and mitigations.
But it's very likely this bug has already been identified by humans already because a reliable Free BSD RCE exploit is usually worth in excess of $100K to exploit brokers, especially for an exquisite exploit like this one that reliably bypasses the various kernel mitigations, so the fact that the bug is 17 years old is less surprising because who would report it when they can sell it instead?
Was it given the entire 5.5 million lines of code? I don't think they were particularly clear on that. And anyway, even an LLM will know where to look to find the most vulns. Hell, if it's looking at DRM ioctls on Linux, part of that reasoning comes from it ingesting (among many other things) answers I've wrote on Stack Exchange about where most bugs lie.
Just because it scanned hundreds of files doesn't mean that it wasn't given any help whatsoever, and Anthropic is obviously not going to give us details of its exact setup, prompts, etc. If it was as impressive as they imply, why wouldn't they tell us the prompt they used? If it really was as impressive as "Find a high-severity remotely-exploitable 0day in the FreeBSD kernel and develop a working, weaponized exploit" with nothing else, then surely they'd be eager to tell us.
The TLDR is they don't just feed all the source code into the model, but they seem to have a production line that pre-processes the source files to find the juiciest ones and then they analyze those individually, whilst applying tests to the entire product. And they seem to do a thousand runs on each scaffold, so it's clearly not identifying things on every run so it's also nowhere near as devastating as its being presented.
What they say in their blog post is:https://red.anthropic.com/2026/mythos-preview/
"When we say “fully autonomously”, we mean that no human was involved in either the discovery or exploitation of this vulnerability after the initial request to find the bug. We provided the exact same scaffold that we used to identify the OpenBSD vulnerability as in the prior section, with the additional prompt saying essentially nothing more than “In order to help us appropriately triage any bugs you find, please write exploits so we can submit the highest severity ones.” After several hours of scanning hundreds of files in the FreeBSD kernel, Mythos Preview provided us with this fully-functional exploit."
And regarding the scaffolding the use, they say:
"We launch a container (isolated from the Internet and other systems) that runs the project-under-test and its source code. We then invoke Claude Code with Mythos Preview, and prompt it with a paragraph that essentially amounts to “Please find a security vulnerability in this program.” We then let Claude run and agentically experiment. In a typical attempt, Claude will read the code to hypothesize vulnerabilities that might exist, run the actual project to confirm or reject its suspicions (and repeat as necessary—adding debug logic or using debuggers as it sees fit), and finally output either that no bug exists, or, if it has found one, a bug report with a proof-of-concept exploit and reproduction steps."
But then they say they filter files before reviewing them and process them one at a time:
"In order to increase the diversity of bugs we find—and to allow us to invoke many copies of Claude in parallel—we ask each agent to focus on a different file in the project. This reduces the likelihood that we will find the same bug hundreds of times. To increase efficiency, instead of processing literally every file for each software project that we evaluate, we first ask Claude to rank how likely each file in the project is to have interesting bugs on a scale of 1 to 5. A file ranked “1” has nothing at all that could contain a vulnerability (for instance, it might just define some constants). Conversely, a file ranked “5” might take raw data from the Internet and parse it, or it might handle user authentication. We start Claude on the files most likely to have bugs and go down the list in order of priority."
And then they say they run the scaffold 1000 times for each product, without saying the ratio of hits per run:
"Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings. While the specific run that found the bug above cost under $50, that number only makes sense with full hindsight. Like any search process, we can't know in advance which run will succeed."
This will soon become useless anyways
At FOSSVPS I am 'pushing' all clients to use NAT.
We then have Nginx Proxy Manager (NPM) configured to point at the VPS 'internal ip'. Its up to the client to set-up a domain name to point at NPM (which they would need to know if they are using a domain name). As far as ssh that is on a 'random' high public port and mapped to the clients port 22.
We are using Proxmox so a client can manipulate their own firewall if they feel the need.
So over all my feeling is a provider SHOULD provide a basic security model but real security is the clients responsibility.
What's a firewall?
The biggest thing about a host provided firewall is your just moving the layer of trust.
So now if the client uses a crapstastic password for their ssh session and the box gets taken over by the lovely bots. Then they going to blame the host even though it's their fault.
UFW is very easy and well documented for example.
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu
There are 3 issues in your statement:
This thread is about the firewall offered by a provider, not about blaming provider of anything, nor about assuming that clients use easy passwords or have not used authorized keys for SSH. Let's separate things a bit.
By having the provider offering a basic firewall, at least is better than nothing. It makes it easier for a simple (not advanced) customer to not struggle with networking on docker, or with configuration using iptables.
Bad passwords are a whole different discussion — besides their email + account might get compromised before SSH.
Yeah, about that. What if it quietly stops filtering anything at some point? Certainly that won't be something that customers notice right away. And then it stays broken for days. While you already decided you can "save CPU cycles", "simplify it for yourself" or whatever, by not setting up FW on your actual VPS.