data.coop
/
ansible
8
3
Fork 7
Code Issues 44 Pull Requests 7 Projects 1 Releases Wiki Activity

Firewall (UFW) #107

Merged
samsapti merged 3 commits from :main into main 2022-11-22 20:05:01 +00:00
Conversation 6 Commits 3 Files Changed 4 +28
samsapti commented 2022-11-10 20:51:07 +00:00
Owner
Copy Link

Add firewall setup using UFW

Add firewall setup using UFW
samsapti added 1 commit 2022-11-10 20:51:08 +00:00
samsapti added 1 commit 2022-11-10 21:03:56 +00:00
samsapti force-pushed main from 86589ad065 to 731b3f8877 2022-11-12 13:39:47 +00:00 Compare
samsapti force-pushed main from 731b3f8877 to fcfb13dcef 2022-11-12 13:53:24 +00:00 Compare
samsapti commented 2022-11-12 13:54:51 +00:00
Author
Owner
Copy Link

(rebased onto latest main)

(rebased onto latest main)
samsapti added the
Security Hardening
 label 2022-11-12 15:13:32 +00:00
samsapti force-pushed main from fcfb13dcef to d597a956ff 2022-11-12 18:42:14 +00:00 Compare
reynir reviewed 2022-11-13 10:49:39 +00:00
reynir left a comment
Owner
Copy Link

I have bad experience with using nftables and docker on the same host. Maybe ufw works better?

I have bad experience with using nftables and docker on the same host. Maybe ufw works better?
roles/ubuntu_base/tasks/firewall.yml
@ -0,0 +6,4 @@
- name: Allow necessary ports
community.general.ufw:
rule: allow
port: "{{ item }}"
reynir commented 2022-11-12 18:48:25 +00:00
Owner
Copy Link

Udp? Tcp? Both?

Udp? Tcp? Both?
samsapti commented 2022-11-13 13:07:16 +00:00
Author
Owner
Copy Link

Do any of the services need UDP? Otherwise I can set them all to allow TCP only.

Do any of the services need UDP? Otherwise I can set them all to allow TCP only.
reynir commented 2022-11-13 15:57:40 +00:00
Owner
Copy Link

I think we may need UDP to receive responses to DNS requests. Otherwise I don't think we use UDP. My question was also what protocol(s) this covers.

I think we may need UDP to receive responses to DNS requests. Otherwise I don't think we use UDP. My question was also what protocol(s) this covers.
samsapti commented 2022-11-13 16:50:58 +00:00
Author
Owner
Copy Link

Default is both.

Default is both.
samsapti commented 2022-11-13 17:02:46 +00:00
Author
Owner
Copy Link

I think we may need UDP to receive responses to DNS requests.

No, firewall is only for blocking incoming requests. Responses to outgoing requests are not affected.

> I think we may need UDP to receive responses to DNS requests. No, firewall is only for blocking incoming requests. Responses to outgoing requests are not affected.
reynir commented 2022-11-13 20:05:09 +00:00
Owner
Copy Link

Yes, but you need to listen for the response :-)

Yes, but you need to listen for the response :-)
samsapti commented 2022-11-13 20:51:18 +00:00
Author
Owner
Copy Link

Still, DNS requests work even if UFW blocks UDP, since it only blocks incoming requests. A DNS response is not a request ;)

Still, DNS requests work even if UFW blocks UDP, since it only blocks incoming _requests_. A DNS response is not a request ;)
reynir commented 2022-11-14 09:24:07 +00:00
Owner
Copy Link

Well, UDP is connectionless and doesn't know about requests and responses. The reply is sent to the sender on the sending port. It may be that the rule generated by ufw tracks the state and allows replies, but it is not immediately obvious from these invocations.

For other UDP uses it may not be desirable: for example, if the datagrams are metrics reports we don't expect a reply and it would be undesirable to allow incoming packets in that case.

Well, UDP is connectionless and doesn't know about requests and responses. The reply is sent to the sender on the sending port. It may be that the rule generated by ufw tracks the state and allows replies, but it is not immediately obvious from these invocations. For other UDP uses it may not be desirable: for example, if the datagrams are metrics reports we don't expect a reply and it would be undesirable to allow incoming packets in that case.
samsapti commented 2022-11-14 16:03:43 +00:00
Author
Owner
Copy Link

You're right, perhaps I wasn't clear enough. Yes, Iptables/Nftables (which is UFW's backend(s)) tracks the state, and thus allows replies. It will only block clients trying to connect to the denied port on the host, even if a service is listening on the port (but not in the case of Docker described below). Unless you deny outgoing traffic, DNS lookups will work fine.

Also, I've never had problems with UFW blocking DNS lookups with this configuration.

You're right, perhaps I wasn't clear enough. Yes, Iptables/Nftables (which is UFW's backend(s)) tracks the state, and thus allows replies. It will only block clients trying to connect to the denied port on the host, even if a service is listening on the port (but not in the case of Docker described below). Unless you deny outgoing traffic, DNS lookups will work fine. Also, I've never had problems with UFW blocking DNS lookups with this configuration.
samsapti commented 2022-11-15 19:42:54 +00:00
Author
Owner
Copy Link

I've changed it such that it only allows TCP on the specified ports.

I've changed it such that it only allows TCP on the specified ports.
samsapti marked this conversation as resolved
roles/ubuntu_base/tasks/firewall.yml Outdated
@ -0,0 +11,4 @@
- 22 # Gitea SSH
- 80 # HTTP
- 443 # HTTPS
- 389 # OpenLDAP
reynir commented 2022-11-12 18:55:21 +00:00
Owner
Copy Link

I'm not sure we actually want to expose ldap

I'm not sure we actually want to expose ldap
samsapti commented 2022-11-13 13:12:00 +00:00
Author
Owner
Copy Link

Why is that? Do we only need it to be reachable internally on the host? If so, we should then also prefix the ports with 127.0.0.1: in the container config. Or if the only thing that needs to communicate with it is phpldapadmin, it shouldn't expose ports at all since they're on the same Docker network. If that's the case, I can fix it in another PR.

Why is that? Do we only need it to be reachable internally on the host? If so, we should then also prefix the ports with `127.0.0.1:` in the container config. Or if the only thing that needs to communicate with it is `phpldapadmin`, it shouldn't expose ports at all since they're on the same Docker network. If that's the case, I can fix it in another PR.
reynir commented 2022-11-13 15:59:29 +00:00
Owner
Copy Link

Yes, I think it's only used internally. Whether we have configured things correctly to use internal networks is another question. I don't know all that much about LDAP, and especially regarding security considerations, but I think we probably don't want to expose it. Maybe @valberg has an opinion.

Yes, I think it's only used internally. Whether we have configured things correctly to use internal networks is another question. I don't know all that much about LDAP, and especially regarding security considerations, but I think we probably don't want to expose it. Maybe @valberg has an opinion.
samsapti marked this conversation as resolved
samsapti commented 2022-11-13 13:06:35 +00:00
Author
Owner
Copy Link

I have bad experience with using nftables and docker on the same host. Maybe ufw works better?

From my own experience, UFW works perfectly fine with Docker. Just be aware, that exposing container ports like 80:80 omits the firewall, so if you don't want it to do that you need to prefix it with localhost like so: 127.0.0.1:80:80.

> I have bad experience with using nftables and docker on the same host. Maybe ufw works better? From my own experience, UFW works perfectly fine with Docker. Just be aware, that exposing container ports like `80:80` omits the firewall, so if you don't want it to do that you need to prefix it with localhost like so: `127.0.0.1:80:80`.
reynir commented 2022-11-13 16:00:30 +00:00
Owner
Copy Link

What does "omits the firewall" mean?

If we can undo the change and won't lock ourselves out I think we should try it.

What does "omits the firewall" mean? If we can undo the change and won't lock ourselves out I think we should try it.
samsapti commented 2022-11-13 16:37:13 +00:00
Author
Owner
Copy Link

What does "omits the firewall" mean?

It means that if UFW denies port 80, but a Docker container exposes 80:80, it won't be blocked. This is due to Docker interacting with iptables/nftables directly (which is UFW's backend).

If we can undo the change and won't lock ourselves out I think we should try it.

That should be possible. We can also keep an SSH session open in another terminal while we test.

> What does "omits the firewall" mean? It means that if UFW denies port 80, but a Docker container exposes `80:80`, it won't be blocked. This is due to Docker interacting with iptables/nftables directly (which is UFW's backend). > If we can undo the change and won't lock ourselves out I think we should try it. That should be possible. We can also keep an SSH session open in another terminal while we test.
reynir commented 2022-11-13 16:44:28 +00:00
Owner
Copy Link

What does "omits the firewall" mean?

It means that if UFW denies port 80, but a Docker container exposes 80:80, it won't be blocked. This is due to Docker interacting with iptables/nftables directly (which is UFW's backend).

Ah, that's a little disappointing. Then we can't rely on the firewall rules alone to work :(

> > What does "omits the firewall" mean? > > It means that if UFW denies port 80, but a Docker container exposes `80:80`, it won't be blocked. This is due to Docker interacting with iptables/nftables directly (which is UFW's backend). Ah, that's a little disappointing. Then we can't rely on the firewall rules alone to work :(
samsapti commented 2022-11-13 16:52:08 +00:00
Author
Owner
Copy Link

Ah, that's a little disappointing. Then we can't rely on the firewall rules alone to work :(

Yes, unfortunately. But it still works in all other cases, so it's better than nothing.

> Ah, that's a little disappointing. Then we can't rely on the firewall rules alone to work :( Yes, unfortunately. But it still works in all other cases, so it's better than nothing.
samsapti added 1 commit 2022-11-15 19:42:25 +00:00
valberg approved these changes 2022-11-22 19:49:28 +00:00
samsapti merged commit d53c6d41dc into main 2022-11-22 20:05:01 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
valberg
Labels
Clear labels   
Blocked

Something is blocking progress

  
Existing Service

Issues/improvements regarding existing services

  
Infrastructure Issue

Infrastructure issue that needs investigation or time to fix

  
Refactor

Refactoring of files / file structure or other improvements

  
Security Hardening

Non-verified / non-critical security improvements

  
Security Issue

Urgent security issue that needs to be fixed ASAP

  
Service Idea

Ideas for new services

  
Service Removal

Removal of services for one reason or another

  
Upgrade service
No Label
Blocked
Existing Service
Infrastructure Issue
Refactor
Security Hardening
Security Issue
Service Idea
Service Removal
Upgrade service
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: data.coop/ansible#107
No description provided.
Delete Branch ":main"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?