Hi,
I’m forced to setup very restrictive firewall on server that is using letsencrypt certificate. What IP addresses (or networks) should I ALLOW on OUTPUT chain to be able to obtain and renew certificates? Is 104.107.156.125 (acme-v01.api.letsencrypt.org) enough? Are there any plans for change? I can’t widely open outgoing traffic to 443/tcp because of security reasons.
Thank you in advance.
@worldowner, the acme-v01.api.letsencrypt.org server is the only server that you need to make an outbound connection to during the issuance process (if you’re using the TLS-SNI-01 or HTTP-01 challenge methods), but it’s hosted by Akamai, which has many different IP addresses for this service and chooses one for you based on your location. There is no guarantee from Akamai that the Akamai CDN server they route you to will always have a consistent IP address.
you should think about host based (DNS name) policies rather than IP based policy
As stated and as with many Software as a Service / Cloud Services there are not gurantees on IP ranges and if you are still using IP based filtering then you need to rethink your security toolkits
In the modern world of PaaS and Clouds IP based outbound filtering just doesn’t cut the mustard. Most PaaS providers will tell you the same
Andrei
Thanks, this is what I thought. Unfortunatelly I can’t allow just acme-v01.api.letsencrypt.org as it gets resolved when rule is being added.
I probably can use NFQUEUE and parse packets in userspace but this seems like a huge overkill.
Relaying on IP ranges is no longer trendy, okay, I get that, but what is best practice then? What repaces old method?
most modern firewalls use application based rules that are built on protocols (HTTP, HTTPS etc) and FDQN
for example a rule for Let's encrypt would be allow HTTPS to acme-v01.api.letsencrypt.org
Old rule syntax would be allow outbound connections to port 443 to IP xxx
as it gets resolved when rule is being added.
this is what we were discussing above as a software as service it can be served from any IP in the world
There are hacky ways of getting around this but I will let you figure it out (you can search this forum as IP white-listing has been discussed before. There is even a study I did of IP stability over a week).
You could potentially run something like this before running certbot commands but once again there is no gurantee that the same IP will be used.
Andrei
I can easly write some bash code that woud resolve acme-v01.api.letsencrypt.org, follow CNAMEs etc, I just don't want to. It is not a solution, it's ugly workaround.
I don't know anything like that for Linux (transparent proxy comes into my mind but it's not exactly what I'd prefer). Do you know a standard (like nfilter/iptables) firewall for Linux with such capabilities? I know l7-filter but it doesn't seem to be maintained and never had great publicity.
Do you have scriptable access to the firewall? I assume this isn’t a normal web server so you’re using the standalone mode for certbot, so you could just add a exception for HTTPS when certbot needs to renew, and remove it afterwards (Via the pre/post hooks)
i agree with you there about the script.
To be honest you are very right I did a quick google and couldn’t find anything
saying that I also should make you aware my background is working with firewalls (Palo Alto, Checkpoint) and loadbalancers. So layer7 based rules are no brainers for me however I now understand the linux firewalls dilema a bit more
Usually we stick a palto alto in front of all the linux servers so the IPtables are sufficient (as we are only whitelisting traffic to a static internal firewall IP).
Will do a bit more thinking
Andrei
Well, it is a normal webserver but with very strict security requirements.
In fact I can't do that. At least not this way. This is what I tried before posting here. Hooks are executed only if there is something to renew but certbot makes HTTPS connection even if there is nothing to renew. So, as a workaround, I can create a tiny wrapper that allows 443/tcp, executes certboot and revokes rule that it added before. This will work, but I can't call it state of the art and be proud of it 
Hooks are useful for restarting services but won't do the job for firewall.
i had another thought on this
i am not an expert on certbot internals but i believe you can lock it down to a PID that way you allow 443 outbound for that process and nothing else
@schoen - is this possible from certbots point of view (locking it down to a PID)
Andrei
I don't think that's a Certbot issue, but rather a firewall issue. However, there are --pre-hook and --post-hook options in Certbot to make it run an external script before and after it starts. Perhaps there could be a firewall-configuration script that it runs that includes a DNS lookup.
If you want to filter on layer 3, you use a packet filter.
If you want to filter on layer 7, you use an HTTP proxy.
Use the right tool for the job and this is a complete non-issue.
layer 7 has protocols outside of HTTP. communications to let’s encrypt is via HTTPS so you have to get SSL proxying involved which is a pain
Overall an application level firewall that has supports layer 4 to 7 is ideal as running to separate products can lead to other issues
I don’t think it’s a simple just use a proxy for this and a iptables for this
Andrei
It's not a general statement but in the context of this thread.
Please inform yourself about the basics. I assume you're talking about MitM'ing SSL, which is completely unnecessary in order to filter SSL by hostname going through a proxy.
If certbot supports using a proxy, then this is the way to go.
As others have said, I’m afraid there’s no way to accommodate this particular need. One possible better avenue: You can try using the DNS challenge to issue and renew certificates from another machine that is allowed to access the Internet, and then push the certificates to your web server by whatever method you use to perform updates and administer the server (presumably SSH).
We may also be better able to help you if you tell us why this web server has these particular requirements. Are they regulatory or imposed by your IT department? Is this an intranet host or an Internet-facing host?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.