proftp-docs Mailing List for ProFTPD Server Software (Page 3)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/pdd/www.proftpd.org/docs/howto
In directory sfp-cvsdas-2.v30.ch3.sourceforge.com:/tmp/cvs-serv6384

Modified Files:
	index.html 
Added Files:
	ConnectionACLs.html 
Log Message:

Adding ConnectionACL howto to website.

--- NEW FILE ---
<!-- $Id: ConnectionACLs.html,v 1.1 2011/01/05 19:14:22 castaglia Exp $ -->
<!-- $Source: /cvsroot/pdd/www.proftpd.org/docs/howto/ConnectionACLs.html,v $ -->

<html>
<head>
<title>ProFTPD mini-HOWTO - Connection ACLs</title>
</head>

<body bgcolor=white>

<hr>
<center><h2><b>Connection ACLs</b></h2></center>
<hr>

Many sites running <code>proftpd</code> have the need to limit/reject
connections from known bad addresses, or to accept connections only from
known good addresses. ProFTPD supports several different mechanisms for
implementing FTP connection ACLs.

However, there is one important thing to note: ProFTPD is not a firewall.
Never forget this. You cannot prevent TCP connections from ever
reaching <code>proftpd</code> in the first place by using <code>proftpd</code>
itself. This means that for many sites with connection ACL needs, their
system's firewall capabilities may be a better mechanism for implementing ACLs.

<code>&lt;Limit LOGIN&gt;</code>, and Whitelists versus Blacklists 
The easiest way of accepting/rejecting connections is to use ProFTPD's
<a href="Limit.html"><code>&lt;Limit&gt;</code></a> syntax, particularly
<code>&lt;Limit LOGIN&gt;</code>.

<p>
For example, you can simply reject all connections to your <code>proftpd</code>
instance by using:
<pre>
  &lt;Limit LOGIN&gt;
    DenyAll
  &lt;/Limit&gt;
</pre>
A more practical example would look like:
<pre>
  &lt;Limit LOGIN&gt;
    # These are trusted addresses
    Allow from 1.2.3.4 5.6.7.8
    Allow from trusted-domain.com

    # Everyone else is denied
    DenyAll
  &lt;/Limit&gt;
</pre>

<p>
The above configuration demonstrates the concept of a <i>whitelist</i>: known
trusted (<i>i.e.</i> "white") addresses are explicitly listed and allowed, and
all others are denied.  Conversely, you might use a <i>blacklist</i>, where
known bad/malicious/untrusted (<i>i.e.</i> "black") addresses are explicitly
listed and denied, and all others are allowed:
<pre>
  &lt;Limit LOGIN&gt;
    Order deny,allow

    # These are known bad addresses
    Deny from 1.2.3.4 5.6.7.8
    Deny from evil-domain.com

    # Everyone else is allowed
    AllowAll
  &lt;/Limit&gt;
</pre>

It is useful to know about whitelists versus blacklists, as it can affect
how large your ACLs become. Sites which run publicly available FTP servers
but which need to weed out bad clients tend to use blacklists; over time,
these blacklists can become quite large. Sites which know who will be using
their FTP server and only want those people to be able to connect will use
whitelists; these whitelists tend to remain fairly small/short.

<p>
<b>Large Blacklists</b><br>
Let's assume that you are running a public FTP server, and that you are using
a <code>&lt;Limit LOGIN&gt;</code> section to make a blacklist.  Your site
may even have some script which detects bad clients, and automatically adds
them to your blacklist, <i>e.g.</i>:
<pre>
  &lt;Limit LOGIN&gt;
    Order deny,allow

    # -- Add blacklisted addresses here --
    Deny from ...
    Deny from ...
    # <b>Many</b> more <code>Deny from</code> lines

    # Allow everyone not explicitly blacklisted
    AllowAll
  &lt;/Limit&gt;
</pre>
Over time, your number of blacklisted IP addresses starts to become large
and unwieldy.  You might have thousands of such addresses; you notice that
<code>proftpd</code> starts acting strangely, and starts slowing down.

When this happens, you should start looking for ways to make your list shorter.
If your list is comprised of entries for each individual IP address, you
should think about using glob expressions and netmasks to reduce the number
of entries. For example, rather than using something like
this:
<pre>
 Deny from 1.2.3.4
 Deny from 1.2.3.5
 Deny from 1.2.3.6
 Deny from 1.2.3.7
 Deny from 1.2.3.8
 Deny from 1.2.3.9
</pre>
you could (as of <code>proftpd-1.3.4rc1</code> and later) use a range:
<pre>
 Deny 1.2.3.[4-9]
</pre>
or even use a glob wildcard such as this, which makes for even fewer entries
in your address lists:
<pre>
 Deny 1.2.3.*
</pre>
Or you could use netmasks such as:
<pre>
 Deny 1.2.3.0/8
</pre>

Using Classes 
Now let's assume that at this point you have used glob ranges and wildcards
and netmasks to make your ACL shorter, but it is still large, and
<code>proftpd</code> is still slow. It is time for you to use ProFTPD's
connection <a href="Classes.html">classes</a>.

<p>
To do this, you would rewrite your large <code>&lt;Limit LOGIN&gt;</code>
section to look something like this:
<pre>
  &lt;Class blacklist&gt;
    # Put all of your blacklisted address/range lines here, as <code>From</code> lines
    From ...
    From ...
    From ...
  &lt;/Class&gt;

  &lt;Limit LOGIN&gt;
    Order deny,allow

    # Rejected blacklisted clients
    DenyClass blacklist

    # Allow everyone else
    AllowAll
  &lt;/Limit&gt;
</pre>

Why does using classes like this make things faster? When using classes, the
label (i.e. the class name in the <code>&lt;Class&gt;</code> section,
like "blacklist" in the above example) is determined when the client
first connects to <code>proftpd</code>, before any comands are sent.
That is when all of the various netmasks and such are checked -- and
only at that time. After that, all of the configuration-based ACLs
are evaluated just using that label.

When you do not use classes, then proftpd scans each configuration, each
netmask/address for each command. That's why things slow down so
much.

Alternatives 
There are a couple of other ways in which to implement connection ACLs; these
alternatives may be more efficient and/or better suited to your site's needs.

You can use a module like
<a href="../contrib/mod_wrap2.html"><code>mod_wrap2</code></a>, particular its
support for storing ACLs in SQL tables. SQL lookups can be very quick, and
can easily support large numbers of addresses efficiently.

And if you find yourself starting to block large blocks of addresses from
countries/regions, you should start thinking about connection ACLs in terms of
geolocation information. For this, the<a href="http://www.castaglia.org/proftpd/modules/mod_geoip.html"><code>mod_geoip</code></a> module for proftpd is
quite useful.

<p><a name="FAQ">
<b>Frequently Asked Questions</b><br>

Question: Is there a limit to how many addresses can
appear in a single line in the config file? 
Answer: No. However, there is a maximum line
length, which is determined by the buffer size used by the configuration file
parser. That buffer size is usually 1024 bytes (1K).

<p>
This 1024 byte length limitation can be worked around, however, by breaking
a single line in the configuration file into multiple lines using the
line continuation syntax, <i>e.g.</i>:
<pre>
  Allow 1.2.3.4 5.6.7.8 9.10.11.12
<pre>
can also appear as:
<pre>
  Allow \
    1.2.3.4 \
    5.6.7.8 \
    9.10.11.12
</pre>

<p>
<hr>
Last Updated: <i>$Date: 2011/01/05 19:14:22 $</i><br>
<hr>

</body>
</html>

Index: index.html
===================================================================
RCS file: /cvsroot/pdd/www.proftpd.org/docs/howto/index.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -r1.7 -r1.8
*** index.html	11 Dec 2009 04:47:38 -0000	1.7
--- index.html	5 Jan 2011 19:14:22 -0000	1.8
***************
*** 72,80 ****

    <p>
-   <dt>On <a href="Upgrade.html">upgrading</a>
-   <dd>Covers the best way to perform an upgrade of ProFTPD
-   </dd>
- 
-   <p>
    <dt>On <a href="Vhost.html"><code>&lt;VirtualHost&gt;</code> sections</a>
    <dd>Covers how to configure virtual servers, listening on only one IP
--- 72,75 ----
***************
*** 91,94 ****
--- 86,101 ----

    <p>
+   <dt>On <a href="Directory.html"><code>&lt;Directory&gt;</code> sections</a>
+   <dd>Covers how <code>&lt;Directory&gt;</code> sections should be configured,
+       and how the configured paths are matched
+   </dd>
+ 
+   <p>
+   <dt>On <a href="Limit.html"><code>&lt;Limit&gt;</code> sections</a>
+   <dd>Covers how <code>&lt;Limit&gt;</code> sections should be configured,
+       and how different <code>&lt;Limit&gt;</code>s interact
+   </dd>
+ 
+   <p>
    <dt>On using <code>proftpd</code> in a <a href="NAT.html">firewall/NAT</a>
        environment</dt>
***************
*** 116,119 ****
--- 123,131 ----

    <p>
+   <dt>On <a href="Upgrade.html">upgrading</a>
+   <dd>Covers the best way to perform an upgrade of ProFTPD
+   </dd>
+ 
+   <p>
    <dt>On <a href="DSO.html">DSO modules</a>
    <dd>Covers what DSO modules are, and how to use them properly
***************
*** 121,124 ****
--- 133,142 ----

    <p>
+   <dt>On <a href="ConnectionACLs.html">connection ACLs</a>
+   <dd>Covers implementing connection ACLs, and some of the performance
+       concerns related to the different mechanisms
+   </dd>
+ 
+   <p>
    <dt>On <a href="ASCII.html">ASCII transfers</a>
    <dd>Covers ASCII mode for data transfers, and the affected FTP commands
***************
*** 137,152 ****

    <p>
-   <dt>On <a href="Directory.html"><code>&lt;Directory&gt;</code> sections</a>
-   <dd>Covers how <code>&lt;Directory&gt;</code> sections should be configured,
-       and how the configured paths are matched
-   </dd>
- 
-   <p>
-   <dt>On <a href="Limit.html"><code>&lt;Limit&gt;</code> sections</a>
-   <dd>Covers how <code>&lt;Limit&gt;</code> sections should be configured,
-       and how different <code>&lt;Limit&gt;</code>s interact
-   </dd>
- 
-   <p>
    <dt>On <a href="Sendfile.html">sendfile support</a>
    <dd>Describes what the <code>sendfile(2)</code> function does, and some
--- 155,158 ----

2002	Jan	Feb	Mar (16)	Apr (35)	May (37)	Jun (26)	Jul (24)	Aug (20)	Sep (33)	Oct (65)	Nov (19)	Dec (38)
2003	Jan (43)	Feb (20)	Mar (31)	Apr (17)	May (10)	Jun (2)	Jul (13)	Aug (13)	Sep (13)	Oct (22)	Nov (7)	Dec (8)
2004	Jan (11)	Feb (14)	Mar (11)	Apr (9)	May (11)	Jun (8)	Jul (8)	Aug (3)	Sep (11)	Oct (10)	Nov (4)	Dec (7)
2005	Jan (1)	Feb (5)	Mar (12)	Apr (9)	May (7)	Jun (56)	Jul (14)	Aug (3)	Sep (20)	Oct (8)	Nov (5)	Dec (4)
2006	Jan (4)	Feb (1)	Mar (31)	Apr (12)	May (10)	Jun (6)	Jul (3)	Aug (2)	Sep (3)	Oct (5)	Nov (5)	Dec (11)
2007	Jan (7)	Feb (2)	Mar (13)	Apr (2)	May (2)	Jun (2)	Jul (6)	Aug (10)	Sep (4)	Oct (14)	Nov (2)	Dec (3)
2008	Jan (2)	Feb	Mar (1)	Apr (4)	May	Jun (2)	Jul (3)	Aug (3)	Sep (5)	Oct (1)	Nov (3)	Dec (2)
2009	Jan (9)	Feb (13)	Mar (3)	Apr (11)	May (1)	Jun (3)	Jul (6)	Aug (2)	Sep (4)	Oct (9)	Nov (2)	Dec (11)
2010	Jan (27)	Feb (15)	Mar (3)	Apr (5)	May (1)	Jun (3)	Jul (3)	Aug (2)	Sep (6)	Oct (6)	Nov	Dec (11)
2011	Jan (6)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (3)	Oct	Nov (6)	Dec
2012	Jan (1)	Feb (1)	Mar (4)	Apr	May (3)	Jun (5)	Jul (7)	Aug (1)	Sep (3)	Oct (4)	Nov (1)	Dec (6)

proftp-docs Mailing List for ProFTPD Server Software (Page 3)

proftp-docs — List for documentation maintainers