[RndTbl] Main firewall / router for public facing subnet

Wed Apr 1 22:20:58 CDT 2020

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 at muug.ca> On Behalf Of athompso at athompso.net
Sent: March 31, 2020 8:49 AM
To: Continuation of Round Table discussion <roundtable at 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 at 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 at muug.ca 
https://muug.ca/mailman/listinfo/roundtable 