Do I really need a firewall for my server?
-
I've been running my server without a firewall for quite some time now, I have a piped instance and snikket running on it. I've been meaning to get UFW on it but I've been too lazy to do so. Is it a necessary thing that I need to have or it's a huge security vulnerability? I can only SSH my server from only my local network and must use a VPN if I wanna SSH in outside so I'd say my server's pretty secure but not the furthest I could take it. Opinions please?
You have a firewall. It’s in your router, and it is what makes it so that you have to VPN into the server. Otherwise the server would be accessible. NAT is, effectively, a firewall.
Should you add another layer, perhaps an IPS or deny-listing? Maybe it’s a good idea.
-
I've been running my server without a firewall for quite some time now, I have a piped instance and snikket running on it. I've been meaning to get UFW on it but I've been too lazy to do so. Is it a necessary thing that I need to have or it's a huge security vulnerability? I can only SSH my server from only my local network and must use a VPN if I wanna SSH in outside so I'd say my server's pretty secure but not the furthest I could take it. Opinions please?
Just make sure you're using public key authentication and you're good
-
You have a firewall. It’s in your router, and it is what makes it so that you have to VPN into the server. Otherwise the server would be accessible. NAT is, effectively, a firewall.
Should you add another layer, perhaps an IPS or deny-listing? Maybe it’s a good idea.
Op means, as they said, a firewall on the server itself.
NAT is, effectively, a firewall.
No it isn't. Stop giving advice on edge security.
-
Op means, as they said, a firewall on the server itself.
NAT is, effectively, a firewall.
No it isn't. Stop giving advice on edge security.
Are you saying that NAT isn’t effectively a firewall or that a NAT firewall isn’t effectively a firewall?
-
Op means, as they said, a firewall on the server itself.
NAT is, effectively, a firewall.
No it isn't. Stop giving advice on edge security.
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall. Now, a pure router in the sense of simply offering a gateway to another subnet doesn't do much, but the typical home router as most people think of it is creating a snat for multiple devices to reach out to the internet and without port forwarding effectively blocks off traffic from the outside in.
-
One thing that hasn't been said in this thread is the following:
Do you trust your router? Do you have an isp that can probe your router remotely and access it? In those cases, you absolutely need a firewallAbsolutely. Even if your ISP is firewalling, never trust they will maintain it, and some of these cheapshit routers they use are awful. Use your own router and put it on the ISP routers DMZ.
-
Are you saying that NAT isn’t effectively a firewall or that a NAT firewall isn’t effectively a firewall?
NAT simply maps IPS across subnet boundaries in such a way that upstream routing tables don't need updating.
If you use destination NAT forward rules to facilitate specific destination port access, you are using a firewall.
-
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall. Now, a pure router in the sense of simply offering a gateway to another subnet doesn't do much, but the typical home router as most people think of it is creating a snat for multiple devices to reach out to the internet and without port forwarding effectively blocks off traffic from the outside in.
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall.
That's like saying a router and firewall are the same thing. NAT appears to be a "firewall" because it's usually deployed with one. NAT itself has no filtering functions the way you're describing.
Now, a pure router in the sense of simply offering a gateway to another subnet
A "pure" router, as you put it, understands upstream subnets and routing tables. NAT does not, and is usually overlayed on top of an existing routing function.
You can set up NAT between two subnets as an experiment with no iptables and it will do its job.
-
Sounds like you could use a reverse proxy.
That doesn't count as a firewall though no? I use traefik as my reverse proxy (and like one thing on nginx that also goes through traefik ultimately) but I still put crowdsec on top
-
That doesn't count as a firewall though no? I use traefik as my reverse proxy (and like one thing on nginx that also goes through traefik ultimately) but I still put crowdsec on top
No, but putting a bunch of those services behind a reverse proxy would lower the amount of open ports. It would also have the side effect of making firewall configuration easier, since you don't need rules for all those ports anymore.
-
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall.
That's like saying a router and firewall are the same thing. NAT appears to be a "firewall" because it's usually deployed with one. NAT itself has no filtering functions the way you're describing.
Now, a pure router in the sense of simply offering a gateway to another subnet
A "pure" router, as you put it, understands upstream subnets and routing tables. NAT does not, and is usually overlayed on top of an existing routing function.
You can set up NAT between two subnets as an experiment with no iptables and it will do its job.
NAT in the sense used when people talk about at home is a source nat, or as we like to call it in the office space a hide address, everyone going to the adjacent net appears to be the same source IP and the system maintains a table of connections to correlate return traffic to.
The other direction though, if you where on that upstream net and tried to target traffic towards the SNAT address above the router has no idea where to send it to unless there's a map to designate where incoming connections need to be sent on the other side of the NAT so it ends up being dropped. I suppose in theory it could try and send it to everyone in the local side net, but if you get multiple responses everything is going to get hosed up.
So from the perspective of session state initiation it can act as a firewall since without route maps it only will work from one side.
-
I've been running my server without a firewall for quite some time now, I have a piped instance and snikket running on it. I've been meaning to get UFW on it but I've been too lazy to do so. Is it a necessary thing that I need to have or it's a huge security vulnerability? I can only SSH my server from only my local network and must use a VPN if I wanna SSH in outside so I'd say my server's pretty secure but not the furthest I could take it. Opinions please?
IMHO, security measures are necessary. I have a tendency to go a bit heavy on security because I really hate having to mop up after a breach. So the more layers I have, the better I feel. Most of the breaches I've experienced were not some dude in a smokey, dimly lit room, wearing a hoody, and clacking away at a keyboard, while confidently announcing 'I'm In!' or 'Enhance!'. Most are bots by the thousands. The bots are pretty sophisticated now days. They can scan vulnerabilities, attack surfaces, et al. They have an affinity for xmrig too, tho those are easy to spot when your server pegs all resources.
So, for the couple days investment of implementing a good, layered security defense, and then the time it takes to monitor such defenses, is worth it to me, and lets me sleep better. To each their own. Not only are breaches a pain in the ass, they have serious ramifications and can have legal consequences such as in a case where your server became a hapless zombie and was orchestrated to attack other servers. So, even on the selfhosted side of things, security measures are required, I would think.
It takes about 5 minutes to set up UFW which would be the absolute minimum, I would think.
-
No, but putting a bunch of those services behind a reverse proxy would lower the amount of open ports. It would also have the side effect of making firewall configuration easier, since you don't need rules for all those ports anymore.
True, I love not having to open ports anymore, game changing.
-
Are you saying that NAT isn’t effectively a firewall or that a NAT firewall isn’t effectively a firewall?
What sort of isp supplied residential equipment doesn’t block inbound connections? Pedantically, you’re correct.
-
Possibly it's about personality types. I was only going on my own experience. Of always being told by a chorus of experts "Oh no you don't want to do that!" and ending up being terrified to touch anything. When I now know that I usually had nothing to be afraid of, because dangerous things tend to be locked down by design, exactly as they should be.
Until they arent.
They are experts because they knew what clicking the wrong button might do.
E.g.: Database admins using the wrong script with a miscconfigured argument or a backup admin responding to a failover, tripple checking every setting to not create a problematic failover and then still clicking the wrong button causing an outage because some random behaviour caused an overload.It happens. And best case you were better (double or tripple) safe than sorry.
-
Op means, as they said, a firewall on the server itself.
NAT is, effectively, a firewall.
No it isn't. Stop giving advice on edge security.
How is NAT not a firewall? Sure theoretically it isn't but I've yet to see a implementation of NAT that doesn't act as a Firewall
-
Assuming it's not a 1-1 NAT it does make for a functional unidirectional firewall.
That's like saying a router and firewall are the same thing. NAT appears to be a "firewall" because it's usually deployed with one. NAT itself has no filtering functions the way you're describing.
Now, a pure router in the sense of simply offering a gateway to another subnet
A "pure" router, as you put it, understands upstream subnets and routing tables. NAT does not, and is usually overlayed on top of an existing routing function.
You can set up NAT between two subnets as an experiment with no iptables and it will do its job.
In practice a stateful NAT is the same as a stateful Firewall. I've never heard of a NAT that isn't a Firewall. A port forward is the same as a Firewall allow rule.
-
I use OpenWRT on my network and each server I have is on its own VLAN. So in my case, my router is the firewall to my servers. But I do have on my todo list to get the local firewalls working as well. As others have said, security is about layers. You want an attacker to have to jump multiple hurdles.
Why did you put each server in its own vlan? You now have a bunch of separate broadcast domains that need a router to move traffic between them. Switching is much faster since it is done in hardware most of the time.
-
How is NAT not a firewall? Sure theoretically it isn't but I've yet to see a implementation of NAT that doesn't act as a Firewall
Because NAT acts as a firewall with a "default deny" policy for incoming packets, but no other rules. You cannot prevent a device on the private subnet side of a NAT from attempting to communicate with an "outside" ip with nat alone, nat doesnt understand the concepts of accept/deny/drop.
All nat does is rewrite address headers.
The machines behind a NAT box are not directly addressable because they have private IP addresses. Machines out on the general Internet cannot send IP packets to them directly. Instead, any packets will be sent to the address of the NAT box, and the NAT box looks at its records to see which outgoing packet an incoming packet is in reply to, to decide which internal address the packet should be forwarded to. If the packet is not in reply to an outgoing packet, there's no matching record, and the NAT box discards the packet.
It's a confused topic because for a lot of people, nat does essentially everything they want. As soon as you get into more complex networking where a routing table needs to be updated, or bidirectional fw rules, it becomes apparent why routing + fw + nat is the most common combo.
-
Why did you put each server in its own vlan? You now have a bunch of separate broadcast domains that need a router to move traffic between them. Switching is much faster since it is done in hardware most of the time.
Mainly for security reasons. Both servers have some limited exposure to the internet. Are you saying doing it that way has performance implications? I haven't noticed any problems its all fast just like before when everything was on the same LAN
