Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add firewall documentation #20

Merged
merged 3 commits into from
Sep 16, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 13 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,8 +63,19 @@ The server also opens the port 80 so if you forget to write the URL
with https:// , Nginx redirects the request to the HTTPS version
for you 😉.

**Docker note**: A local image is created the first time executed, and
there is no need to rebuild it if you change the Nginx configuration or the `entrypoint.sh` file. Only changes to the Dockerfile script require a rebuild. If you just edit the Nginx configuration, or want to change the ports mapped, only restart the container is needed.
#### Firewall

The HTTP/HTTPS ports (`80`/`443`) need to accept traffic from the IP address of your host machine and your local webapp port (e.g. `5988`) needs to accept traffic from the IP address of the `nginx-local-ip` container (on the Docker network). If you are using the UFW firewall (in a Linux environment) you can allow traffic on these ports with the following commands:

> Since local IP addresses can change over time, ranges are used in these rules so that the firewall configuration does not have to be updated each time a new address is assigned.

```.sh
$ sudo ufw allow proto tcp from 192.168.0.0/16 to any port 80,443
Copy link
Contributor

@mrjones-plip mrjones-plip Sep 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll "lgtm" the PR as this is minor, but since a lot of people run a different RFC1918 subnet on their LAN (eg 10.10.0.0/24), they'd have to change this. Since they're more likely to have a /24 than a /16 on their local LAN, I'd say go with the /24 instead of the /16.

(Noted that /16 as is, goes up to my LAN's subnet 192.168.68.0/24 - which is quite handy ; )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since they're more likely to have a /24 than a /16 on their local LAN

@mrjones-plip, am I wrong or wouldn't /16 include all the addresses covered by /24? Maybe I am totally off, but it based on what I was reading I thought that the range covered increases as the mask number decreases (seems very counter-intuitive...).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No no! You're totally correct: A /16 covers way more (65k) than a /24 (256), just like that link you cited says. However, a 192.168.0.0/16 won't cover a 10.10.0.0/24. And given few, if any, folks will run a /16 on their LAN, I was just saying that they'd be more familiar and comfortable with changing it to their specific /24 instead of wondering if the /16 covers their range or not. TMI on all three RFC1918 ranges here, but all in there's 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16

Still - this is good as is I think!

$ sudo ufw allow proto tcp from 172.16.0.0/16 to any port 5988
```

#### Docker note
jkuester marked this conversation as resolved.
Show resolved Hide resolved
A local image is created the first time executed, and there is no need to rebuild it if you change the Nginx configuration or the `entrypoint.sh` file. Only changes to the Dockerfile script require a rebuild. If you just edit the Nginx configuration, or want to change the ports mapped, only restart the container is needed.

If you do need to rebuild the container, append `--build` on to your compose call: ` docker-compose up --build`.

Expand Down
6 changes: 6 additions & 0 deletions docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,9 @@ services:
APP_URL: $APP_URL
HTTP: $HTTP
HTTPS: $HTTPS

networks:
default:
ipam:
config:
- subnet: 172.16.0.0/16
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice ! Going to test in a few minutes ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah - nice trick! just docker stop didn't do the trick for mme, but after some harder hitting prune calls, I'm in the right zone \o/

Before:

docker network inspect $(docker network ls | awk '$3 == "bridge" { print $1}') | jq -r '.[] | .Name + " " + .IPAM.Config[0].Subnet' -
nginx-local-ip_default 172.20.0.0/16

Then with a (likely too heavy handed) prune and rm:

docker system prune&&docker volume prune
docker image rm medicmobile/nginx-local-ip

I'm good to go then! Here's after:

docker network inspect $(docker network ls | awk '$3 == "bridge" { print $1}') | jq -r '.[] | .Name + " " + .IPAM.Config[0].Subnet' -
nginx-local-ip_default 172.16.0.0/16