Kitz Forum
Computers & Hardware => Networking => Topic started by: Weaver on November 21, 2022, 01:10:39 PM
-
Say that you and I both have IPv6 - to make things easier, otherwise IPv4 with real IPv4 addresses will do fine. You want to connect your box to mine directly, that is without going through some intermediate server that forwards traffic. We both have the usual "Count Dracula + virgin" stateful firewalls in our routers and no software "firewalls" in our own boxen. How do we do it? That is, if we want to write a protocol to break through the firewall and effectively declare to the router that access is authorised. (And knowledge of or fiddling with the router settings is not allowed btw. Nor any hacking allowed.)
-
Send one another UDP flows with the same source and destination port, or source and destination reversed. Your outbound port 10,000 to port 10,000 connection will open a flow in the firewall in that direction, mine will open a flow in mine. Your source 10000, destination 20000 will open a flow your side, my source 20000 destination 10000 will open the path for you.
-
Excellent. :)
Here we go. Some speculative vague+ignorant stuff.
I’m wondering how firewalls’ behaviour might or might not vary. [btw - I have omitted IPv4/v6 protocol version field from what follows.]
It seems to me to be possibly a very daft idea, but I’m wondering if
a match on: (src_addr, dst_addr, IP_protocol_x=prot1 )
might actually be handled as: (src_addr, dst_addr, IP_protocol_x=*) under certain circumstances. And this is intentionally left vague.
Or a match on: (src_addr, dst_addr, IP_protocol_x=prot1, dest_port=port1)
might be treated as: (src_addr, dst_addr, IP_protocol_x=prot1 or *, dest_port=*)
This kind of wider-related matching, if it exists, is either really useful, or really dangerous and in any case should be an option that is highly configurable.
I don’t know about the variability in firewalls’ behaviours / capabilities / options, as you see. Usual level of ignorance from me.
It might be handy here, to be able to use a busting technique set up with UDP to also affect other protocols even. So saying "I trust machine x completely" would mean "all incoming traffic from x is ok". But it might be better to have the option of filtering this and being more selective about the allowed traffic types from machine x.
It would be so great if there were an RFC for firewall config protocol, and also for remote firewall config, where requests are of course either signed, or else encrypted and contain a field that is a pre-shared key. Much better than hole-busting trickery.
-
Unlikely on both counts. A full layer 3 match of source, destination and IP protocol would be expected: anything else is a bug. Where there's a transport protocol in use a full L4 source/destination match would be expected.
No room for any wildcards. The inbound flow has a counterpart outbound flow, so TCP doesn't work, or it doesn't.
I'm talking about (mis)using statefulness in basic firewalls here. Obviously the rulesets can be anything from a full 5tuple match to any-any.
-
This write up of firewall and NAT traversal from tailscale is a good read and seems relevant:
https://tailscale.com/blog/how-nat-traversal-works/
-
It would be so great if there were an RFC for firewall config protocol, and also for remote firewall config, where requests are of course either signed, or else encrypted and contain a field that is a pre-shared key. Much better than hole-busting trickery.
This is interesting if I understand where you're going.
May an entity control their firewalls remotely en masse: absolutely. Template pushes are a thing.
Remote firewall configuration by a third party no ifs, no buts, just no.
The business departments / enterprises talk and agree modifications to their firewall sets to allow them to achieve objectives.
Third parties and firewalls just no. If they're third party contractors give them a VPN onto the network.
At no point should a firewall respond to a configuration request from outside the perimeter of trust it requires in. People connecting to the intranet via VPN are within that trusted group.
As are orchestration services and management services with the necessary permissions, access and authentication. Let them have that if they need access
An RFC to allow remote management of firewalls is not happening as they're proprietary kit with proprietary management platforms. Want to give a third party permission to change firewall policies give them a VPN to your orchestration service, let them modify templates, etc as necessary.
-
@weaver If I understand your original question correctly, I think what you are describing in effect is the same 'hole punching' that is already widely used for applications such as VoIP, Games, etc albeit this does require a server to help with establishing the session.
-
@johnson absolutely amazing work from tailscale and a very good write-up. They really have worked hard at this.
It just reminds me once again what a scandal IPv4 NATs are. I’m so glad that I saw the light and got rid of NAT 15 years ago. When I was a Demon and Zen user, I didn’t have NAT myself with either ISP at the end, even before I moved to AA.
-
If it doesn't require unsolicited inbound connectivity, and most things don't, NAT is fine.
-
@johnson absolutely amazing work from tailscale and a very good write-up. They really have worked hard at this.
It just reminds me once again what a scandal IPv4 NATs are. I’m so glad that I saw the light and got rid of NAT 15 years ago. When I was a Demon and Zen user, I didn’t have NAT myself with either ISP at the end, even before I moved to AA.
But what do you actually use that doesn't work with NAT? I mean for most things double-NAT is not even an issue, good thing thanks to CG-NAT now.
-
I don’t really know how to answer that. I’ve been NAT-free for so long. I did get utterly sick of having to remotely log into a server belonging to a customer and then reconfigure port NAT redirection of RDP so that I could then go and look at another machine.
That’s not what I really object to most, it’s the cost to developers and the loss of so many opportunities over the years for a rich spread of imaginative peer-to-peer apps, probably including a number of ideas that we have not yet thought up because of IPv4 NAT. Mind you, to be fair, using IPv6 gets us out of the peer-to-peer problem. Again, the existence of NAT has prolonged the existence of IPv4 when it should have died well over ten years ago because of address exhaustion. I do have to say that the very existence of firewalls is also a crucial factor in stalling the growth of peer-to-peer novel apps. Imagine a world without firewalls! What things would we then be able to do? Or at least a world without overly restrictive firewalls with unhelpful default rules that prohibit useful communications as well as nuisance and DDOS behaviour. We need protection against the latter to be also placed deeper within the network, and we need defences that are far more reactive, context-sensitive, controllable and relevant. A final admission, my visceral loathing of IPv4 NAT and clinging on to IPv4 simply because of inertia is far from logical; I’d say that there’s definitely something irrational about my attitudes here. I do hate old designs that should IMHO have been put to bed a long time ago. It’s like my dislike of TCP, also not entirely logical, but that’s another rant for another day, most definitely.
Hypocrisy alert: I confess that a few years ago I found a use for IPv4 NAT within my Firebrick router. I discovered that it’s a way of letting me talk to the admin i/fs of my four modems which are attached to the router. The Firebrick NAT-rewrites the packets exchanged between a modem i/f and my own machine on my main LAN.
-
I don’t really know how to answer that.
I can entirely empathise: I haven't a clue how to answer yours but will try ;D
The RDP issue: shouldn't be using RDP across the Interwebs but if you were why not destination NAT on outside for port 3389 mapping 3389 to one machine, 3390 to 3389 on another, 3391, etc, or better yet 33389 for first one to make port scanning more dull for nosey folks? :)
Peer to peer apps: are you familiar with Napster, KaZaA, eDonkey, etc? We've moved towards centralising compute, storage, etc, for efficiency but for other things we certainly have peer to peer - play games online and in many cases they're peer to peer or one of the players hosts. Been knocking around since the dialup days. With dynamic IP addresses have to have lobbies anyway, these can easily be used to punch holes in NAT.
Firewalls are required for the same reason most of us have to lock our doors at night. The default deny at the end of them is essential. Sad as it is they are necessary. Without them we'd all be at the mercy of bad actors. The default deny at the end means my big router's ruleset is this, and 2 of them direct the system to hardware offload and fasttrack, not allow/deny, one is cosmetic:
[admin@MikroTik] /ip/firewall/filter> print
Flags: X - disabled, I - invalid; D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 chain=forward action=fasttrack-connection hw-offload=yes in-interface-list=LANs log=no log-prefix=""
2 chain=forward action=fasttrack-connection hw-offload=yes connection-state=established,related in-interface=SFP3-YouFibre1 log=no log-prefix=""
3 chain=forward action=accept in-interface-list=LANs log=no log-prefix=""
4 chain=forward action=accept connection-state=established,related in-interface=SFP3-YouFibre1 log=no log-prefix=""
5 chain=input action=accept in-interface-list=LANs log=no log-prefix=""
6 chain=input action=accept protocol=icmp in-interface=SFP3-YouFibre1 log=no log-prefix=""
7 chain=input action=accept connection-state=established,related,untracked in-interface=SFP3-YouFibre1 log=no log-prefix=""
8 chain=input action=accept in-interface=ether13-RTR-Mgmt log=no log-prefix=""
[admin@MikroTik] /ip/firewall/nat> print
Flags: X - disabled, I - invalid; D - dynamic
0 chain=srcnat action=masquerade out-interface=SFP3-YouFibre1 log=no log-prefix=""
DDoS protection of a good standard is reactive, context-sensitive, controllable and relevant. I'll find you a picture of the controls I have on my lab here, though this is enterprise grade, not whatever is found in regular home equipment which is, frankly, worthless. DDoS protection at home is a nice placebo but doesn't actually do anything.
Don't think it should be deep in the network: it should be as close as possible to the Internet-facing edge so that you don't waste capacity transporting junk into your core. Ideally the junk doesn't touch the network at all: systems that detect DDoS based on telemetry and then have the network stop advertising those prefixes and have a specific screening service take over are pretty cool.
-
Don't think it should be deep in the network: it should be as close as possible to the Internet-facing edge so that you don't waste capacity transporting junk into your core. Ideally the junk doesn't touch the network at all: systems that detect DDoS based on telemetry and then have the network stop advertising those prefixes and have a specific screening service take over are pretty cool.
That's one of the big things about Cloudflare proxy isn't it, they can redirect attacks to their dedicate DDoS black hole. Although its sad that the only solution is to have tons of spare bandwidth to syphon off the invalid traffic.
-
I would very much like to know about ISP-side firewalls. Keeping evil traffic away further upstream rather than having it come down your internet access link only to get dropped by your firewall. I wish A&A offered this as for me it would be a killer feature to have.
Has there been an ISP that offered such a thing ever? Some highly dubious ancient recollection says "PlusNet" ?
That kind-of links into my thinking earlier about firewall remote control, but with some major differences; before I was thinking about more dynamic firewall control driven by code whereas here I’m thinking that ISP-side firewalls would have a configuration that was set up in a control panel, and hopefully also accompanied by a very very lightweight machine-to-machine API protocol.
-
I agree with XGS on NAT.
As an example Weaver I was only recently thinking about this, I had the NAT rules on my firewall set to log traffic (from when I enabled for diagnosing a problem) and was seeing some end points accessing those ports, so is this a NAT problem? Well the reality is if I was using routable IPs to each client device the ports would still be open on the firewall.
I even deliberately run some virtual servers on NAT now in datacentres to save IP addresses as they have become really expensive, there is no technical issues, some hobby projects I run which give no revenue, I saved the rental expenditure on dedicated IP addresses. One of my servers, I pay more for the IP's than leasing the bandwidth and hardware.
I also used to run a big project some years back across over 40 physical servers, only 2 out the 40 had internet facing IP's rest was all NAT, the backend etc.
Many datacentres do indeed offer firewalls of their own in the control panel they supply as well.
I remember back in the pre Windows XP SP2 days, a friend of mine installed Windows XP on his ICS machine back in the day (before NAT routers were widespread), was directly connected to ISP modem, within seconds of it booting up it was compromised by a internet virus, XP firewall in those days wasnt default deny inbound.
-
What Chrys was saying very much matches my experience, and now I’ve been dragged back into ancient history, to the times when I was still well. :-)
About 18-20 years ago, one of my neighbours got infected within around 5 mins after connecting a Win XP (not SP2) box to the internet with default settings. (Time-till-infection inferred from a later simple experiment iirc.) They took the box back to the shop and had Windows XP reinstalled on it and somehow had some random antivirus software installed with it. This time they did much better, it lasted about 30 days before becoming infected. In distress they came to me wanting a freebie as they were far too cheap to want to pay my normal consultancy rates so I refused to get involved as there would be no payment for my work and they probably wouldn’t follow my draconian future security restrictions needed to keep the machine healthy and well secured. I did agree to look at the box briefly though, told them they were correct as it was indeed crawling with nasties. The first things that the malware had done were to destroy the AV software and turn off the software firewall. The latter being an interesting point, seeing as software firewalls can simply be turned off by malware there’s little point having them. I told them that every infected machine I had ever gone to had (once) had antivirus software running on it, well let’s say the AV s/w was "supposedly installed" and that the mfr or user had installed and not removed it. There was the usual sorrowful whimper of "but I had antivirus, and a firewall". One could indeed have some sympathy with home and business users in such a situation. But after confirming the diagnosis I went and left it well alone, since, as I said earlier, the users were not up for paying for professional security consulting services. I did add these two experiences to the time until infection stats records that I was keeping though.
God, Win XP (pre SP3) was a dog’s breakfast, and when it came out I was immediately horrified as I couldn’t believe the cynical attitude of Microsoft, who were releasing XP, the first truly home user Win NT family product, with the default privilege level being that of administrator not that of a standard user. It’s was a disaster compared with NT 4.0 in this respect (and was that also true [?] for the fine NT 5.0 aka Win2k ? - can’t remember). And there was also MS’s couldn’t care less attitude of not forcing developers to make all apps run fine without enhanced (ie administrator) privileges. They of course knew that the result would be chaos and disaster for the users (and for MS themselves too if they had any wit at all). MS should have had an app certification program, like Apple does now with the app store and which some serious o/s vendors such as DEC did when you paid a lot of money for some software and it would be "certified"/"approved" or whatever so you know that such software would work and not wreck the o/s.
I never ever bothered with software firewalls in Windows; always removed them immediately as one less thing to have to debug. And it goes without saying that I always clean-installed Win NT-family o/s’s straight from genuine MS media so no third-party antivirus in sight.
Mind you, perhaps the value, if any, that software firewalls have where they are fully deeply integrated into the o/s and well-secured as an o/s core feature is as a more or less sophisticated system of ACLs, which should have capabilities of process-awareness (pid-awareness) and application-awareness, or a friendlier abstraction of both of the two, that can be quoted in firewall rules. This is something that is hard to integrate into hardware firewalls. Perhaps a very very powerful and extremely friendly capability could come from exporting o/s-concept-level annotations into a hardware firewall. An o/s sends a set of "labels" to a firewall or router and these labels allows the device to display flows / sessions with meaningful language, so that source ports and of course source addresses are mapped to pids and to app names and IP addresses are of course mapped to names of boxes. (I like the 20-bit flow label thing in IPv6, shame what has happened with it, btw.) IPv6 horrible addresses really need translating into english and expanding fully now more than ever. Perhaps once again there might be scope for remote control of hw firewalls so that an o/s with its per-app and per-process type ACLs could send those up to a gate wall firewall and pre-translate the ACLs into per-src-port etc language that is easy for a firewall to understand. Alternatively sending up rules in a "OS-type / ACL format" would mean that the o/s wouldn’t have to understand everything about the details of firewalls’ differing native rule formats, giving some abstraction. Mind you, not sure if that’s entirely a good or safe thing, as we want things to fail if the firewall’s capabilities don’t match what we’re trying to get.
Apologies to XGS, Chrys et al for wandering off into my former designer life 25 yrs ago, but with things now surely made extremely foggy and annoyingly vague and half-baked.
-
That was part of the beauty of NAT, it avoided a lot of these issues. Once I actually started paying for dialup it wasn't long until I moved that onto Linux with its experimental NAT support as I had already built a cheap gaming LAN with recycled computers where we could all go online at the same time. It kinda makes me sad how people raised with Internet access as standard have no appreciation for networking in general.
As someone who had WiFi since 802.11b when it barely worked, it still blows my mind just how well it all works these days.
-
Apologies to XGS, Chrys et al for wandering off into my former designer life 25 yrs ago, but with things now surely made extremely foggy and annoyingly vague and half-baked.
Never, ever apologise. It starts conversations.
If it's okay I'll send you a PM with some things in it you might find interesting. Posting them in public would be a little too much exposure and while it's pretty easy for anyone with more than a passing interest to work out who I am best not to advertise too loudly :)
-
Thanks, much appreciated. Always, always ready to learn.