You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Souza, Dylan" <Dy...@comcast.com.INVALID> on 2021/03/10 19:38:27 UTC
Propose purge_allow_ip removal
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
Re: Propose purge_allow_ip removal
Posted by Chris Lemmons <al...@gmail.com>.
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 <ra...@apache.org> 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 <ro...@gmail.com> 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
> > <Dy...@comcast.com.invalid> 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
> > >
Re: Propose purge_allow_ip removal
Posted by Rawlin Peters <ra...@apache.org>.
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 <ro...@gmail.com> 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
> <Dy...@comcast.com.invalid> 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
> >
Re: Propose purge_allow_ip removal
Posted by Robert O Butts <ro...@gmail.com>.
+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
<Dy...@comcast.com.invalid> 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
>