> How many variables can there be?
Normally not something you consider, but under attack, this comes down to
standard networking tuples. Source ip, source port, destination ip,
destination port, and protocol (tcp, udp, icmp, etc).
Sadly most folks don't think about it like this, but anyone that admins
security, firewalls, or cloud acls does. Again, this to that. Those
5-step tuples of info are primarily for things like netflow reporting and
others that do network management, reporting, and the like.
Add in things like firewall or ddos prevention (think cloudflare, prolexic,
like), this is what they act upon volumetrically. Thread the needle port
to port to get public to your resource, verify integrity in-path. Working
for service providers years ago taught me about what DDoS can do to you,
and how to prevent such things if possible volumetrically.
It's really just a matter of making sure dns, port access, and whatever
inspection you want works on ingress. If something else blasts you,
redirect accordingly.
Take for example Microsoft was getting DDoS'd across all services last week
<
https://go.theregister.com/feed/www.theregister.com/2023/06/13/microsoft_azure_ddos/>,
they're literally blasting destination port/protocol services to deny
service to take Azure entirely down at the management portal level. Blast
a destination port/ip/dns service enough, it all crumbles, but this is what
is required to run public services these days.
-mb
On Tue, Jun 13, 2023 at 10:17 PM Michael Butash <
michael@butash.net> wrote:
> One cannot downplay the importance of things like this today, particularly
> with k8s and various iterations of it around docker. NAT is not a foreign
> concept, or shouldn't be in 2023.
>
> I remember working in Silicon Valley circa 1999 and no one had firewalls.
> Our call center was on public ip's, and then we were getting hacked because
> the company at the time had no clue of security. I led an effort to
> install blackice pirated (not for commercial use!) across all call center
> computers to affect change, but gave up and left the company shortly
> thereafter as they obviously didn't "get it".
>
> Docker is meant to separate network environments via nat for very good
> reason. It creates a controllable ingress point, and can thus be run
> through as stringent an inspection as desired, or not. This to That port
> translations are meant to be a checkpoint of acknowledgement of traffic and
> thus inspection, as much or little as you want at that point.
>
> Case in point, Fortigate firewalls are lit up this week for again exposing
> their arse to the internet insecurely. Their sslvpn application that
> expects to be publicly accessible is easily hacked, and thus every
> fortigate that didn't patch in the first day is owned.
>
> If you forward ports, do so with reasonable intent and acknowledgement of
> doing so in a secure fashion. Otherwise don't forward the goddamn port, or
> let dumb things do so on your behalf without reasonable understanding.
>
> -mb
>
>
> On Tue, Jun 13, 2023 at 8:55 PM David Schwartz via PLUG-discuss <
> plug-discuss@lists.phxlinux.org> wrote:
>
>> Thanks for the pep talk, Michael. :-)
>>
>> I was heavily involved in networking and all that stuff back in the 80’s
>> and so I can say that I do understand it … or at least did at one point.
>> But for the past 20 years I’ve worked in environments where there was an IT
>> Dept that was always there handling things — even simple things. So I’ve
>> lost touch with all of the different layers and levels of indirection that
>> are involved today.
>>
>> I built this service following a guide laid out by a guy who I assume
>> knows what he’s talking about, but he says it just connects to either
>> localhost or a local IP (192.168.x.y). I’ve gotten lost in situations when
>> people show examples or create tutorials that are really only designed to
>> run within a local environment, and when you ask about “opening them up”,
>> you’re told, “Oh, that’s outside the scope of this material”. This guy
>> offered to let me hire him for his “typical hourly rate” to help get the
>> service I built — following his detailed instructions — working on a remote
>> host. He said, “there are just too many variables involved”. In my mind,
>> it’s a vanilla Windows Server 2016 running on a VPN hosting a service built
>> according to his plans. How many variables can there be?
>>
>> -David Schwartz
>>
>>
>>
>>
>> On Jun 13, 2023, at 5:32 PM, Michael Butash via PLUG-discuss <
>> plug-discuss@lists.phxlinux.org> wrote:
>>
>> As a "network guy", i.e. someone operating at layer 1-4 mostly, I would
>> say you need to understand networking first. So few developers and system
>> folk do, and thus struggle in today's day and age around basic networking
>> functions in a cloud world. It's some basic tradition of "when a packet in
>> a pocket hits a socket" like a childhood rhyme that goes unheard, and
>> really should if you call yourself a self-respecting developer today or the
>> past 20 years.
>>
>> Understanding basic Layer 1-7 of the network OSI model is the key.
>>
>> Docker relies heavily on NAT and IP routing between systems. Even
>> installing a typical web/app/db stack requires local socket interaction
>> between devices using the same networking - perhaps start with this first
>> and understand local socket connections to 127.0.0.1 first. Then move into
>> docker and IProute2 namespace separation with Docker and like
>> technologies. If you understand how a firewall works, this isn't that much
>> more complex.
>>
>> Keeping a consistent control plane between applications (again
>> web/app/db) and basic ip reachability isn't too hard when you understand
>> vlans and networking, maybe extending into overlay tech like Zerotier and
>> Tailscale for apps to talk to each other, securely, and across
>> clouds/networks/domains in general.
>>
>> I could give a whole "In the beginning.." speech, but best you simply
>> learn some networking first.
>>
>> -mb
>>
>>
>> On Tue, Jun 13, 2023 at 3:19 PM David Schwartz via PLUG-discuss <
>> plug-discuss@lists.phxlinux.org> wrote:
>>
>>> Right now I just want to be able to run my web app on my phone and have
>>> it access my back-end service remotely.
>>>
>>> I’m just having a challenge getting that "signal chain” set up and
>>> working. I know what it’s supposed to be in theory; it’s just not as easy
>>> as plugging a wire between a couple of sockets.
>>>
>>> Docker is optional.
>>>
>>> How can I do something like a "signal trace” in Windows?
>>>
>>> -David Schwartz
>>>
>>>
>>>
>>>
>>> On Jun 13, 2023, at 2:19 PM, Michael Butash via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>>
>>> Docker should be an inside to outside port mapping for your
>>> application. The outside port maps needs to reflect your firewall, load
>>> balancer, or whatever forwards traffic to it as the destination.
>>>
>>> [internet]-[firewall]-[host]-[docker] - you want to thread the needle of
>>> ports. This to That.
>>>
>>> If you don't want public facing ports for security reasons, vpn like
>>> openvpn or an overlay like zerotier/tailscale is recommended.
>>>
>>> -mb
>>>
>>>
>>>
>>> On Tue, Jun 13, 2023 at 2:03 PM David Schwartz via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>>
>>>> I’m looking for someone familiar with Docker who can help me out a
>>>> little bit.
>>>>
>>>> I’m working on an app with a REST-based web service that I’ve been
>>>> building inside of a VM (VirtualBox) running Win 10. I’m having trouble
>>>> getting the service part working on a remote server, and someone suggested
>>>> using Docker to isolate it and get it running inside of the VM first, then
>>>> copy it to the remote server. The remote server is also Windows based,
>>>> obviously.
>>>>
>>>> I’m having trouble getting all of the IPs and ports and holes in the
>>>> firewall aligned so I can reach it from outside the server.
>>>>
>>>> Right now I probably don’t _need_ Docker, although it could be helpful
>>>> at some point when I’ll need to scale-up, so I’m not even really committed
>>>> to using it other than it might be easier to set it up inside of the VM and
>>>> make everything work there first.
>>>>
>>>> (As much as I’d like to build the service to run on Linux, one of the
>>>> libraries I’m using is not set up for Linux yet, so it’s not an option at
>>>> this time. The vendor says they might support Linux at some point in the
>>>> future.)
>>>>
>>>> Anyway, I’m just looking to see if anybody might be able to help me get
>>>> my service code running on a remote Windows server that’s accessible from
>>>> elsewhere. (The code itself runs on the server, I just can’t reach it from
>>>> the outside, which is the whole point of having it there.)
>>>>
>>>>
>>>> -David Schwartz
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
---------------------------------------------------
PLUG-discuss mailing list:
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)