Firewall (UFW) #107
|
|
@ -9,6 +9,7 @@
|
|||
- apparmor
|
||||
- haveged
|
||||
- mosh
|
||||
- ufw
|
||||
- srvadmin-all # Dell OpenManage
|
||||
|
||||
- name: Install necessary packages via pip
|
||||
|
|
|
|||
20
roles/ubuntu_base/tasks/firewall.yml
Normal file
20
roles/ubuntu_base/tasks/firewall.yml
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
- name: Setup firewall with UFW
|
||||
community.general.ufw:
|
||||
state: enabled
|
||||
policy: deny
|
||||
- name: Allow necessary ports
|
||||
community.general.ufw:
|
||||
rule: allow
|
||||
port: "{{ item }}"
|
||||
|
samsapti marked this conversation as resolved
|
||||
loop:
|
||||
- 22 # Gitea SSH
|
||||
- 80 # HTTP
|
||||
- 443 # HTTPS
|
||||
- 389 # OpenLDAP
|
||||
|
samsapti marked this conversation as resolved
Outdated
reynir
commented
I'm not sure we actually want to expose ldap I'm not sure we actually want to expose ldap
samsapti
commented
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 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
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.
|
||||
- 636 # OpenLDAP
|
||||
- 25 # Email
|
||||
- 465 # Email
|
||||
- 587 # Email
|
||||
- 993 # Email
|
||||
- 19022 # SSH
|
||||
|
|
@ -7,4 +7,6 @@
|
|||
tags: [install-base-packages]
|
||||
- import_tasks: users.yml
|
||||
tags: [setup-users]
|
||||
- import_tasks: firewall.yml
|
||||
tags: [setup-firewall]
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue
Udp? Tcp? Both?
Do any of the services need UDP? Otherwise I can set them all to allow TCP only.
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.
Default is both.
No, firewall is only for blocking incoming requests. Responses to outgoing requests are not affected.
Yes, but you need to listen for the response :-)
Still, DNS requests work even if UFW blocks UDP, since it only blocks incoming requests. A DNS response is not a request ;)
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.
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.
I've changed it such that it only allows TCP on the specified ports.