Main firewall / router for public facing subnet
Hi folks, hope everybody is safe and sound. This may be a basic question for most of you, but at any rate, I would rather ask here as I like the way MUUG members approach things. I have a Shaw connection with a few Static IPs. As of now the modem is bridged, and each machine grabs its own IP and goes to town, be it a static for servers or a dynamic for my local network router. On each of these, I set up firewall and whatever else is needed. I have the feeling that's redundant. That, and having a main router in front of them would help me set up things such as QoS and a central firewall. I am used to doing this for simple NAT duties, but this time I would have a router managing public facing IP addresses. Any tips on what should I look for to get started? Thanks! -- Alberto Abrao 204-202-1778 204-558-6886 www.abrao.net
On 2020-03-30 Alberto Abrao wrote:
I have the feeling that's redundant. That, and having a main router in front of them would help me set up things such as QoS and a central firewall.
I am used to doing this for simple NAT duties, but this time I would have a router managing public facing IP addresses.
You can do all this with Linux quite easily. It's a bit to delve into, though, if you want to handle and route multiple IPs, NATing some, etc. The interface, iptables and route stuff will start to get complex. But then you get fun features like qos (tc command), like you said. I'd say find a way to start slow. Like start making your single-connection-point firewall first without putting any boxes behind it. Then move them behind it one by one as you add more setups/features to the firewall. Some will say use OpenBSD for all of this, but I say use Linux. Or, more accurately, use what you know and are good at. It'll be easier to get a grasp of things if you're already partway there. Also, I always recommend "rolling your own" using basic utilities rather than using some pre-made "simple" firewall/router distro. But that's mostly because I like my boxes to serve many duties, not one just for firewall, one just for NAS, etc. Plus, you learn more doing it yourself, and have ultimate flexibility. With a purpose-made distro you'll eventually run into something you want to do that it can't. My 2c. YMMV!
On 2020-03-30 17:04, Trevor Cordes wrote:
On 2020-03-30 Alberto Abrao wrote:
I have the feeling that's redundant. That, and having a main router in front of them would help me set up things such as QoS and a central firewall.
I'd say find a way to start slow. Like start making your single-connection-point firewall first without putting any boxes behind it. Then move them behind it one by one as you add more setups/features to the firewall.
Agreed.
Some will say use OpenBSD for all of this, but I say use Linux. Or, more accurately, use what you know and are good at. It'll be easier to get a grasp of things if you're already partway there.
That's true, assuming you don't think IPTables/NFtables is some Lovecrraftian nightmare that needs to be killed with fire. My personal preference is to use pfSense, as it provides a good balance between a helpful GUI, access to the OS if needed, performance, flexibility, etc. It's not perfect, but it's a good starting point if you have a clue what you want to do. There are quite a lot of pfSense users here, most lurk.
Also, I always recommend "rolling your own" using basic utilities rather than using some pre-made "simple" firewall/router distro. But that's mostly because I like my boxes to serve many duties, not one just for firewall, one just for NAS, etc. Plus, you learn more doing it yourself, and have ultimate flexibility. With a purpose-made distro you'll eventually run into something you want to do that it can't.
While true, security best-practice says to never do more than one thing on your firewall in the first place. There's always an exception to that rule, but not being *able* to install Samba on your firewall might be a good thing... -Adam
Right now I have the servers on their own and my internal network is routed using an OpenBSD box. Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated. I did what you mentioned with a multi-function CentOS machine for the longest time, then when I got multiple static IPs I decided to route my internal network with Debian. After a while, decided to try IPFire/pfSense/OPNsense, but it wasn't long until I got tired of the GUI. So Adam mentioned OpenBSD is the thing if you want security, and I've been looking for ways to get my feet wet on the BSDs besides purpose-built ready-to-go packages such as *sense. And here I am. I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate places reduces the impact if any of them were to be breached. Also, I am kind of OCD with my hardware. It sucked having my wife screaming on one side and family calling on the other because I knocked off the lone box whenever I wanted to dust its fans. At least now I can pick my battles =D Alberto Abrao 204-202-1778 204-558-6886 www.abrao.net On 2020-03-30 5:04 p.m., Trevor Cordes wrote:
You can do all this with Linux quite easily. It's a bit to delve into, though, if you want to handle and route multiple IPs, NATing some, etc. The interface, iptables and route stuff will start to get complex.
But then you get fun features like qos (tc command), like you said.
I'd say find a way to start slow. Like start making your single-connection-point firewall first without putting any boxes behind it. Then move them behind it one by one as you add more setups/features to the firewall.
Some will say use OpenBSD for all of this, but I say use Linux. Or, more accurately, use what you know and are good at. It'll be easier to get a grasp of things if you're already partway there.
Also, I always recommend "rolling your own" using basic utilities rather than using some pre-made "simple" firewall/router distro. But that's mostly because I like my boxes to serve many duties, not one just for firewall, one just for NAS, etc. Plus, you learn more doing it yourself, and have ultimate flexibility. With a purpose-made distro you'll eventually run into something you want to do that it can't.
My 2c. YMMV! _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2020-03-30 Alberto Abrao wrote:
Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated.
That part is easier than you think. I haven't done it yet, mainly because I'm too cheap to spring for a plan with multiple statics, but I'm pretty sure you'll just set up your single interface to listen on multiple IPs. Then use routing and/or packet-mangling-de-jour methods to forward them to the correct internal boxes. After firewall-checks, of course. Easy for statics, but you might not be able to do more than 1 of your DHCP dynamic on that interface, though?? Unless you can setup a 2nd "fake" MAC on the same interface? Others can chime in.
I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate
I'm of the opinion that if you're a wizard it really doesn't matter if it's all one box or not. If they p0wn your firewall, chances are they'll then hop into whatever internal, less protected, box they want anyhow without much trouble. The key is to not get p0wned. I'm talking from a personal and micro-business standpoint: for corporate of course you'll want to throw money at separating everything. It's hard enough, and expensive enough, trying to keep X quality (read: ECC) boxes going, let alone X+1 boxes (and more +1's for every new task). I'd rather have 1 boss ECC system that I know won't give me grief do everything than a handful of cheap / small / esoteric boxes (probably with no ECC). It's my philosophy. I understand it's not shared by the writers of best practices. YMMV. If you've already learned OpenBSD and like it, of course stick with it, unless you've hit limitations. As for iptables vs pfsense, I've yet to run into a scenario tc/iptables/etc can't do, and I do some pretty wacky esoteric stuff on many boxes. However, here's a great example of why you'd like Fedora rather than CentOS: the newer, handy iptables features are generally bleeding edge and only to be found in distros that give you the bleeding kernel. If you're on the typical multi-year-old RHEL kernel then you may find that what you want to do isn't possible.
That could be a way, but I was more inclined to do it the way I assume - and the word is assume, as I have no idea - an ISP like Shaw is doing it: they assign addresses that are public facing to machines they have no access to, but they filter what goes in and out no problem. As we've discussed a few months ago, it's what goes for residential IPs. It's more about the know how than just getting something that works. I really need to step up my networking game. My setup here is nothing more than a lab. As far as I know, a managed router would be enough for most of my QoS needs, and the firewalls are doing their jobs on the two servers (using static IPs) + the internal network router (which grabs a residential DHCP address). But that would be too easy, I guess? And I am totally with you on the difference between small companies' requirements (and budgets!) compared to big ones. Hell, I used to set up OpenWRT routers with samba shares to replace aging Pentium III boxes running XP for Samba duties *AND* the pwned ISP-supplied router that had its DNS hijacked, and that was around 2015. The hard disk on that beige case alone was on borrowed time...hardcore. Of course most Canadian companies don't need to do something that extreme to save a buck, so you can order something really nice and get the job done with room to spare, ticking all the boxes, right? Nah... I am still SERIOUSLY looked down upon when I argue that my solution meet the requirements set, yet cost 1/10th of what was quoted by an "enterprise" vendor, and I am not even exaggerating. There's the solution of the issue and the process of selling it, and the more expensive it is, the more enterprisey it sounds, right? And THAT'S why I am trying to look pretty... =D I am not tied to any particular OS, as long as 1) it's open (e.g. not Windows) and 2) no GUIs. My plan was to have something that would do QoS and, after that is working, study how to move the firewall duties to it. I must make it clear that I don't expect anyone to walk me through it, hold my hand or anything. Some recommended reading would be all it takes, even if it's a monster tome. And I can't think of a better place to ask for this than here, otherwise I will have tons of people selling me Cisco stuff or whatever. And, once again, thank you everyone for chiming in. I really appreciate it. Alberto Abrao 204-202-1778 204-558-6886 www.abrao.net On 2020-03-30 11:06 p.m., Trevor Cordes wrote:
On 2020-03-30 Alberto Abrao wrote:
Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated. That part is easier than you think. I haven't done it yet, mainly because I'm too cheap to spring for a plan with multiple statics, but I'm pretty sure you'll just set up your single interface to listen on multiple IPs. Then use routing and/or packet-mangling-de-jour methods to forward them to the correct internal boxes. After firewall-checks, of course.
Easy for statics, but you might not be able to do more than 1 of your DHCP dynamic on that interface, though?? Unless you can setup a 2nd "fake" MAC on the same interface? Others can chime in.
I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate I'm of the opinion that if you're a wizard it really doesn't matter if it's all one box or not. If they p0wn your firewall, chances are they'll then hop into whatever internal, less protected, box they want anyhow without much trouble. The key is to not get p0wned. I'm talking from a personal and micro-business standpoint: for corporate of course you'll want to throw money at separating everything.
It's hard enough, and expensive enough, trying to keep X quality (read: ECC) boxes going, let alone X+1 boxes (and more +1's for every new task). I'd rather have 1 boss ECC system that I know won't give me grief do everything than a handful of cheap / small / esoteric boxes (probably with no ECC). It's my philosophy. I understand it's not shared by the writers of best practices. YMMV.
If you've already learned OpenBSD and like it, of course stick with it, unless you've hit limitations. As for iptables vs pfsense, I've yet to run into a scenario tc/iptables/etc can't do, and I do some pretty wacky esoteric stuff on many boxes. However, here's a great example of why you'd like Fedora rather than CentOS: the newer, handy iptables features are generally bleeding edge and only to be found in distros that give you the bleeding kernel. If you're on the typical multi-year-old RHEL kernel then you may find that what you want to do isn't possible.
By the way, there's another project I have... which is to consolidate all the stuff I've been spreading out a ECC-capable monster machine like Trevor mentioned, in order to learn to virtualize things other than Hyper-V instances for Windows Images. I even have the monster here - a power hog, and quite noisy, but hey! Still, to get there, I first need to finish spreading it all out. Heh! Alberto Abrao 204-202-1778 204-558-6886 www.abrao.net On 2020-03-31 12:28 a.m., Alberto Abrao wrote:
That could be a way, but I was more inclined to do it the way I assume - and the word is assume, as I have no idea - an ISP like Shaw is doing it: they assign addresses that are public facing to machines they have no access to, but they filter what goes in and out no problem. As we've discussed a few months ago, it's what goes for residential IPs.
It's more about the know how than just getting something that works. I really need to step up my networking game. My setup here is nothing more than a lab. As far as I know, a managed router would be enough for most of my QoS needs, and the firewalls are doing their jobs on the two servers (using static IPs) + the internal network router (which grabs a residential DHCP address). But that would be too easy, I guess?
And I am totally with you on the difference between small companies' requirements (and budgets!) compared to big ones. Hell, I used to set up OpenWRT routers with samba shares to replace aging Pentium III boxes running XP for Samba duties *AND* the pwned ISP-supplied router that had its DNS hijacked, and that was around 2015. The hard disk on that beige case alone was on borrowed time...hardcore. Of course most Canadian companies don't need to do something that extreme to save a buck, so you can order something really nice and get the job done with room to spare, ticking all the boxes, right? Nah... I am still SERIOUSLY looked down upon when I argue that my solution meet the requirements set, yet cost 1/10th of what was quoted by an "enterprise" vendor, and I am not even exaggerating. There's the solution of the issue and the process of selling it, and the more expensive it is, the more enterprisey it sounds, right? And THAT'S why I am trying to look pretty... =D
I am not tied to any particular OS, as long as 1) it's open (e.g. not Windows) and 2) no GUIs. My plan was to have something that would do QoS and, after that is working, study how to move the firewall duties to it.
I must make it clear that I don't expect anyone to walk me through it, hold my hand or anything. Some recommended reading would be all it takes, even if it's a monster tome. And I can't think of a better place to ask for this than here, otherwise I will have tons of people selling me Cisco stuff or whatever.
And, once again, thank you everyone for chiming in. I really appreciate it.
Alberto Abrao 204-202-1778 204-558-6886 www.abrao.net
On 2020-03-30 11:06 p.m., Trevor Cordes wrote:
On 2020-03-30 Alberto Abrao wrote:
Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated. That part is easier than you think. I haven't done it yet, mainly because I'm too cheap to spring for a plan with multiple statics, but I'm pretty sure you'll just set up your single interface to listen on multiple IPs. Then use routing and/or packet-mangling-de-jour methods to forward them to the correct internal boxes. After firewall-checks, of course.
Easy for statics, but you might not be able to do more than 1 of your DHCP dynamic on that interface, though?? Unless you can setup a 2nd "fake" MAC on the same interface? Others can chime in.
I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate I'm of the opinion that if you're a wizard it really doesn't matter if it's all one box or not. If they p0wn your firewall, chances are they'll then hop into whatever internal, less protected, box they want anyhow without much trouble. The key is to not get p0wned. I'm talking from a personal and micro-business standpoint: for corporate of course you'll want to throw money at separating everything.
It's hard enough, and expensive enough, trying to keep X quality (read: ECC) boxes going, let alone X+1 boxes (and more +1's for every new task). I'd rather have 1 boss ECC system that I know won't give me grief do everything than a handful of cheap / small / esoteric boxes (probably with no ECC). It's my philosophy. I understand it's not shared by the writers of best practices. YMMV.
If you've already learned OpenBSD and like it, of course stick with it, unless you've hit limitations. As for iptables vs pfsense, I've yet to run into a scenario tc/iptables/etc can't do, and I do some pretty wacky esoteric stuff on many boxes. However, here's a great example of why you'd like Fedora rather than CentOS: the newer, handy iptables features are generally bleeding edge and only to be found in distros that give you the bleeding kernel. If you're on the typical multi-year-old RHEL kernel then you may find that what you want to do isn't possible.
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2020-03-31 Alberto Abrao wrote:
I must make it clear that I don't expect anyone to walk me through it, hold my hand or anything. Some recommended reading would be all it takes, even if it's a monster tome. And I can't think of a better place to ask for this than here, otherwise I will have tons of people selling me Cisco stuff or whatever.
That's a great question. I wish I could refer you to a great tome (especially an O'Reilly book!) that would give the birds eye view of how you achieve your goals. Alas, even though I have 250 print ORM / NSP / Wiley books, none I've ever seen fits that bill. If I think back to how I learned this type of stuff (besides my University network course which was like a ISS-level view) it was basically reading iptables and tc man pages and looking at netfilter packet flow charts (some very good ones out there!) and then just tinkering. There is a NSP "Linux Firewalls" book (just won at the last meeting, unfortunately) which gives a decent intro to iptables, but is fairly dated and mostly focuses on an obscure packet monitoring program the author wrote, which probably isn't used much anymore. Not useful for what you are doing. I'm sure you'll find some pfsense books, but I bet there's not much for the DIYer who wants to roll their own (regardless of OS). Hopefully someone can prove me wrong! The funny thing is, in the end you'll spend hours/days figuring out a new tool or kernel feature only to write a handful of lines in a script or config file somewhere that does what you want. But then it's yours forever (in many ways)!
Personal preference. I would rather mess with a GUI after I understand the changes it is making under the hood. It helps me make sense of everything. When it comes to GUIs, OpenBSD gets a big advantage as most GUI-based OSS solutions for firewalling are based on BSDs, so I assume they would all be similar if not equal. I expect to have to have a GUI on top of whatever I deal with on a setup that's not my own, as that would be more convenient for most people or even myself on a regular day. Last, I assume you mean pf(4), as I can't find anything for of(4). Am I right? Thank you everyone. On 2020-03-31 8:49 a.m., athompso@athompso.net wrote:
Avoiding GUIs means you want to go one of two paths: OpenBSD with of(4) or some very-up-to-date Linux distro like Fedora with the latest nftables. Skip everything else. But why do you want to avoid a GUI completely? -Adam
I second the OpenBSD suggestion (though I suspect that was an obvious ‘given’). As to the question of multiple IPs… yeah that’s super easy. I'll over answer that... Here’s an example (where <IP#> is the dotted quads in question): lab-gw$ cat /etc/hostname.vic1 up inet <IP1> 255.255.255.0 NONE group egress inet alias <IP2> 255.255.255.0 inet alias <IP3> 255.255.255.0 Note the group is pretty important because you can use that in the PF config instead of hard coding IP’s in your PF config. I try and keep policy simple (having dealt with ridiculous 10,000+ rule firewalls is a maddening experience). That being said... friends don't let friends block ICMP... It's a dumb idea and claims of security are infantile and ignore 'availability.' Same goes for 'block drop' vs 'block return'... just don't block drop... fail fast, fail cleanly. It's a 'cut off your nose to spite your face' kind of situation. Here is a snippet example illustrating this (note this host has a number of networks and interfaces… notice no hard coded numbers)… This example doesn't include a DNAT for 'other IPs' but that is an easy man page away from resolving. lab-gw$ cat /etc/pf.conf set block-policy return set skip on lo antispoof for egress block return # Block stateless traffic (will optimize out but helps me frame ruleset). block log all # Default deny # Keep DEV & PROD separated block log quick from (dev:network) to (prod:network) block log quick from (prod:network) to (dev:network) # Allow infrastructure services/proxies to SNAT out to the Internet on primary IP. match out on egress from (lab:network) to any nat-to (egress:0) # Allow ICMP match out on egress proto icmp from (infrastructure:network) to any nat-to (egress:0) match out on egress proto icmp from (dev:network) to any nat-to (egress:0) match out on egress proto icmp from (prod:network) to any nat-to (egress:0) # Allow public services pass in on egress proto tcp from any to (egress:0) port ssh pass in on egress proto tcp from any to (egress) port {www,https} # Allow router specific traffic pass on egress proto icmp pass out on egress # Allow intra VLAN traffic where not short-circuit blocked. pass on infrastructure pass on dev pass on prod Finally as to the question of virtualizing one's gateway... well that's a personal choice. In a home environment... go for it. If you trust the configuration and know the machines ILOM/DRAC/AMT/Remote Management du jour won't respond on those interfaces then I don't see the harm in getting the most out of your gear. For a business, I have a best practice that base connectivity infrastructure should have minimal to no external dependencies on other services to function. Hypervisor is a hell of a dependency for a default gateway, same would go for DNS but that is my choice, balancing a risk profile of trust in infrastructure with faith it can come back up without intervention. That's just my opinion, you do you (but please be well informed). Any questions on the OpenBSD stuff... ask me off thread. From: Roundtable <roundtable-bounces@muug.ca> On Behalf Of athompso@athompso.net Sent: March 31, 2020 8:49 AM To: Continuation of Round Table discussion <roundtable@muug.ca> Subject: Re: [RndTbl] Main firewall / router for public facing subnet Avoiding GUIs means you want to go one of two paths: OpenBSD with of(4) or some very-up-to-date Linux distro like Fedora with the latest nftables. Skip everything else. But why do you want to avoid a GUI completely? -Adam On Mar. 31, 2020 00:28, Alberto Abrao <mailto:alberto@abrao.net> wrote: That could be a way, but I was more inclined to do it the way I assume - and the word is assume, as I have no idea - an ISP like Shaw is doing it: they assign addresses that are public facing to machines they have no access to, but they filter what goes in and out no problem. As we've discussed a few months ago, it's what goes for residential IPs. It's more about the know how than just getting something that works. I really need to step up my networking game. My setup here is nothing more than a lab. As far as I know, a managed router would be enough for most of my QoS needs, and the firewalls are doing their jobs on the two servers (using static IPs) + the internal network router (which grabs a residential DHCP address). But that would be too easy, I guess? And I am totally with you on the difference between small companies' requirements (and budgets!) compared to big ones. Hell, I used to set up OpenWRT routers with samba shares to replace aging Pentium III boxes running XP for Samba duties *AND* the pwned ISP-supplied router that had its DNS hijacked, and that was around 2015. The hard disk on that beige case alone was on borrowed time...hardcore. Of course most Canadian companies don't need to do something that extreme to save a buck, so you can order something really nice and get the job done with room to spare, ticking all the boxes, right? Nah... I am still SERIOUSLY looked down upon when I argue that my solution meet the requirements set, yet cost 1/10th of what was quoted by an "enterprise" vendor, and I am not even exaggerating. There's the solution of the issue and the process of selling it, and the more expensive it is, the more enterprisey it sounds, right? And THAT'S why I am trying to look pretty... =D I am not tied to any particular OS, as long as 1) it's open (e.g. not Windows) and 2) no GUIs. My plan was to have something that would do QoS and, after that is working, study how to move the firewall duties to it. I must make it clear that I don't expect anyone to walk me through it, hold my hand or anything. Some recommended reading would be all it takes, even if it's a monster tome. And I can't think of a better place to ask for this than here, otherwise I will have tons of people selling me Cisco stuff or whatever. And, once again, thank you everyone for chiming in. I really appreciate it. Alberto Abrao 204-202-1778 204-558-6886 http://www.abrao.net On 2020-03-30 11:06 p.m., Trevor Cordes wrote:
On 2020-03-30 Alberto Abrao wrote:
Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated. That part is easier than you think. I haven't done it yet, mainly because I'm too cheap to spring for a plan with multiple statics, but I'm pretty sure you'll just set up your single interface to listen on multiple IPs. Then use routing and/or packet-mangling-de-jour methods to forward them to the correct internal boxes. After firewall-checks, of course.
Easy for statics, but you might not be able to do more than 1 of your DHCP dynamic on that interface, though?? Unless you can setup a 2nd "fake" MAC on the same interface? Others can chime in.
I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate I'm of the opinion that if you're a wizard it really doesn't matter if it's all one box or not. If they p0wn your firewall, chances are they'll then hop into whatever internal, less protected, box they want anyhow without much trouble. The key is to not get p0wned. I'm talking from a personal and micro-business standpoint: for corporate of course you'll want to throw money at separating everything.
It's hard enough, and expensive enough, trying to keep X quality (read: ECC) boxes going, let alone X+1 boxes (and more +1's for every new task). I'd rather have 1 boss ECC system that I know won't give me grief do everything than a handful of cheap / small / esoteric boxes (probably with no ECC). It's my philosophy. I understand it's not shared by the writers of best practices. YMMV.
If you've already learned OpenBSD and like it, of course stick with it, unless you've hit limitations. As for iptables vs pfsense, I've yet to run into a scenario tc/iptables/etc can't do, and I do some pretty wacky esoteric stuff on many boxes. However, here's a great example of why you'd like Fedora rather than CentOS: the newer, handy iptables features are generally bleeding edge and only to be found in distros that give you the bleeding kernel. If you're on the typical multi-year-old RHEL kernel then you may find that what you want to do isn't possible.
Roundtable mailing list mailto:Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Corrected; seems my message's newlines got trampled... (each inet stanza should be on it's own line). -----Original Message----- From: Roundtable <roundtable-bounces@muug.ca> On Behalf Of Sean Cody Sent: April 1, 2020 10:21 PM To: 'Continuation of Round Table discussion' <roundtable@muug.ca> Subject: Re: [RndTbl] Main firewall / router for public facing subnet I second the OpenBSD suggestion (though I suspect that was an obvious ‘given’). As to the question of multiple IPs… yeah that’s super easy. I'll over answer that... Here’s an example (where <IP#> is the dotted quads in question): lab-gw$ cat /etc/hostname.vic1 up inet <IP1> 255.255.255.0 NONE group egress inet alias <IP2> 255.255.255.0 inet alias <IP3> 255.255.255.0 Note the group is pretty important because you can use that in the PF config instead of hard coding IP’s in your PF config. I try and keep policy simple (having dealt with ridiculous 10,000+ rule firewalls is a maddening experience). That being said... friends don't let friends block ICMP... It's a dumb idea and claims of security are infantile and ignore 'availability.' Same goes for 'block drop' vs 'block return'... just don't block drop... fail fast, fail cleanly. It's a 'cut off your nose to spite your face' kind of situation. Here is a snippet example illustrating this (note this host has a number of networks and interfaces… notice no hard coded numbers)… This example doesn't include a DNAT for 'other IPs' but that is an easy man page away from resolving. lab-gw$ cat /etc/pf.conf set block-policy return set skip on lo antispoof for egress block return # Block stateless traffic (will optimize out but helps me frame ruleset). block log all # Default deny # Keep DEV & PROD separated block log quick from (dev:network) to (prod:network) block log quick from (prod:network) to (dev:network) # Allow infrastructure services/proxies to SNAT out to the Internet on primary IP. match out on egress from (lab:network) to any nat-to (egress:0) # Allow ICMP match out on egress proto icmp from (infrastructure:network) to any nat-to (egress:0) match out on egress proto icmp from (dev:network) to any nat-to (egress:0) match out on egress proto icmp from (prod:network) to any nat-to (egress:0) # Allow public services pass in on egress proto tcp from any to (egress:0) port ssh pass in on egress proto tcp from any to (egress) port {www,https} # Allow router specific traffic pass on egress proto icmp pass out on egress # Allow intra VLAN traffic where not short-circuit blocked. pass on infrastructure pass on dev pass on prod Finally as to the question of virtualizing one's gateway... well that's a personal choice. In a home environment... go for it. If you trust the configuration and know the machines ILOM/DRAC/AMT/Remote Management du jour won't respond on those interfaces then I don't see the harm in getting the most out of your gear. For a business, I have a best practice that base connectivity infrastructure should have minimal to no external dependencies on other services to function. Hypervisor is a hell of a dependency for a default gateway, same would go for DNS but that is my choice, balancing a risk profile of trust in infrastructure with faith it can come back up without intervention. That's just my opinion, you do you (but please be well informed). Any questions on the OpenBSD stuff... ask me off thread. From: Roundtable <roundtable-bounces@muug.ca> On Behalf Of athompso@athompso.net Sent: March 31, 2020 8:49 AM To: Continuation of Round Table discussion <roundtable@muug.ca> Subject: Re: [RndTbl] Main firewall / router for public facing subnet Avoiding GUIs means you want to go one of two paths: OpenBSD with of(4) or some very-up-to-date Linux distro like Fedora with the latest nftables. Skip everything else. But why do you want to avoid a GUI completely? -Adam On Mar. 31, 2020 00:28, Alberto Abrao <mailto:alberto@abrao.net> wrote: That could be a way, but I was more inclined to do it the way I assume - and the word is assume, as I have no idea - an ISP like Shaw is doing it: they assign addresses that are public facing to machines they have no access to, but they filter what goes in and out no problem. As we've discussed a few months ago, it's what goes for residential IPs. It's more about the know how than just getting something that works. I really need to step up my networking game. My setup here is nothing more than a lab. As far as I know, a managed router would be enough for most of my QoS needs, and the firewalls are doing their jobs on the two servers (using static IPs) + the internal network router (which grabs a residential DHCP address). But that would be too easy, I guess? And I am totally with you on the difference between small companies' requirements (and budgets!) compared to big ones. Hell, I used to set up OpenWRT routers with samba shares to replace aging Pentium III boxes running XP for Samba duties *AND* the pwned ISP-supplied router that had its DNS hijacked, and that was around 2015. The hard disk on that beige case alone was on borrowed time...hardcore. Of course most Canadian companies don't need to do something that extreme to save a buck, so you can order something really nice and get the job done with room to spare, ticking all the boxes, right? Nah... I am still SERIOUSLY looked down upon when I argue that my solution meet the requirements set, yet cost 1/10th of what was quoted by an "enterprise" vendor, and I am not even exaggerating. There's the solution of the issue and the process of selling it, and the more expensive it is, the more enterprisey it sounds, right? And THAT'S why I am trying to look pretty... =D I am not tied to any particular OS, as long as 1) it's open (e.g. not Windows) and 2) no GUIs. My plan was to have something that would do QoS and, after that is working, study how to move the firewall duties to it. I must make it clear that I don't expect anyone to walk me through it, hold my hand or anything. Some recommended reading would be all it takes, even if it's a monster tome. And I can't think of a better place to ask for this than here, otherwise I will have tons of people selling me Cisco stuff or whatever. And, once again, thank you everyone for chiming in. I really appreciate it. Alberto Abrao 204-202-1778 204-558-6886 http://www.abrao.net On 2020-03-30 11:06 p.m., Trevor Cordes wrote:
On 2020-03-30 Alberto Abrao wrote:
Doing it for a single external IP is manageable to me, the thing is the leap in doing it for multiple public IPs. I do know I have some heavy reading ahead, and I look forward to it. Any recommendations are very much appreciated. That part is easier than you think. I haven't done it yet, mainly because I'm too cheap to spring for a plan with multiple statics, but I'm pretty sure you'll just set up your single interface to listen on multiple IPs. Then use routing and/or packet-mangling-de-jour methods to forward them to the correct internal boxes. After firewall-checks, of course.
Easy for statics, but you might not be able to do more than 1 of your DHCP dynamic on that interface, though?? Unless you can setup a 2nd "fake" MAC on the same interface? Others can chime in.
I used to do one-box-for-everything as well, mostly because I didn't have a lot of equipment to begin with. However, I see lots of people talking about security, and I can see having things on separate I'm of the opinion that if you're a wizard it really doesn't matter if it's all one box or not. If they p0wn your firewall, chances are they'll then hop into whatever internal, less protected, box they want anyhow without much trouble. The key is to not get p0wned. I'm talking from a personal and micro-business standpoint: for corporate of course you'll want to throw money at separating everything.
It's hard enough, and expensive enough, trying to keep X quality (read: ECC) boxes going, let alone X+1 boxes (and more +1's for every new task). I'd rather have 1 boss ECC system that I know won't give me grief do everything than a handful of cheap / small / esoteric boxes (probably with no ECC). It's my philosophy. I understand it's not shared by the writers of best practices. YMMV.
If you've already learned OpenBSD and like it, of course stick with it, unless you've hit limitations. As for iptables vs pfsense, I've yet to run into a scenario tc/iptables/etc can't do, and I do some pretty wacky esoteric stuff on many boxes. However, here's a great example of why you'd like Fedora rather than CentOS: the newer, handy iptables features are generally bleeding edge and only to be found in distros that give you the bleeding kernel. If you're on the typical multi-year-old RHEL kernel then you may find that what you want to do isn't possible.
Roundtable mailing list mailto:Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
participants (5)
-
Adam Thompson -
Alberto Abrao -
athompso＠athompso.net
-
Sean Cody -
Trevor Cordes