Gecko [ www.thearyasamaj.org ]

Name	Size	Permission
ASCII.html	3.71 KB	-rw-r--r--
AWS.html	26.05 KB	-rw-r--r--
AuthFiles.html	9.54 KB	-rw-r--r--
Authentication.html	15.32 KB	-rw-r--r--
BCP.html	13.7 KB	-rw-r--r--
Chroot.html	14.27 KB	-rw-r--r--
Classes.html	5.92 KB	-rw-r--r--
Compiling.html	34.11 KB	-rw-r--r--
ConfigFile.html	16.47 KB	-rw-r--r--
ConfigurationTricks.html	16.54 KB	-rw-r--r--
ConnectionACLs.html	6.84 KB	-rw-r--r--
Controls.html	11.95 KB	-rw-r--r--
CreateHome.html	7.79 KB	-rw-r--r--
DNS.html	6.92 KB	-rw-r--r--
DSO.html	14.9 KB	-rw-r--r--
Debugging.html	12.47 KB	-rw-r--r--
Directory.html	10.89 KB	-rw-r--r--
DisplayFiles.html	6.69 KB	-rw-r--r--
ECCN.html	4.73 KB	-rw-r--r--
FTP.html	16.09 KB	-rw-r--r--
FXP.html	5.57 KB	-rw-r--r--
Filters.html	7.93 KB	-rw-r--r--
Globbing.html	5.53 KB	-rw-r--r--
KeepAlives.html	19.68 KB	-rw-r--r--
Limit.html	15.08 KB	-rw-r--r--
ListOptions.html	6.18 KB	-rw-r--r--
LogLevels.html	5.08 KB	-rw-r--r--
LogMessages.html	14.89 KB	-rw-r--r--
Logging.html	22.37 KB	-rw-r--r--
Memcache.html	9.04 KB	-rw-r--r--
NAT.html	11.15 KB	-rw-r--r--
Nonroot.html	4.23 KB	-rw-r--r--
Quotas.html	17.17 KB	-rw-r--r--
Radius.html	17.35 KB	-rw-r--r--
Redis.html	8.53 KB	-rw-r--r--
Regex.html	22.23 KB	-rw-r--r--
Rewrite.html	16.8 KB	-rw-r--r--
SQL.html	40.55 KB	-rw-r--r--
SSH.html	5.14 KB	-rw-r--r--
Scoreboard.html	9.11 KB	-rw-r--r--
Sendfile.html	7.34 KB	-rw-r--r--
ServerType.html	10.45 KB	-rw-r--r--
Stopping.html	10.31 KB	-rw-r--r--
TLS.html	58.93 KB	-rw-r--r--
Testing.html	8.73 KB	-rw-r--r--
Timestamps.html	6.71 KB	-rw-r--r--
Tracing.html	8.68 KB	-rw-r--r--
Translations.html	3.52 KB	-rw-r--r--
Umask.html	9.16 KB	-rw-r--r--
Upgrade.html	2.14 KB	-rw-r--r--
Versioning.html	5.41 KB	-rw-r--r--
Vhost.html	11.55 KB	-rw-r--r--
VirtualUsers.html	8.8 KB	-rw-r--r--
ftpaccess.html	2.03 KB	-rw-r--r--
index.html	10.45 KB	-rw-r--r--

Code Editor : Filters.html

<!DOCTYPE html>
<html>
<head>
<title>ProFTPD: Filters</title>
</head>

<hr>
<center><h2>ProFTPD: Filters</h2></center>
<hr>

ProFTPD supports the ability to &quot;filter&quot; the FTP commands it receives
from the client. These filters are written as
<a href="Regex.html">regular expressions</a>. This means that while the
filters can be very powerful, they can also be complex and harder to construct.

First, there are the <a href="../modules/mod_core.html#AllowFilter"><code>AllowFilter</code></a> and <a href="../modules/mod_core.html#DenyFilter"><code>DenyFilter</code></a> configuration directives. These configuration directives are used
to set filters on every FTP command. If an <code>AllowFilter</code> is
used, the command parameters must match the given filter, otherwise the
command will be denied. If a <code>DenyFilter</code> is used, the command
parameters must not match the given filter, otherwise the command will
be denied. If both <code>AllowFilter</code> and <code>DenyFilter</code> are
used, then the <code>AllowFilter</code> will be checked first.

Second, there are some special filter configuration directives aimed at those
FTP commands that cause changes to files and directories on the server system: <a href="../modules/mod_core.html#PathAllowFilter"><code>PathAllowFilter</code></a> and <a href="../modules/mod_core.html#PathDenyFilter"><code>PathDenyFilter</code></a>. Like <code>AllowFilter</code> and <code>DenyFilter</code>, the
<code>Allow</code> filter, if present, is checked first, then a
<code>DenyFilter</code>, if present. <code>PathAllowFilter</code> and
<code>PathDenyFilter</code> are checked after the
<code>AllowFilter</code> and <code>DenyFilter</code> directives. These
<code>Path</code> filters are only applied to the following FTP commands:
<code>DELE</code>, <code>MKD/XMKD</code>, <code>RMD/XRMD</code>,
<code>RNFR</code>, <code>RNTO</code>, <code>STOR</code>, <code>STOU</code>,
and to the <code>SITE</code> commands <code>CHGRP</code> and <code>CHMOD</code>.
Note that using both <code>PathAllowFilter</code> and
<code>PathDenyFilter</code> at the same time is not a good idea; only one
filter is generally needed.

One property that often catches the unwary administrator is the fact that
<code>proftpd</code> only operates on the first <code>Filter</code> directive
defined in the configuration file; it does not cycle through multiple
<code>Filter</code> directives. This is because multiple regular expressions
can be combined into a single (albeit more complex) regular expression. The
alternation metacharacter is helpful in creating such combined regular
expressions. For example, if you had the following in your
<code>proftpd.conf</code>:
<pre>
 PathAllowFilter \.jpg$
 PathAllowFilter \.jpeg$
 PathAllowFilter \.mpeg$
 PathAllowFilter \.mpg$
 PathAllowFilter \.mp3$
</pre>
only the first <code>PathAllowFilter</code> would be enforced. To enforce
all Filter simultaneously, use:
<pre>
 PathAllowFilter \.(jpg|jpgeg|mpeg|mpg|mp3)$
</pre>
Matches are case-sensitive! Also note that if you surround your regular
expression in quotation (&quot;) marks, any backslash will itself need
to be escaped; ProFTPD's configuration parser interprets backslashes inside
of quoted strings a little differently. Thus, the example above would look
like this:
<pre>
 PathAllowFilter &quot;\\.(jpg|jpgeg|mpeg|mpg|mp3)$&quot;
</pre>
if using quotation marks.

Another characteristic to keep in mind is that Filters are only applied to
FTP command parameters, not to the FTP command itself. Most of the
time, this is not a problem. It would be useful sometimes, though, to
be able to filter parameters of commands other than those filtered by the
<code>Path</code> filter directives. It would be an easy change to the
source code; however, there is no feature request for the ability to do this
on <a href="http://bugs.proftpd.org">bugs.proftpd.org</a> with a good
justification for such a feature. If you can think of one, please open
such a request.

When developing your Filter directives, it often helps to keep an eye on the
server <a href="Debugging.html">debugging</a> output, to see how well your
filters are being applied.

Examples 
To prevent clients from using paths which may contain non-printable characters
(e.g. CR, LF, VB, etc), you can use the following
<code>PathDenyFilter</code> pattern:
<pre>
 PathDenyFilter [^[:print:]]
</pre>
Alternatively, you could use a <code>PathAllowFilter</code> which only
allows printable characters in paths:
<pre>
 PathAllowFilter [[:print:]]
</pre>
And if you want to prevent spaces and tabs from appearing in paths, you
can use:
<pre>
 PathDenyFilter [[:blank:]]
</pre>

What if you want to prevent clients from uploading so-called "dot files",
i.e. files whose names start with a period ('.'), so that they are
"hidden"? To prevent uploading of all dot files, you can use the following
<code>PathDenyFilter</code> configuration:
<pre>
 PathDenyFilter \.[^/]*$
</pre>

In ProFTPD 1.3.3rc1 and later, you can use the <code>AllowFilter</code> and
<code>DenyFilter</code> configuration directives inside of
<code>&lt;Limit&gt;</code> sections, so that those <code>Filter</code>
directives only apply to the FTP commands listed in the
<code>&lt;Limit&gt;</code> section. This means you can specify regular
expression filters for the arguments for specific commands. For example,
you may want to configure a directory that only allows uploads of files with
specific extensions. You could use <code>PathAllowFilter</code> for
this -- but <code>PathAllowFilter</code> also applies to the <code>MKD</code>
command, and you might want to allow users to create subdirectories in your
special directory. Thus you only want your regular expression to apply
to the <code>STOR</code> command in your directory. Below is an example
of how to do this using <code>AllowFilter</code>:
<pre>
 &lt;Directory /path/to/dir&gt;
 &lt;Limit STOR&gt;
 Order deny, allow
 AllowFilter \.ext$
 &lt;/Limit&gt;
 &lt;/Directory&gt;
</pre>
The key is the <code>Order</code> directive; without it, the configuration
will not work as you expect.

<a name="FAQ">
Frequently Asked Questions 
Question: How can I prevent <code>SITE CHMOD</code>
commands which use the mode 777, but allow other <code>SITE CHMOD</code>
commands? 
Answer: For this, you would use the
<code>DenyFilter</code> directive, like so:
<pre>
 &lt;Limit SITE_CHMOD&gt;
 DenyFilter 777
 &lt;/Limit&gt;
</pre>
However, the desired mode can also be expressed symbolically, using
e.g. "SITE CHMOD a+rwx file". So our filter should take this into
account, as well as some variants:
<pre>
 &lt;Limit SITE_CHMOD&gt;
 DenyFilter (777|a+rwx|u=rwx,g=rwx,o=rwx)
 &lt;/Limit&gt;
</pre>
Looking better, but still not perfect. A determined user could still work
around our filter by using a series of <code>SITE CHMOD</code> commands
like this:
<pre>
 SITE CHMOD u+rwx file
 SITE CHMOD g+rwx file
 SITE CHMOD o+rwx file
</pre>
Or the determined user could make the change even more granular:
<pre>
 SITE CHMOD u+r file
 SITE CHMOD u+w file
 SITE CHMOD u+x file
 SITE CHMOD g+r file
 SITE CHMOD g+w file
 SITE CHMOD g+x file
 SITE CHMOD o+r file
 SITE CHMOD o+w file
 SITE CHMOD o+x file
</pre>
Another trap is that the numbers "777" might appear in a legitimate file name,
and thus the following allowed command would fail unnecessarily:
<pre>
 SITE CHMOD 644 ServiceOrder777.doc
</pre>

In short, it is possible to create filters for portions of commands, but you
do need to be very careful to not inadvertently cause commands to fail that
should succeed.

</body>
</html>

${this.title}

Code Editor : Filters.html