Enhanced PHP File Manager

⬆️ Go Up (..)

📊 Server Information

Server:

nginx/1.28.0

System:

Linux 6.8.0-90-generic

PHP Version:

8.4.15

User:

alqudsvolunteers

Directory:

/home/alqudsvolunteers/rootlink/proc/thread-self/root/usr/share/doc/varnish/html/users-guide

Free Space:

80.21 GB

🔧 Quick Actions

✏️ Editing: run_security.html

<!DOCTYPE html>

<title>Security first &#8212; Varnish version 7.5.0 documentation</title>
    <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
    <link rel="stylesheet" type="text/css" href="../_static/classic.css?v=e2714048" />
    
    <script src="../_static/documentation_options.js?v=8214db13"></script>
    <script src="../_static/doctools.js?v=888ff710"></script>
    <script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
    
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="Required command line arguments" href="command-line.html" />
    <link rel="prev" title="Starting and running Varnish" href="running.html" /> 
  </head><body>
    <div class="related" role="navigation" aria-label="related navigation">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="../genindex.html" title="General Index"
             accesskey="I">index</a></li>
        <li class="right" >
          <a href="command-line.html" title="Required command line arguments"
             accesskey="N">next</a> |</li>
        <li class="right" >
          <a href="running.html" title="Starting and running Varnish"
             accesskey="P">previous</a> |</li>
        <li class="nav-item nav-item-0"><a href="../index.html">Varnish version 7.5.0 documentation</a> &#187;</li>
          <li class="nav-item nav-item-1"><a href="index.html" >The Varnish Users Guide</a> &#187;</li>
          <li class="nav-item nav-item-2"><a href="running.html" accesskey="U">Starting and running Varnish</a> &#187;</li>
        <li class="nav-item nav-item-this"><a href="">Security first</a></li> 
      </ul>
    </div>

<div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body" role="main">
            
  <section id="security-first">
<span id="run-security"></span><h1>Security first<a class="headerlink" href="#security-first" title="Link to this heading">¶</a></h1>
<p>If you are the only person involved in running Varnish, or if all
the people involved are trusted to the same degree, you can skip
this chapter. We have protected Varnish as well as we can from
anything which can come in through an HTTP socket.</p>
<p>If parts of your web infrastructure are outsourced or otherwise
partitioned along administrative lines, you need to think about
security.</p>
<p>Varnish provides four levels of authority, roughly related to
how and where control comes into Varnish:</p>
<blockquote>
<div><ul class="simple">
<li><p>The command line arguments,</p></li>
<li><p>The CLI interface,</p></li>
<li><p>VCL programs, and</p></li>
<li><p>HTTP requests.</p></li>
</ul>
</div></blockquote>
<section id="command-line-arguments">
<h2>Command line arguments<a class="headerlink" href="#command-line-arguments" title="Link to this heading">¶</a></h2>
<p>The top level security decisions is decided and defined when starting
Varnish in the form of command line arguments, we use this strategy
in order to make them invulnerable to subsequent manipulation.</p>
<p>The important decisions to make are:</p>
<ol class="arabic simple">
<li><p>Who should have access to the Command Line Interface?</p></li>
<li><p>Which parameters can they change?</p></li>
<li><p>Will inline-C code be allowed?</p></li>
<li><p>If/how VMODs will be restricted?</p></li>
<li><p>How child processes will be jailed?</p></li>
</ol>
<section id="cli-interface-access">
<h3>CLI interface access<a class="headerlink" href="#cli-interface-access" title="Link to this heading">¶</a></h3>
<p>The command line interface can be accessed in three ways.</p>
<p><a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> can be told to listen and offer CLI connections on
a TCP socket. You can bind the socket to pretty much anything the
kernel will accept:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">-</span><span class="n">T</span> <span class="mf">127.0.0.1</span><span class="p">:</span><span class="mi">631</span>
<span class="o">-</span><span class="n">T</span> <span class="n">localhost</span><span class="p">:</span><span class="mi">9999</span>
<span class="o">-</span><span class="n">T</span> <span class="mf">192.168.1.1</span><span class="p">:</span><span class="mi">34</span>
<span class="o">-</span><span class="n">T</span> <span class="s1">&#39;[fe80::1]:8082&#39;</span>
</pre></div>
</div>
<p>The default is <code class="docutils literal notranslate"><span class="pre">-T</span> <span class="pre">localhost:0</span></code> which will pick a random port
number, which <a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a> can learn from the shared memory.</p>
<p>By using a <code class="docutils literal notranslate"><span class="pre">localhost</span></code> address, you restrict CLI access to the local
machine.</p>
<p>You can also bind the CLI port to an IP address reachable across
the net, and let other machines connect directly.</p>
<p>This gives you no secrecy, i.e. the CLI commands will go across the
network as ASCII text with no encryption, but the <code class="docutils literal notranslate"><span class="pre">-S</span></code> / pre shared
key (<a class="reference internal" href="#psk">PSK</a>) authentication requires the remote end to know the shared
secret.</p>
<p>Alternatively you can bind the CLI port to a <code class="docutils literal notranslate"><span class="pre">localhost</span></code> address,
and give remote users access via a secure connection to the local
machine, using ssh/VPN or similar.</p>
<p>If you use <cite>ssh(1)</cite> you can restrict which commands each user can
execute to just <a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a>, or even use a wrapper scripts
around <a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a> to allow specific CLI commands.</p>
<p>It is also possible to configure <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> for “reverse
mode”, using the <code class="docutils literal notranslate"><span class="pre">-M</span></code> argument.  In that case <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a>
will attempt to open a TCP connection to the specified address, and
initiate a CLI connection to your central Varnish management facility.</p>
<p>The connection in this case is also without encryption, but
the remote end must still authenticate using <code class="docutils literal notranslate"><span class="pre">-S</span></code>/<a class="reference internal" href="#psk">PSK</a>.</p>
<p>Finally, if you run varnishd with the <code class="docutils literal notranslate"><span class="pre">-d</span></code> option, you get a CLI
command on stdin/stdout, but since you started the process, it would
be hard to prevent you getting CLI access, wouldn’t it ?</p>
</section>
<section id="cli-interface-authentication">
<span id="psk"></span><h3>CLI interface authentication<a class="headerlink" href="#cli-interface-authentication" title="Link to this heading">¶</a></h3>
<p>By default the CLI interface is protected with a simple, yet powerful
“Pre Shared Key” authentication method, which do not provide secrecy
(ie: The CLI commands and responses are not encrypted).</p>
<p>The way <code class="docutils literal notranslate"><span class="pre">-S</span></code>/PSK works is really simple: During startup a file is
created with a random content and the file is only accessible to the
user who started <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> (or the superuser).</p>
<p>To authenticate and use a CLI connection, you need to know the
contents of that file, in order to answer the cryptographic challenge
<a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> issues, see <a class="reference internal" href="../reference/cli_protocol.html#ref-psk-auth"><span class="std std-ref">Authentication CLI connections</span></a>.</p>
<p><a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a> uses all of this to restrict access, it will only
function, provided it can read the secret file.</p>
<p>If you want to allow other users, local or remote, to be able to
access CLI connections, you must create your own secret file and make
it possible for (only!) these users to read it.</p>
<p>A good way to create the secret file is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">dd</span> <span class="k">if</span><span class="o">=/</span><span class="n">dev</span><span class="o">/</span><span class="n">random</span> <span class="n">of</span><span class="o">=/</span><span class="n">etc</span><span class="o">/</span><span class="n">varnish_secret</span> <span class="n">count</span><span class="o">=</span><span class="mi">1</span>
</pre></div>
</div>
<p>When you start <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a>, you specify the filename with ‘-S’,
and it goes without saying that the <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> master process
needs to be able to read the file too.</p>
<p>You can change the contents of the secret file while
<a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> runs, it is read every time a CLI connection is
authenticated.</p>
<p>On the local system, <a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a> can retrieve the filename
from shared memory, but on remote systems, you need to give
<a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a> a copy of the secret file, with the -S argument.</p>
<p>If you want to disable <code class="docutils literal notranslate"><span class="pre">-S</span></code>/PSK authentication, use an <code class="docutils literal notranslate"><span class="pre">-S</span> <span class="pre">none</span></code>
argument to varnishd:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">varnishd</span> <span class="p">[</span><span class="o">...</span><span class="p">]</span> <span class="o">-</span><span class="n">S</span> <span class="n">none</span> <span class="p">[</span><span class="o">...</span><span class="p">]</span>
</pre></div>
</div>
</section>
<section id="parameters">
<h3>Parameters<a class="headerlink" href="#parameters" title="Link to this heading">¶</a></h3>
<p>Parameters can be set from the command line, and made “read-only”
(using ‘-r’) so they cannot subsequently be modified from the CLI
interface.</p>
<p>Pretty much any parameter can be used to totally mess up your
HTTP service, but a few can do more damage than others:</p>
<dl class="simple">
<dt><a class="reference internal" href="../reference/varnishd.html#ref-param-cc-command"><span class="std std-ref">cc_command</span></a></dt><dd><p>Execute arbitrary programs</p>
</dd>
<dt><a class="reference internal" href="../reference/varnishd.html#ref-param-vcc-allow-inline-c"><span class="std std-ref">vcc_allow_inline_c</span></a></dt><dd><p>Allow inline C in VCL, which would allow any C code from VCL
to be executed by Varnish.</p>
</dd>
</dl>
<p>Furthermore you may want to look at and lock down:</p>
<dl class="simple">
<dt><a class="reference internal" href="../reference/varnishd.html#ref-param-syslog-cli-traffic"><span class="std std-ref">syslog_cli_traffic</span></a></dt><dd><p>Log all CLI commands to <cite>syslog(8)</cite>, so you know what goes on.</p>
</dd>
<dt><a class="reference internal" href="../reference/varnishd.html#ref-param-vcc-unsafe-path"><span class="std std-ref">vcc_unsafe_path</span></a></dt><dd><p>Restrict VCL/VMODs to <a class="reference internal" href="../reference/varnishd.html#ref-param-vcl-path"><span class="std std-ref">vcl_path</span></a> and
<a class="reference internal" href="../reference/varnishd.html#ref-param-vmod-path"><span class="std std-ref">vmod_path</span></a></p>
</dd>
<dt><a class="reference internal" href="../reference/varnishd.html#ref-param-vmod-path"><span class="std std-ref">vmod_path</span></a></dt><dd><p>The directory (or colon separated list of directories) where
Varnish will look for modules. This could potentially be
used to load rogue modules into Varnish.</p>
</dd>
</dl>
</section>
</section>
<section id="the-cli-interface">
<h2>The CLI interface<a class="headerlink" href="#the-cli-interface" title="Link to this heading">¶</a></h2>
<p>The CLI interface in Varnish is very powerful, if you have
access to the CLI interface, you can do almost anything to
the Varnish process.</p>
<p>As described above, some of the damage can be limited by restricting
certain parameters, but that will only protect the local filesystem,
and operating system, it will not protect your HTTP service.</p>
<p>We do not currently have a way to restrict specific CLI commands to
specific CLI connections. One way to get such an effect is to “wrap”
all CLI access in pre-approved scripts which use <a class="reference internal" href="../reference/varnishadm.html#varnishadm-1"><span class="std std-ref">varnishadm</span></a>
to submit the sanitized CLI commands, and restrict a remote user to
only those scripts, for instance using sshd(8)’s configuration.</p>
</section>
<section id="vcl-programs">
<h2>VCL programs<a class="headerlink" href="#vcl-programs" title="Link to this heading">¶</a></h2>
<p>There are two “dangerous” mechanisms available in VCL code:  VMODs
and inline-C.</p>
<p>Both of these mechanisms allow execution of arbitrary code and will
thus allow a person to get access to the machine, with the
privileges of the child process.</p>
<p>If <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> is started as root/superuser, we sandbox the
child process, using whatever facilities are available on the
operating system, but if <a class="reference internal" href="../reference/varnishd.html#varnishd-1"><span class="std std-ref">varnishd</span></a> is not started as
root/superuser, this is not possible. No, don’t ask me why you have to
be superuser to lower the privilege of a child process…</p>
<p>Inline-C is disabled by default since Varnish version 4, so unless
you enable it, you don’t have to worry about it.</p>
<p>The parameters mentioned above can restrict the loading of VMODs to only
be loaded from a designated directory, restricting VCL wranglers to a
pre-approved subset of VMODs.</p>
<p>If you do that, we are confident that your local system cannot be compromised
from VCL code.</p>
</section>
<section id="http-requests">
<h2>HTTP requests<a class="headerlink" href="#http-requests" title="Link to this heading">¶</a></h2>
<p>We have gone to great lengths to make Varnish resistant to anything
coming in through the socket where HTTP requests are received, and
you should, generally speaking, not need to protect it any further.</p>
<p>The caveat is that since VCL is a programming language which lets you
decide exactly what to do with HTTP requests, you can also decide
to do stupid and potentially dangerous things with them, including opening yourself up
to various kinds of attacks and subversive activities.</p>
<p>If you have “administrative” HTTP requests, for instance PURGE
requests, we strongly recommend that you restrict them to trusted
IP numbers/nets using VCL’s <a class="reference internal" href="vcl-syntax.html#vcl-syntax-acl"><span class="std std-ref">Access control lists (ACLs)</span></a>.</p>
</section>
</section>

<div class="clearer"></div>
          </div>
        </div>
      </div>
      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
        <div class="sphinxsidebarwrapper">
  <div>
    <h3><a href="../index.html">Table of Contents</a></h3>
    <ul>
<li><a class="reference internal" href="#">Security first</a><ul>
<li><a class="reference internal" href="#command-line-arguments">Command line arguments</a><ul>
<li><a class="reference internal" href="#cli-interface-access">CLI interface access</a></li>
<li><a class="reference internal" href="#cli-interface-authentication">CLI interface authentication</a></li>
<li><a class="reference internal" href="#parameters">Parameters</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-cli-interface">The CLI interface</a></li>
<li><a class="reference internal" href="#vcl-programs">VCL programs</a></li>
<li><a class="reference internal" href="#http-requests">HTTP requests</a></li>
</ul>
</li>
</ul>

</div>
  <div>
    <h4>Previous topic</h4>
    <p class="topless"><a href="running.html"
                          title="previous chapter">Starting and running Varnish</a></p>
  </div>
  <div>
    <h4>Next topic</h4>
    <p class="topless"><a href="command-line.html"
                          title="next chapter">Required command line arguments</a></p>
  </div>
  <div role="note" aria-label="source link">
    <h3>This Page</h3>
    <ul class="this-page-menu">
      <li><a href="../_sources/users-guide/run_security.rst.txt"
            rel="nofollow">Show Source</a></li>
    </ul>
   </div>
<div id="searchbox" style="display: none" role="search">
  <h3 id="searchlabel">Quick search</h3>
    <div class="searchformwrapper">
    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>
    </div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
        </div>
      </div>
      <div class="clearer"></div>
    </div>
    <div class="related" role="navigation" aria-label="related navigation">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="../genindex.html" title="General Index"
             >index</a></li>
        <li class="right" >
          <a href="command-line.html" title="Required command line arguments"
             >next</a> |</li>
        <li class="right" >
          <a href="running.html" title="Starting and running Varnish"
             >previous</a> |</li>
        <li class="nav-item nav-item-0"><a href="../index.html">Varnish version 7.5.0 documentation</a> &#187;</li>
          <li class="nav-item nav-item-1"><a href="index.html" >The Varnish Users Guide</a> &#187;</li>
          <li class="nav-item nav-item-2"><a href="running.html" >Starting and running Varnish</a> &#187;</li>
        <li class="nav-item nav-item-this"><a href="">Security first</a></li> 
      </ul>
    </div>
    <div class="footer" role="contentinfo">
    &#169; Copyright 2010-2014, Varnish Software AS.
      Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.2.6.
    </div>
  </body>
</html>

❌ Cancel

🗂️ Enhanced PHP File Manager

📊 Server Information

🔧 Quick Actions

✏️ Editing: run_security.html

📤 Upload File

📁 Create Folder

📄 Create File

✏️ Rename Item

🗑️ Delete Confirmation