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

UFW script locks you out of remote host access #303

Closed
ipartola opened this issue Sep 8, 2014 · 6 comments
Closed

UFW script locks you out of remote host access #303

ipartola opened this issue Sep 8, 2014 · 6 comments

Comments

@ipartola
Copy link

@ipartola ipartola commented Sep 8, 2014

Currently, roles/common/tasks/ufw.yml task Deny everything and enable UFW seems to enable the firewall too early on. This means that all connections will be dropped before the exception for ssh is made. This is very problematic when running ansible over SSH on a remote host. Ideally, the firewall should be enabled as the last step in this task.

@tilsammans
Copy link
Contributor

@tilsammans tilsammans commented Sep 8, 2014

I have not seen this problem, and I am using Ansible over SSH to a remote host.

@pyrho
Copy link

@pyrho pyrho commented Sep 9, 2014

Had the same issue on Debian 7. The issue is that the "Deny everything and enable UFW" step fails with "ERROR: problem running ufw-init" which AFAIK isn't an issue. I added "ignore_errors: yes" to this step and it fixes the issue.

@ariddell
Copy link
Contributor

@ariddell ariddell commented Sep 9, 2014

I've never encountered this problem although it does seem like the order in ufw.yml might be adjusted.

@Debugreality
Copy link

@Debugreality Debugreality commented Oct 16, 2014

I had the same issue and split up the deny everything and enable UFW into separate commands with enable after ssh rules. Seems to work, see config below:

- name: Deny everything
ufw: policy=deny

- name: Set firewall rule for DNS
ufw: rule=allow port=domain

- name: Set firewall rule for mosh
ufw: rule=allow port=60000:61000 proto=udp

- name: Set firewall rules for web traffic and SSH
ufw: rule=allow port={{ item }} proto=tcp
with_items:
- http
- https
- ssh

- name: Enable UFW
ufw: state=enabled

@ariddell
Copy link
Contributor

@ariddell ariddell commented Oct 16, 2014

Aren't the tests run against Debian 7? It's strange that the problem isn't more widespread.

@al3x al3x closed this Nov 2, 2014
apsanz pushed a commit to apsanz/sovereign that referenced this issue Nov 10, 2014
On fresh installs of Debian 7.6, the current order of steps will lock you
out of SSH. This will enable UFW after creating rules for http, https, ssh,
and DNS. Fix comes from @Debugreality in issue sovereign#303:

sovereign#303
apsanz added a commit to apsanz/sovereign that referenced this issue Nov 10, 2014
On fresh installs of Debian 7.6, the current order of steps will lock you
out of SSH. This will enable UFW after creating rules for http, https, ssh,
and DNS. Fix comes from @Debugreality in issue sovereign#303:

sovereign#303
apsanz added a commit to apsanz/empress that referenced this issue Nov 18, 2014
On fresh installs of Debian 7.6, the current order of steps will lock you
out of SSH. This will enable UFW after creating rules for http, https, ssh,
and DNS. Fix comes from @Debugreality in issue #303:

sovereign/sovereign#303
@shaneonabike
Copy link

@shaneonabike shaneonabike commented Feb 12, 2015

This hasnt been resolved for me and I was completely locked out of my server after the apache was attempted to be restarted

norbert pushed a commit to norbert/florin that referenced this issue Feb 18, 2015
On fresh installs of Debian 7.6, the current order of steps will lock you
out of SSH. This will enable UFW after creating rules for http, https, ssh,
and DNS. Fix comes from @Debugreality in issue #303:

sovereign/sovereign#303
adborden pushed a commit to adborden/sovereign2-common that referenced this issue Nov 3, 2019
On fresh installs of Debian 7.6, the current order of steps will lock you
out of SSH. This will enable UFW after creating rules for http, https, ssh,
and DNS. Fix comes from @Debugreality in issue #303:

sovereign/sovereign#303
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants