I'm +0 on removing the parameter. I do think we want to have a parameter for allowing purge from a specific set of IPs. This parameter can be set at 127.0.0.1 and/or ::1 if a user wants to use local system authentication for that. It also could allow an implementation to use a local proxy on a high port that does authentication via some other mechanism. And if we're going to allow folks to configure it via a parameter, it might make the most sense to use the parameter we already have.
> If an attacker is on the server, you're already in trouble. Perhaps, but it might be a different kind of trouble. There are plenty of vulnerabilities that simply allow an attacker to make an HTTP request "through" a system, but don't provide a system account. Likewise, this could be used by an unprivileged local account to purge material they otherwise have no right to purge. System administrators are the ones in the best position to understand their security threat models and we should allow them to disable it entirely if the cost-benefit tradeoff isn't favourable for them. On Thu, Mar 11, 2021 at 10:31 AM Rawlin Peters <[email protected]> wrote: > > I agree w/ Rob for the reasons he mentioned. > > +1 on removing the parameter which was broken yet nobody noticed > -0 on adding a new parameter to enable the localhost PURGE rule > > - Rawlin > > On Thu, Mar 11, 2021 at 9:23 AM Robert O Butts <[email protected]> > wrote: > > > > +1 on removing the Parameter. We shouldn't normally remove things like this > > without a deprecation period, but we accidentally broke it in the last > > release and nobody noticed. So it seems kind of silly to fix something > > nobody noticed only to immediately deprecate/remove. > > > > Moreover, it's a pretty big security risk to be exposing PURGE externally. > > It's theoretically possible to only expose IPs you own, but it's very easy > > to accidentally expose more, and then you're vulnerable. I'm having a hard > > time imagining a scenario where someone couldn't use server automation > > (e.g. Ansible, Puppet) to run the Purge locally. > > > > -0.9 on a new param to disable/enable the localhost PURGE rule. If an > > attacker is on the server, you're already in trouble. It might be a tiny > > decrease in exposure to allow blocking it, in case an attacker is on the > > machine but doesn't have ats/root perms. But that seems pretty like a > > small, unlikely case to me. Unless anyone feels otherwise? Simpler to just > > have fixed rules allowing it on localhost and nowhere else, and no magic > > Parameters. > > > > > > On Wed, Mar 10, 2021 at 12:38 PM Souza, Dylan > > <[email protected]> wrote: > > > > > Hey all, > > > > > > We noticed recently that the parameter purge_allow_ip does not fully do > > > what is documented here: > > > > > > https://traffic-control-cdn.readthedocs.io/en/latest/overview/profiles_and_parameters.html?highlight=purge_allow_ip > > > - ip-allow-config< > > > https://traffic-control-cdn.readthedocs.io/en/latest/overview/profiles_and_parameters.html?highlight=purge_allow_ip#ip-allow-config > > > > > > > > > > The purge allow IP parameter is supposed to configure ATS to allow PURGE > > > requests over the specified addresses. This functionality works as > > > documented for the edge tier, but on the mid tier this falls apart because > > > atscfg prepends a PURGE/PUSH deny all rule to the very beginning of the > > > file. This leaves us with the inability to purge content at all on the mid > > > tier. > > > > > > I have opened up the following PR today to allow PURGE requests over > > > localhost on mids so that we can accomplish mid tier purges. This is meant > > > as a short term solution. > > > https://github.com/apache/trafficcontrol/pull/5619 > > > > > > Since today purge_allow_ip is only half working as documented, I would > > > like to propose that moving forward purge_allow_ip is depreciated entirely > > > and instead move to a model where PURGE is simply allowed over localhost > > > on > > > ATS. Perhaps we can add a parameter to disable that feature if we want > > > disallowing all PURGE requests to be configurable. > > > > > > Please let me know what you think! > > > > > > - Dylan Souza > > >
