NuFW - handbook22.html - NuFW Project Homepage

handbook22.html

Eric Leblond, 03/02/2010 01:35 am

 <html><!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=iso-8859-15"><!-- /Added by HTTrack -->
 <head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>NuFW Handbook</title><link rel="stylesheet" href="ck-style.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.71.0"><link rel="start" href="#id184845" title="NuFW Handbook"><link rel="next" href="#id259167" title="Chapter�1.�License"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id184845"></a>NuFW Handbook</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Eric</span> <span class="surname">Leblond</span></h3><code class="email">&lt;<a href="mailto:eric%20at%20inl%20dot%20fr">eric at inl dot fr</a>&gt;</code></div></div><div><div class="author"><h3 class="author"><span class="firstname">Vincent</span> <span class="surname">Deffontaines</span></h3><code class="email">&lt;<a href="mailto:gryzor%20at%20inl%20dot%20fr">gryzor at inl dot fr</a>&gt;</code></div></div><div><div class="author"><h3 class="author"><span class="firstname">Pierre</span> <span class="surname">Chifflier</span></h3><code class="email">&lt;<a href="mailto:chifflier%20at%20inl%20dot%20fr">chifflier at inl dot fr</a>&gt;</code></div></div><div><p class="copyright">Copyright � 2005-2008 INL</p></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="2"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.0.3</td><td align="left">2009/01/20</td></tr><tr><td align="left" colspan="2">
         <p>Added a short note about OCSP support.</p>
         </td></tr><tr><td align="left">Revision 1.0.2</td><td align="left">2008/12/10</td></tr><tr><td align="left" colspan="2">
         <p>Updated the nuauth_command description. Synchronized nuauth and nufw output with current version in debug section.</p>
         </td></tr><tr><td align="left">Revision 1.0.1</td><td align="left">2008/12/01</td></tr><tr><td align="left" colspan="2">
         <p>Updated the recommended setup section, fixed image inclusions. Added a version choosing section. Better documentation for nuauth's user session disconnection.</p>
         </td></tr><tr><td align="left">Revision 1.0.0</td><td align="left">2008/11/25</td></tr><tr><td align="left" colspan="2">
         <p>This handbook is based on the original howto document, and has been dramatically enhanced (countless changes).</p>
         </td></tr></table></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#id259167">1. License</a></span></dt><dt><span class="chapter"><a href="#id259190">2. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#id259195">Presentation</a></span></dt><dt><span class="section"><a href="#id259240">Architecture</a></span></dt><dt><span class="section"><a href="#id240455">Requirements</a></span></dt><dd><dl><dt><span class="section"><a href="#id240470">General</a></span></dt><dt><span class="section"><a href="#id240504">Nuauth dependencies</a></span></dt><dt><span class="section"><a href="#id240801">nufw dependencies</a></span></dt><dt><span class="section"><a href="#id240839">User marking requirement on old kernel</a></span></dt><dt><span class="section"><a href="#id283357">Using nfnetlink and getting all latest NuFW features</a></span></dt></dl></dd><dt><span class="section"><a href="#id283408">Recommended setup</a></span></dt><dt><span class="section"><a href="#id283713">How to choose your NuFW version</a></span></dt><dd><dl><dt><span class="section"><a href="#id283717">Installing</a></span></dt><dt><span class="section"><a href="#id283771">Upgrading</a></span></dt><dt><span class="section"><a href="#id283787">Finding out the installed version</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id283819">3. Compilation and installation</a></span></dt><dd><dl><dt><span class="section"><a href="#id283824">Default distribution kernels</a></span></dt><dt><span class="section"><a href="#id283861">Kernel preparation</a></span></dt><dt><span class="section"><a href="#id283906">Linux 2.6.14 and higher</a></span></dt><dt><span class="section"><a href="#id283924">NuFW compilation</a></span></dt><dt><span class="section"><a href="#id284015">Initial setup and tests</a></span></dt><dd><dl><dt><span class="section"><a href="#id284020">Certificates and client installation</a></span></dt><dt><span class="section"><a href="#id284046">Creating your own certificates</a></span></dt><dt><span class="section"><a href="#id284176">Basic nuauth setup</a></span></dt></dl></dd><dt><span class="section"><a href="#id284302">Testing</a></span></dt><dd><dl><dt><span class="section"><a href="#id284330">Setting up Netfilter rules before 2.6.14</a></span></dt><dt><span class="section"><a href="#id284353">Setting up Netfilter rules from 2.6.14</a></span></dt><dt><span class="section"><a href="#id284377">Testing the authentication system</a></span></dt><dt><span class="section"><a href="#id284467">Initial tests and debug process</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id284555">4. Setting up NuFW</a></span></dt><dd><dl><dt><span class="section"><a href="#LDAP_acls">Using the LDAP module for acl checking</a></span></dt><dd><dl><dt><span class="section"><a href="#id284673">Installation of OpenLDAP server (slapd)</a></span></dt><dt><span class="section"><a href="#id284696">Slapd configuration</a></span></dt><dt><span class="section"><a href="#id284772">nuauth configuration</a></span></dt><dt><span class="section"><a href="#id284800">Using nuface, a web-based rules generator</a></span></dt><dt><span class="section"><a href="#id284824">nuaclgen configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#id284892">Setting up NuFW authenticated connections tracking</a></span></dt><dd><dl><dt><span class="section"><a href="#id284897">nuauth settings</a></span></dt><dt><span class="section"><a href="#mysql_log">Installation of MySQL server</a></span></dt><dt><span class="section"><a href="#id284947">Installation of PostgreSQL server</a></span></dt><dt><span class="section"><a href="#id284997">SQL configuration</a></span></dt><dt><span class="section"><a href="#id285053">Life of a connection in the SQL table</a></span></dt><dt><span class="section"><a href="#id285120">Netfilter settings</a></span></dt><dt><span class="section"><a href="#id285234">Using the connection tracking</a></span></dt></dl></dd><dt><span class="section"><a href="#id285280">Single Sign On setup</a></span></dt><dd><dl><dt><span class="section"><a href="#id285284">Apache</a></span></dt><dt><span class="section"><a href="#id285300">Squid</a></span></dt><dt><span class="section"><a href="#id285316">Troubleshooting single sign on problems</a></span></dt></dl></dd><dt><span class="section"><a href="#id285406">User based Quality of Service</a></span></dt><dd><dl><dt><span class="section"><a href="#id285411">Setting up Kernel on non libnetfilter_queue system</a></span></dt><dt><span class="section"><a href="#id285438">Setting up nufw</a></span></dt><dt><span class="section"><a href="#id285454">Setting up Netfilter</a></span></dt><dt><span class="section"><a href="#id285484">Using marking modules</a></span></dt><dt><span class="section"><a href="#id285510">Using NuFW mark</a></span></dt></dl></dd><dt><span class="section"><a href="#id285556">Controlling nuauth finely at runtime</a></span></dt><dt><span class="section"><a href="#id285744">Time-based ACLs</a></span></dt><dd><dl><dt><span class="section"><a href="#id285749">Global configuration</a></span></dt><dt><span class="section"><a href="#id285793">XML period definition module</a></span></dt></dl></dd><dt><span class="section"><a href="#id285879">Chaining modules in nuauth</a></span></dt><dd><dl><dt><span class="section"><a href="#id285883">Syntax description</a></span></dt><dt><span class="section"><a href="#id285926">Some examples</a></span></dt></dl></dd><dt><span class="section"><a href="#hardening">Hardening NuFW</a></span></dt><dd><dl><dt><span class="section"><a href="#id285976">Nufw certificate verification</a></span></dt><dt><span class="section"><a href="#id286172">Authentication server (nuauth)</a></span></dt><dt><span class="section"><a href="#id286346">User authentication restrictions</a></span></dt><dt><span class="section"><a href="#id286379">On client side</a></span></dt><dt><span class="section"><a href="#id286566">Certificate authentication</a></span></dt><dt><span class="section"><a href="#id286606">Using secure LDAP (LDAPs) for ACLs checking</a></span></dt><dt><span class="section"><a href="#id286701">OS and application filtering</a></span></dt><dt><span class="section"><a href="#id286719">Intrusion Detection System (IDS)</a></span></dt></dl></dd><dt><span class="section"><a href="#nuauth_auth">Nuauth authentication configurations</a></span></dt><dd><dl><dt><span class="section"><a href="#id286785">PAM/LDAP authentication with Nuauth</a></span></dt><dt><span class="section"><a href="#id286868">PAM/Winbind authentication with Nuauth</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id286972">5. Authentication Agents</a></span></dt><dd><dl><dt><span class="section"><a href="#id286977">Supported OSes</a></span></dt><dd><dl><dt><span class="section"><a href="#id286982">Windows</a></span></dt><dt><span class="section"><a href="#id287005">Linux</a></span></dt><dt><span class="section"><a href="#id287036">MacOS</a></span></dt><dt><span class="section"><a href="#id287046">UNIX and BSD systems</a></span></dt></dl></dd><dt><span class="section"><a href="#id287058">pam_nufw</a></span></dt><dd><dl><dt><span class="section"><a href="#id287085">Options</a></span></dt><dt><span class="section"><a href="#id287166">Configuration file example</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id287254">6. Miscellaneous</a></span></dt><dd><dl><dt><span class="section"><a href="#id287258">Supported protocols</a></span></dt><dt><span class="section"><a href="#id287309">Big endian architectures</a></span></dt><dt><span class="section"><a href="#id287319">System with glibc 2.3.2</a></span></dt><dt><span class="section"><a href="#id287332">Linux distributions specific</a></span></dt><dt><span class="section"><a href="#id287348">Debian specific</a></span></dt><dt><span class="section"><a href="#id287368">Mandrake specific</a></span></dt><dt><span class="section"><a href="#id287377">Suse specific</a></span></dt><dt><span class="section"><a href="#id287387">Redhat specific</a></span></dt><dd><dl><dt><span class="section"><a href="#id287392">RedHat Enterprise Linux 4</a></span></dt></dl></dd><dt><span class="section"><a href="#id287403">Known issues</a></span></dt><dd><dl><dt><span class="section"><a href="#id287408">Problem with ip_queue on kernel prior to 2.6.12</a></span></dt><dt><span class="section"><a href="#id287420">Running NuFW in a bridged network</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id287450">7. Appendix</a></span></dt><dd><dl><dt><span class="section"><a href="#FinerTLS">Managing finer TLS settings with NuFW</a></span></dt></dl></dd><dt><span class="glossary"><a href="#id288119">Glossary</a></span></dt></dl></div><div class="list-of-figures"><p><b>List of Figures</b></p><dl><dt>2.1. <a href="#id259267">NuFW Algorithm resume</a></dt><dt>2.2. <a href="#id283441">A Nulog screenshot</a></dt><dt>2.3. <a href="#id283504">A NuFace screenshot</a></dt></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>7.1. <a href="#nufw-tls">nufw daemon (command line) TLS options resume</a></dt><dt>7.2. <a href="#nuauth-tls">nuauth daemon configuration TLS options resume</a></dt><dt>7.3. <a href="#nutcpc-tls">nutcpc command line TLS options resume</a></dt><dt>7.4. <a href="#nuclient-tls">nuclient.conf TLS options resume</a></dt></dl></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id259167"></a>Chapter�1.�License</h2></div></div></div><p>
   This document is copyrighted by INL, and distributed under the Creative Commons <span><strong class="command">by-nc-sa</strong></span> license. The full text of the license is available at  <a href="http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode" target="_top">http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode</a>.
   </p></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id259190"></a>Chapter�2.�Introduction</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id259195">Presentation</a></span></dt><dt><span class="section"><a href="#id259240">Architecture</a></span></dt><dt><span class="section"><a href="#id240455">Requirements</a></span></dt><dd><dl><dt><span class="section"><a href="#id240470">General</a></span></dt><dt><span class="section"><a href="#id240504">Nuauth dependencies</a></span></dt><dt><span class="section"><a href="#id240801">nufw dependencies</a></span></dt><dt><span class="section"><a href="#id240839">User marking requirement on old kernel</a></span></dt><dt><span class="section"><a href="#id283357">Using nfnetlink and getting all latest NuFW features</a></span></dt></dl></dd><dt><span class="section"><a href="#id283408">Recommended setup</a></span></dt><dt><span class="section"><a href="#id283713">How to choose your NuFW version</a></span></dt><dd><dl><dt><span class="section"><a href="#id283717">Installing</a></span></dt><dt><span class="section"><a href="#id283771">Upgrading</a></span></dt><dt><span class="section"><a href="#id283787">Finding out the installed version</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id259195"></a>Presentation</h2></div></div></div><p>
 NuFW is an enterprise grade firewall that performs an authentication of every single connection passing through the IP filter, by transparently requesting user's credentials before any filtering decision is taken. Practically, this means security policies can integrate with the user directory, and bring the notion of user ID down to the IP layers.
 NuFW lays on Netfilter, the state of the art IP filtering layer from the Linux kernel. It fully integrates with Netfilter and extends its capabilities.
 The daemons currently run on Linux and software clients are available for Windows, Linux, FreeBSD et Mac OSX.
 </p><p>
 NuFW can:
 </p><div class="itemizedlist"><ul type="disc"><li><p>
 Authenticate any connection that goes through your gateway or only from/to a chosen subset or a specific protocol (iptables is used to select the connections to authenticate).</p></li><li><p>Perform accounting, routing and quality of service based on users and not simply on IP.</p></li><li><p> Filter packets with criteria such as application and OS used by remote users.</p></li><li><p> Be the key of a secure and simple Single Sign On system.</p></li></ul></div><p>
 </p><p>
 NuFW is composed of two daemons that can be put on different systems and the
 main daemon nuauth is heavily multi-threaded.  nuauth uses loadable modules to
 add features, like SQL logging, reporting alert to IDS using Prelude, etc.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id259240"></a>Architecture</h2></div></div></div><p>
     NuFW has very little needs in terms of architecture. It is a firewall, so it needs to be installed between the client and the server, concerning connections the admin wills to authenticate. In other words, if you look at the figure below, the requisite is that the firewall running NuFW is set between the client host (M) and the server (T). It doesn't matter whether you administrate the server (T) or whether it is a random host on the internet : NuFW authentication occurs at the time the firewall decision is taken for each connection.</p><p>
     A very typical setup is to use NuFW on a central firewall, so that it can filter connections from LAN to DMZ, from LAN to Internet, from WAN to LAN, etc. Of course, this is no requisite and you can always chain NuFW with another implementation. Technically, NuFW has one requisite : no NAT should be applied on connections between the client and NuFW itself. If that occurs, NuFW authentication will not work. This can easily be turned around if you want to identify your users from the Internet, by setting up a VPN (road-warrior or network to network) tunnel.
     </p><p>
     A typical architecture is as follows :
     </p><div class="figure"><a name="id259267"></a><p class="title"><b>Figure�2.1.�NuFW Algorithm resume</b></p><div class="figure-contents"><img src="algorythm.png" alt="NuFW Algorithm resume"></div></div><p><br class="figure-break">
     </p><div class="orderedlist"><ol type="1"><li><p>A standard application sends a packet.</p></li><li><p>The Nufw server queues the packet and sends an auth request packet to the Nuauth server.</p></li><li><p>The Nuauth server sends to all nufw agents running on the client computer an authentication request.</p></li><li><p>The Nufw client run by the user whose application sent traffic sees that a connection is being initiated and sends a user request packet. The Nuauth server sums the auth request and the user request packet and checks this against an authentication authority.</p></li><li><p>The Nuauth server replies to the Nufw server accordingly.</p></li><li><p>The Nufw server transmits the packet following the answer given to its request.</p></li><li><p>The flow of the connection is handled by Netfilter's state table (the conntrack), like for any firewalling rule.</p></li></ol></div><p>
     </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id240455"></a>Requirements</h2></div></div></div><p>In this section, each invoked library will have to be installed and the
 header files have to be in standard places (so <span><strong class="command">./configure</strong></span> can
                 find them).
 </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id240470"></a>General</h3></div></div></div><p>NuFW is an advanced network filtering solution. For logging, as well as for domain integrations, it is highly recommended that all servers hosting NuFW services (<span><strong class="command">nufw</strong></span>, <span><strong class="command">nuauth</strong></span>, <span><strong class="command">LDAP/Active Directory</strong></span>, and <span><strong class="command">the logging server (SQLi/syslog/prelude)</strong></span>) be time-synchronized with a protocol such as NTP. NuFW does not provide time synchronization per se.
       </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id240504"></a>Nuauth dependencies</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id240509"></a>nuauth core daemon</h4></div></div></div><p>
 nuauth dependencies are as follows:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="filename">libglib2.0</code>: nuauth heavily uses this library which provides a set of very useful high level objects. It needs at least 2.4 release.</p></li><li><p><code class="filename">libgnutls</code>: communications between components are encrypted using TLS v1</p></li><li><p><code class="filename">libsasl2</code>: authentication is done via sasl</p></li><li><p><code class="filename">libtool</code>: It's needed for the compilation of library and modules</p></li></ul></div><p>
         </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Be careful when choosing your GnuTLS version : old versions may contain security breaches. Check the <a href="http://www.gnu.org/software/gnutls/security.html" target="_top">GnuTLS security advisories page</a> or make sure your distribution is reactive enough with updates.</p></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id240704"></a>MySQL logging</h4></div></div></div><p>
 The <code class="filename">libmysqlclient</code> library is required for compiling of this module.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id240719"></a>PostgreSQL logging</h4></div></div></div><p>
 The <code class="filename">libpq</code> library is required for compiling this module.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id240735"></a>Prelude IDS alerts</h4></div></div></div><p>
 The <code class="filename">libprelude</code> library is required for compiling this module.
 Prelude allows for gathering security events at the scale of any organization, and NuFW can send Prelude the following events :
 </p><div class="itemizedlist"><ul type="disc"><li><p>User authentication failures</p></li><li><p>User authentication successes</p></li><li><p>Start and end of user sessions</p></li><li><p>Start and end of authenticated connections</p></li><li><p>Rejected connections</p></li></ul></div><p>
 NuFW is a native sensor for Prelude, allowing tight integration with any IDS based the IDMEF standard (RFC 4765).
 All information about the Prelude project is available at <a href="http://prelude-ids.org/" target="_top">http://prelude-ids.org</a>
         </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id240785"></a>LDAP authentication and acl check</h4></div></div></div><p>
 <code class="filename">libldap</code> library is needed (version 2 or better).
 </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id240801"></a>nufw dependencies</h3></div></div></div><p>The nufw daemon only depends on:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="filename">iptables</code>: <code class="filename">libipq.a</code> is necessary to compile the nufw server</p></li><li><p><code class="filename">libgnutls</code>: nufw is connected to nuauth using a TLS encrypted channel</p></li></ul></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id240839"></a>User marking requirement on old kernel</h3></div></div></div><p>
 A system with a kernel prior to 2.6.14 needs a patched version of the ip_queue module and of
 its "sibling" library libipq.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id283357"></a>Using nfnetlink and getting all latest NuFW features</h3></div></div></div><p>
 On kernel superior to 2.6.14, ipq is now deprecated in favor of libnetfilter_queue which
 uses the new nfnetlink system.
 On top of that nfnetlink also provides libnetfilter_conntrack which is used by NuFW to implement
 connection tracking, and strict time-based acls.
         </p><p>To use this features, the following libraries are needed:
         </p><div class="itemizedlist"><ul type="disc"><li><p>libnfnetlink</p></li><li><p>libnetfilter_queue</p></li><li><p>libnetfilter_conntrack</p></li></ul></div><p>
         You can find working versions of these libraries at <a href="http://nufw.org/download/libs/index.html" target="_top">http://nufw.org/download/libs/index.html</a>
         Debian packages are available at <a href="http://www.nufw.org/debian/" target="_top">http://www.nufw.org/debian/</a>
         </p><p>
 If you plan to use NuFW time-based acls, it is best to use a kernel superior to 2.6.18 or
 to apply patches provided on NuFW site.
         </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283408"></a>Recommended setup</h2></div></div></div><p>
     This section's aim is to provide the best practises to help admins start a NuFW installation.
     We recommend that you use :
     </p><div class="itemizedlist"><ul type="disc"><li><p>A MySQL database for logs. Though nuauth as well as single sign on modules support PostgreSQL logging, NuLog PostgreSQL support should be considered experimental for now.</p></li><li><p>A <span><strong class="command">NuLog</strong></span> installation. This is not a formal requisite for setting up and using NuFW, but <a href="http://software.inl.fr/trac/wiki/EdenWall/NuLog" target="_top">NuLog</a> is a great tool to keep track of what is going on on your firewall. It analyses data from a ulog SQL database.
     </p><div class="figure"><a name="id283441"></a><p class="title"><b>Figure�2.2.�A Nulog screenshot</b></p><div class="figure-contents"><img src="nulog_scr.png" alt="A Nulog screenshot"></div></div><p><br class="figure-break">
      </p></li><li><p>A <span><strong class="command">NuFace</strong></span> installation. <a href="http://software.inl.fr/trac/wiki/EdenWall/NuFace" target="_top">NuFace</a> is INL's tool to build consistent <span><strong class="command">Netfilter</strong></span> + <span><strong class="command">nuauth</strong></span> rules. You really should consider using <span><strong class="command">NuFace</strong></span> unless you plan to write your own tool : dealing with filtering rules by hand can be tricky because you need to synchronise authenticating rules at <span><strong class="command">Netfilter</strong></span> and <span><strong class="command">nuauth</strong></span> levels.
     </p><div class="figure"><a name="id283504"></a><p class="title"><b>Figure�2.3.�A NuFace screenshot</b></p><div class="figure-contents"><img src="nuface_scr.png" alt="A NuFace screenshot"></div></div><p><br class="figure-break">
      </p></li><li><p>A <a href="http://www.netfilter.org/projects/ulogd/index.html" target="_top">ulogd</a> daemon setup for Netfilter logging. Ulogd can log Netfilter flows into the same database as nuauth, in order to provide a consistent log for both authenticated and unauthenticated connections. For now we recommend you use ulogd in version 1.X. Ulogd should run on the same host as your <code class="computeroutput">nufw</code> daemon, and log in the same MySQL database as nuauth. The <a href="#mysql_log" title="Installation of MySQL server">Installation of MySQL server</a> section describes a MySQL installation.</p></li><li><p>A user directory, supported by PAM. This means Active Directory, LDAP, Novell e-directory, and other directories are supported. This is actually a PAM matter, see section <a href="#nuauth_auth" title="Nuauth authentication configurations">Nuauth authentication configurations</a> for details. A plaintext nuauth module exists for user authentication, but it should be used for quick testing only. We really advise you have nuauth lay on a user directory. For instance, adding/removing users from the plaintext file requires that you restart nuauth, while those changes are transparent if nuauth uses the <code class="computeroutput">system</code> module.</p></li><li><p>A LDAP (local) directory, to store nuauth ACLs. Again, user authentication can be setup on a plaintext file, but this means you will need to handle it by hand, with a text editor, and warranty that your nuauth rules are consistent with Netfilter rules. On the other hand, <a href="http://software.inl.fr/trac/wiki/EdenWall/NuFace" target="_top">Nuface</a> can deal with both Netfilter and LDAP rules. Again, nuauth will need to be restarted if you make changes in the plaintext file, while the LDAP changes will apply on the fly. The LDAP ACL directory needs not formally be local, it can be hosted on any LDAP directory that <code class="computeroutput">nuauth</code> can reach. See the <a href="#LDAP_acls" title="Using the LDAP module for acl checking">Using the LDAP module for acl checking</a> section for details about how to setup your LDAP acl tree.</p></li></ul></div><p>
     </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283713"></a>How to choose your NuFW version</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id283717"></a>Installing</h3></div></div></div><p>If you are installing NuFW from scratch, it is advised that you use the latest stable version. You should avoid distribution packages if they distribute old versions, especially if security upgrades have been notified in latest versions. NuFW security announces are always available at <a href="http://nufw.org/-Security-announces-.html" target="_top">this URL</a>.
         </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Up to date Debian packages are distributed by INL, and can be used on your Debian systems by setting :
          </p><pre class="screen">
           deb http://packages.inl.fr/ testing/
          </pre><p>
          or
          </p><pre class="screen">
           deb http://packages.inl.fr/ stable/
          </pre><p>
          to your <code class="computeroutput">/etc/apt/sources.list</code> file. Also note that this URL makes the <code class="computeroutput">inl-keyring</code> package available, for package GPG signatures.
         </p></div><p>
        </p><p>Unless you are a developer or a very advanced user, we recommend that you do not attempt to use the trunk version of NuFW.
        </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id283771"></a>Upgrading</h3></div></div></div><p>You should upgrade your installation at least when security announces are released in new versions. Security announces are always available at <a href="http://nufw.org/-Security-announces-.html" target="_top">this URL</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id283787"></a>Finding out the installed version</h3></div></div></div><p>You can easily find out which version of the software you are using, with each NuFW component, by using the <code class="computeroutput">-V</code> switch with any program that we distribute :
         </p><pre class="screen">
 # nuauth -V
 nuauth (version 2.2.18 ($Revision: 5020 $))
 # nufw -V
 NuFW (version 2.2.19)
 # nutcpc -V
 nutcpc (version 2.2.19 $Revision: 5350 $)
         </pre><p>
         As an alternative, you can also use your distribution's package manager to find out, for instance :
         </p><pre class="screen">
 $ dpkg -l nutcpc
 [...]
 ii  nutcpc         2.2.19-1+inl1  The authentication firewall [client]
         </pre><p>
        </p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id283819"></a>Chapter�3.�Compilation and installation</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id283824">Default distribution kernels</a></span></dt><dt><span class="section"><a href="#id283861">Kernel preparation</a></span></dt><dt><span class="section"><a href="#id283906">Linux 2.6.14 and higher</a></span></dt><dt><span class="section"><a href="#id283924">NuFW compilation</a></span></dt><dt><span class="section"><a href="#id284015">Initial setup and tests</a></span></dt><dd><dl><dt><span class="section"><a href="#id284020">Certificates and client installation</a></span></dt><dt><span class="section"><a href="#id284046">Creating your own certificates</a></span></dt><dt><span class="section"><a href="#id284176">Basic nuauth setup</a></span></dt></dl></dd><dt><span class="section"><a href="#id284302">Testing</a></span></dt><dd><dl><dt><span class="section"><a href="#id284330">Setting up Netfilter rules before 2.6.14</a></span></dt><dt><span class="section"><a href="#id284353">Setting up Netfilter rules from 2.6.14</a></span></dt><dt><span class="section"><a href="#id284377">Testing the authentication system</a></span></dt><dt><span class="section"><a href="#id284467">Initial tests and debug process</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283824"></a>Default distribution kernels</h2></div></div></div><p>
       The following distributions do NOT need a kernel recompilation to run NuFW <sup>[<a name="id283832" href="#ftn.id283832">1</a>]</sup>:
       </p><div class="itemizedlist"><ul type="disc"><li><p>Fedora Core 6 (kernel 2.6.18)</p></li><li><p>Debian Etch (kernel 2.6.18)</p></li><li><p>Debian Lenny</p></li></ul></div><p>
       </p><p>
       Please note that a Linux kernel recompilation will only be needed on the Firewall itself (the host running the nufw daemon). The nuauth daemon should run on any POSIX system, and clients are, by essence, multi-platform (meaning, NO kernel dependency).</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283861"></a>Kernel preparation</h2></div></div></div><p>You only need to patch your kernel sources with patch-o-matic if you want to use userid marking (from Linux 2.6.14 there is no need to patch the kernel as this option is available in vanilla). This is necessary if you need to mark your network flows depending on the originating user ID, for instance, to perform per user Quality of Service. This is not needed to use NuFW. To do so, install patch-o-matic as usual and
       run </p><pre class="screen">$./runme ip_queue_vwmark</pre><p>Important note : it seems 2.6.24 netfilter_netlink capabilities only work if they are compiled as modules. Always compile these options as modules :
       </p><div class="itemizedlist"><ul type="disc"><li><p>CONFIG_NETFILTER_NETLINK</p></li><li><p>CONFIG_NETFILTER_NETLINK_QUEUE</p></li><li><p>CONFIG_NETFILTER_NETLINK_LOG</p></li><li><p>CONFIG_NF_CT_NETLINK</p></li></ul></div><p>
       Most distribution kernels come with these options compiled as modules.
       </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283906"></a>Linux 2.6.14 and higher</h2></div></div></div><p>
         If you run a kernel higher than 2.6.14 (and you should!), you should set the following options:
 </p><pre class="screen">
 CONFIG_NETFILTER_XT_TARGET_NFQUEUE=Y or m
 CONFIG_NETFILTER_NETLINK=Y or m
 CONFIG_IP_NF_CONNTRACK=m (we advise you don't set this option statically)
 CONFIG_IP_NF_CONNTRACK_EVENTS=Y
 </pre><p>
         Setting these options will allow you to use the NFQUEUE target, and use very simple Netfilter rules.
         </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id283924"></a>NuFW compilation</h2></div></div></div><p>Extract the source to the directory of your choice and
 go to the created directory.</p><p>
 NuFW uses autoconf and automake for compilation and a standard <span><strong class="command">configure</strong></span> script
 is provided.
 Above standard options, the following flags (among other) are provided:
 </p><div class="itemizedlist"><ul type="disc"><li><p> <code class="option">--with-mysql-log </code>   Support user activity logging in MySQL database</p></li><li><p> <code class="option">--with-pgsql-log </code>   Support user activity logging in PostgreSQL database</p></li><li><p> <code class="option">--with-system-auth </code>   Support PAM+NSS authentication</p></li><li><p> <code class="option">--with-ldap </code>   Support LDAP directory for users and acl lookups</p></li></ul></div><p>
 A detailed list of the options is available via
 </p><pre class="screen">$./configure --help</pre><p>
 Thus you can run <span><strong class="command">./configure</strong></span> with the options you want and launch compilation and installation:
 </p><pre class="screen">$ ./configure --with-ldap --with-system-auth --with-mysql-log \\
                 --sysconfdir=/etc/nufw/
 $ make
 $ sudo make install</pre><p>
 If you want to install default configuration files :
 </p><pre class="screen">sudo make install-conf</pre><p>
 This will only copy new configuration files when an old version of the file does not already exist in your <span><strong class="command">$prefix/conf</strong></span> directory
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id284015"></a>Initial setup and tests</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284020"></a>Certificates and client installation</h3></div></div></div><p>This is about copying the default certificates. Don't do that unless on very early tests ; you probably want to generate your own certificates: see next section.</p><p>For nufw
 </p><pre class="screen">cp conf/certs/nufw-*.pem /etc/nufw/</pre><p>
                 For nuauth:
 </p><pre class="screen">cp conf/certs/nuauth*.pem /etc/nufw/
 cp conf/certs/NuFW*.pem /etc/nufw/</pre><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284046"></a>Creating your own certificates</h3></div></div></div><p>The management of certificates, or the use of a Public Key Infrastructure (PKI), is
       not covered in this howto. Using a dedicated software, like
       <a href="http://www.openca.org/" target="_top">OpenCA</a> or
       <a href="http://ejbca.sourceforge.net/" target="_top">EBJCA</a>,
       is suggested.
       </p><p>See section <a href="#hardening" title="Hardening NuFW">Hardening NuFW</a> for details on how
       certificates are used in NuFW.
       </p><p>The following commands show how to quickly create a Certificate Authority, and some
       certificates for nufw and nuauth.
       </p><p>Generating your own Certificate authority:
       </p><pre class="screen">mkdir private
 chmod 700 private
 openssl req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem</pre><p>
 You have to set a strong password here and keep it secret.
       </p><p>Generating nufw and nuauth private keys:
       </p><pre class="screen">openssl genrsa -out private/nufw-key.pem</pre><p>
       </p><pre class="screen">openssl genrsa -out private/nuauth-key.pem</pre><p>
       </p><p>Generating Certificate Signing Requests for both nufw and nuauth
       keys:
       </p><pre class="screen">openssl req -new -key private/nufw-key.pem -out nufw.csr</pre><p>
       </p><pre class="screen">openssl req -new -key private/nuauth-key.pem -out nuauth.csr</pre><p>
       </p><p>Having our keys signed by the certificate authority we created:
       </p><pre class="screen">openssl x509 -req -days 365 -in nufw.csr -CA private/CAcert.pem \
       -CAkey private/CAkey.pem -CAcreateserial -out nufw-cert.pem</pre><p>
       </p><pre class="screen">openssl x509 -req -days 365 -in nuauth.csr -CA private/CAcert.pem \
       -CAkey private/CAkey.pem -CAcreateserial -out nuauth-cert.pem</pre><p>
       </p><p>Then, as in previous section, copy the files where needed:
       For nufw:
       </p><pre class="screen">cp private/nufw-key.pem /etc/nufw/</pre><p>
       </p><pre class="screen">cp nufw-cert.pem /etc/nufw/</pre><p>
       For nuauth:
       </p><pre class="screen">cp private/nuauth-key.pem /etc/nufw/</pre><p>
       </p><pre class="screen">cp nuauth-cert.pem /etc/nufw/</pre><p>
       And don't forget your key files (here, nufw-key.pem and nuauth-key.pem) should always remain private.
       </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284176"></a>Basic nuauth setup</h3></div></div></div><p>NuFW sources provide a sample configuration file for nuauth <code class="filename">nuauth.conf</code>
 which is available in the <code class="filename">conf</code> directory.
 </p><p>The two most important configuration variables are:
 <code class="option">nuauth_client_listen_addr</code> which sets the address
 where <span><strong class="command">nuauth</strong></span> listens for client requests and <code class="option">nuauth_nufw_listen_addr</code>
 which sets the address where <span><strong class="command">nuauth</strong></span> listens for nufw requests.
 The list of <span><strong class="command">nufw</strong></span> servers authorized to connect to server <span><strong class="command">nuauth</strong></span> is the
  <code class="varname">nufw_gw_addr</code>.</p><p>
 The next thing to do after setting this variable is to choose
 your authentication and acl checking module.
 Authentication modules for user have to be chosen in:
 </p><div class="itemizedlist"><ul type="disc"><li><p>plaintext: user credentials are stored in a text file. It is advised not to use this module, except for quick testing :
 you need to restart nuauth when updating the text file. Instead, on production, you should run the system module. This format supports both
 plaintext and encrypted passwords, see the sample config file (named <span><strong class="command">users-plaintext.nufw</strong></span>) for formatting and details.</p></li><li><p>system: authentication is done against PAM and groups are system groups. This provides
  a convenient way to use nss features and/or pam-modules. This is the recommended way, as it lets you
  authenticate against your LDAP, Active Directory, or any directory.</p></li></ul></div><p>
 This is set with the option <code class="option">nuauth_user_check_module</code>
 which default is <code class="varname">libsystem</code> (if not set in config file).
 Further choice for the acl checking  module has to be done if you choose:
 </p><div class="itemizedlist"><ul type="disc"><li><p>libldap : this is the recommended ACL checking module, as it is modular, and does not require a reload of the
 nuauth server when updating rules. You can manage iptables and LDAP rules in a consistent way, by using <a href="http://software.inl.fr/trac/wiki/EdenWall/NuFace" target="_top">NuFace</a></p></li><li><p>plaintext : this module is intended to be used for quick testing only. It requires that you reload nuauth when modifying rules.</p></li></ul></div><p>
 by setting the variable <code class="option">nuauth_acl_check_module</code>.
 </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id284302"></a>Testing</h2></div></div></div><p>To be able to proceed quickly to test, we will use the system
 module for user and the plaintext module for acl.
 A sample file for the plaintext acl check module is available
 in the <code class="filename">conf</code> directory, <code class="filename">acls.nufw</code>.
 Copy it to <code class="filename">/etc/nufw</code> and adjust the
 group of the ssh acl to have it matching the group of a system
 user you will use later to authenticate on the system.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284330"></a>Setting up Netfilter rules before 2.6.14</h3></div></div></div><p>
 We will test the setup by connecting from the local host ssh server. For this
 we need to add filtering rules to ask for authentication:
 </p><pre class="screen">iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j QUEUE
 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT</pre><p>
 <sup>[<a name="id284346" href="#ftn.id284346">2</a>]</sup>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284353"></a>Setting up Netfilter rules from 2.6.14</h3></div></div></div><p>
 We will test the setup by connecting from the local host ssh server. For this
 we need to add filtering rules to ask for authentication:
 </p><pre class="screen">iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j NFQUEUE
 iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT</pre><p>
 <sup>[<a name="id284368" href="#ftn.id284368">3</a>]</sup>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284377"></a>Testing the authentication system</h3></div></div></div><p>First, the daemons need to be started. We start nuauth in a terminal
 </p><pre class="screen">nuauth -vvvvvvvvv</pre><p>
 then we start </p><pre class="screen">nufw -s -vvvvvvvvv</pre><p> in another terminal.
 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When starting <span><strong class="command">nufw</strong></span> or <span><strong class="command">nuauth</strong></span> daemons without the <span><strong class="command">-D</strong></span> switch,
 they do not run as daemon : they remain attached to the console. In such conditions, both programs log to STDOUT/STDERR instead of
 using syslog. On production, you should always start the daemons with the <span><strong class="command">-D</strong></span> option.</p></div><p>
 Next, we can try to connect a user. Under Linux it can be done with:
 </p><pre class="screen">nutcpc -N -d -U [USERNAME] -H [NUAUTH IP]</pre><p>
 Next step is to enter the user's password. Without the <span><strong class="command">-U</strong></span> option, the current system user's name is used.</p><p>At nuauth level, we should see something like:
 </p><pre class="screen">user bill@nufw uses OS Linux, 3.0.10, #1 Tue Oct 19 23:51:32 CEST 2008</pre><p>
 If your PAM setup is based on shadow file, you will not be able to authenticate a user different from the one running nuauth. On this kind of setup, nuauth needs to be run as root to authenticate other users.
 <sup>[<a name="id284456" href="#ftn.id284456">4</a>]</sup>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284467"></a>Initial tests and debug process</h3></div></div></div><p>
         Let's authenticate a ssh connection from the computer.
 </p><div class="itemizedlist"><ul type="disc"><li><p>nufw gets a packet from  Netfilter:
     </p><pre class="screen">[PID] Sending request for 12</pre><p>
 is the ID of the packet inside the kernel.
 </p></li><li><p>nuauth receives nufw's request:
     </p><pre class="screen">* Message: NuFW Packet: src=127.0.0.1 dst=127.0.0.1 proto=6 sport=48505 dport=22, IN=lo OUT=, packet_id=12, mark=0</pre></li><li><p>nuauth sends an authentication request to the clients
 on IP source:
     </p><pre class="screen">** Message: Warn client(s) on IP 127.0.0.1</pre></li><li><p>nuauth receives packet from the client:
     </p><pre class="screen">** Message: User Packet: src=127.0.0.1 dst=127.0.0.1 proto=6 sport=48504 dport=22, mark=0, user=regit, \\
 OS=Linux 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008, app=/usr/bin/ssh</pre><p>
     </p></li><li><p>nuauth sends back response to nufw:
     </p><pre class="screen">** Message: Answ Packet: src=127.0.0.1 dst=127.0.0.1 proto=6 sport=48505 dport=22, decision=ACCEPT, IN=lo OUT=, \\
 packet_id=12, mark=1000, user=regit, OS=Linux 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008, app=/usr/bin/ssh</pre><p>
     </p></li><li><p>nufw pushes the packet back in the kernel:
     </p><pre class="screen">[PID] (*) Accepting packet with id=12</pre><p>
 </p></li></ul></div><p>
                 </p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id284346" href="#id284346">2</a>] </sup>
 Only SYN packets are sent to QUEUE. This is not enough to do advanced
 user activities logging, but enough for traffic authentication.
 </p></div><div class="footnote"><p><sup>[<a name="ftn.id284368" href="#id284368">3</a>] </sup>
 Only SYN packets are sent to NFQUEUE. This is enough to do advanced
 user activities logging, because events on the connections will be automatically sent to nufw by Netfilter.
 This requires, in particular, that the CONFIG_IP_NF_CONNTRACK_EVENTS kernel option be set.
 </p></div><div class="footnote"><p><sup>[<a name="ftn.id284456" href="#id284456">4</a>] </sup> Never launch nutcpc against 'localhost' or '127.0.0.1',
 even if nuauth is on the same computer.
 Packets sent to nuauth by the firewall will hardly have the address of the loopback but rather have a
 source address which is one of the network interface.
 </p></div></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id283832" href="#id283832">1</a>] </sup>Please let us know if you find others ;)</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id284555"></a>Chapter�4.�Setting up NuFW</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#LDAP_acls">Using the LDAP module for acl checking</a></span></dt><dd><dl><dt><span class="section"><a href="#id284673">Installation of OpenLDAP server (slapd)</a></span></dt><dt><span class="section"><a href="#id284696">Slapd configuration</a></span></dt><dt><span class="section"><a href="#id284772">nuauth configuration</a></span></dt><dt><span class="section"><a href="#id284800">Using nuface, a web-based rules generator</a></span></dt><dt><span class="section"><a href="#id284824">nuaclgen configuration</a></span></dt></dl></dd><dt><span class="section"><a href="#id284892">Setting up NuFW authenticated connections tracking</a></span></dt><dd><dl><dt><span class="section"><a href="#id284897">nuauth settings</a></span></dt><dt><span class="section"><a href="#mysql_log">Installation of MySQL server</a></span></dt><dt><span class="section"><a href="#id284947">Installation of PostgreSQL server</a></span></dt><dt><span class="section"><a href="#id284997">SQL configuration</a></span></dt><dt><span class="section"><a href="#id285053">Life of a connection in the SQL table</a></span></dt><dt><span class="section"><a href="#id285120">Netfilter settings</a></span></dt><dt><span class="section"><a href="#id285234">Using the connection tracking</a></span></dt></dl></dd><dt><span class="section"><a href="#id285280">Single Sign On setup</a></span></dt><dd><dl><dt><span class="section"><a href="#id285284">Apache</a></span></dt><dt><span class="section"><a href="#id285300">Squid</a></span></dt><dt><span class="section"><a href="#id285316">Troubleshooting single sign on problems</a></span></dt></dl></dd><dt><span class="section"><a href="#id285406">User based Quality of Service</a></span></dt><dd><dl><dt><span class="section"><a href="#id285411">Setting up Kernel on non libnetfilter_queue system</a></span></dt><dt><span class="section"><a href="#id285438">Setting up nufw</a></span></dt><dt><span class="section"><a href="#id285454">Setting up Netfilter</a></span></dt><dt><span class="section"><a href="#id285484">Using marking modules</a></span></dt><dt><span class="section"><a href="#id285510">Using NuFW mark</a></span></dt></dl></dd><dt><span class="section"><a href="#id285556">Controlling nuauth finely at runtime</a></span></dt><dt><span class="section"><a href="#id285744">Time-based ACLs</a></span></dt><dd><dl><dt><span class="section"><a href="#id285749">Global configuration</a></span></dt><dt><span class="section"><a href="#id285793">XML period definition module</a></span></dt></dl></dd><dt><span class="section"><a href="#id285879">Chaining modules in nuauth</a></span></dt><dd><dl><dt><span class="section"><a href="#id285883">Syntax description</a></span></dt><dt><span class="section"><a href="#id285926">Some examples</a></span></dt></dl></dd><dt><span class="section"><a href="#hardening">Hardening NuFW</a></span></dt><dd><dl><dt><span class="section"><a href="#id285976">Nufw certificate verification</a></span></dt><dt><span class="section"><a href="#id286172">Authentication server (nuauth)</a></span></dt><dt><span class="section"><a href="#id286346">User authentication restrictions</a></span></dt><dt><span class="section"><a href="#id286379">On client side</a></span></dt><dt><span class="section"><a href="#id286566">Certificate authentication</a></span></dt><dt><span class="section"><a href="#id286606">Using secure LDAP (LDAPs) for ACLs checking</a></span></dt><dt><span class="section"><a href="#id286701">OS and application filtering</a></span></dt><dt><span class="section"><a href="#id286719">Intrusion Detection System (IDS)</a></span></dt></dl></dd><dt><span class="section"><a href="#nuauth_auth">Nuauth authentication configurations</a></span></dt><dd><dl><dt><span class="section"><a href="#id286785">PAM/LDAP authentication with Nuauth</a></span></dt><dt><span class="section"><a href="#id286868">PAM/Winbind authentication with Nuauth</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="LDAP_acls"></a>Using the LDAP module for acl checking</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284673"></a>Installation of OpenLDAP server (slapd)</h3></div></div></div><p>OpenLDAP server installation is standard. Use your Linux distribution packages,
 example with Debian:
 </p><pre class="screen">apt-get install slapd</pre><p>
 Read <a href="http://www.openldap.org/doc/admin/" target="_top">OpenLDAP Software
 Administrator's Guide</a>, section "Building and Installing OpenLDAP Software" to get more information.
         </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284696"></a>Slapd configuration</h3></div></div></div><p>
 The file <code class="filename">acls.schema</code> has to be put in <code class="filename">/etc/ldap/schema</code>
 and a line
 </p><pre class="screen">include         /etc/ldap/schema/acls.schema</pre><p>
 has to be added at the beginning of the <code class="filename">/etc/ldap/slapd.conf</code>.
 In the level of access setup in this file, one can add:
 </p><pre class="screen">#INL access for acls
 access to  dn="ou=acls,dc=nufw,dc=org"
        by dn="uid=nufw,ou=Users,dc=nufw,dc=org" write
        by dn="uid=nuauth,ou=Users,dc=nufw,dc=org" read
        by dn="cn=admin,dc=nufw,dc=org" write
        by * none</pre><p>
 nufw user is able to modify the policy and the nuauth user
 can only read the acls.
 </p><p>
 To speed up search request you can add the following index to your <code class="filename">slapd.conf</code>:
 </p><pre class="screen">
 index OsName,OsRelease,OsVersion,AppName pres,eq
 index SrcIPStart,SrcIPEnd,DstIPStart,DstIPEnd pres,eq
 index Proto,SrcPortStart,SrcPortEnd,DstPortStart,DstPortEnd pres,eq
 index SrcPort,DstPort pres,eq
 </pre><p>
 </p><p>
 You can start with a LDIF file such as:
 </p><pre class="screen">dn: dc=nufw,dc=org
 objectClass: top
 objectClass: dcObject
 objectClass: organization
 o: nufw.org
 dc: nufw
 structuralObjectClass: organization
 dn: ou=Users,dc=nufw,dc=org
 objectClass: organizationalUnit
 ou: Users
 structuralObjectClass: organizationalUnit
 dn: ou=acls,dc=nufw,dc=org
 objectClass: organizationalUnit
 ou: acls
 structuralObjectClass: organizationalUnit
 dn: uid=nuauth,ou=Users,dc=nufw,dc=org
 objectClass: top
 objectClass: simpleSecurityObject
 uid: nuauth
 userPassword: nuauth
 dn: uid=nufw,ou=Users,dc=nufw,dc=org
 objectClass: top
 objectClass: simpleSecurityObject
 uid: nufw
 userPassword: nufw
 </pre><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284772"></a>nuauth configuration</h3></div></div></div><p>
 To use LDAP support for acl checking, we need to modify the <code class="filename">nuauth.conf</code> file:
 </p><pre class="screen">nuauth_acl_check_module="ldap"</pre><p>
 and we have to setup the connection parameters:
 </p><pre class="screen">ldap_bind_dn="uid=nuauth,ou=Users,dc=nufw,dc=org"
 ldap_bind_password="secretpassword"
 ldap_basedn="dc=nufw,dc=org"
 ldap_acls_base_dn="ou=Acls,dc=nufw,dc=org"</pre><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284800"></a>Using nuface, a web-based rules generator</h3></div></div></div><p>
 <a href="http://www.inl.fr/" target="_top">INL</a> has released a powerful Netfilter rules generator system for NuFW and Netfilter.
 It is called Nuface and it is available at:
 <a href="http://software.inl.fr/trac/wiki/EdenWall/NuFace" target="_top">http://software.inl.fr/trac/wiki/EdenWall/NuFace</a>
 It generates a set of rules for NuFW and Netfilter that can directly be applied from the web interface. All Netfilter rules generated by Netfilter use the stateful capabilities of Netfilter, without user intervention.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284824"></a>nuaclgen configuration</h3></div></div></div><p>nuaclgen is a script that can help you maintain a simple
       set of acls in an LDAP tree.</p><p>It is advised that you use Nuface rather than Nuaclgen, if possible, since it makes things simpler. In particular,
       be aware that when you use nuaclgen, you need to also modify by hand your Netfilter rules.</p><p>
 The file <code class="filename">nuaclgen.conf</code> contains the informations about LDAP
 connections. It needs to be modified to suit your configuration, for example:
 </p><pre class="screen">$ldap_host="localhost";
 $username="uid=nufw,ou=Users,dc=nufw,dc=org";
 $password="writepasswd";
 $basedn="ou=Acls,dc=nufw,dc=org";</pre><p>
 <sup>[<a name="id284854" href="#ftn.id284854">5</a>]</sup>
 </p><p>To allow ssh for users
 of group 513 if they use <code class="filename">/usr/bin/ssh</code> application, we can use:
 </p><pre class="screen">nuaclgen --Aclname cn=ssh,ou=Acls,dc=nufw,dc=org -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513</pre><p>
 </p><p>Or for access directed to a web server:
 </p><pre class="screen">
 nuaclgen --Aclname cn=apt,ou=Acls,dc=nufw,dc=org -p 6 --dport 80 \
   -AppName "/usr/lib/apt/methods/http" -j ACCEPT -g 1042
 </pre><p>
 This ACL gives access to group 1042  which is used by root user of some server of ours.
 Thus root user can only get file to update the computer, but other users can not access
 the web.
 </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id284892"></a>Setting up NuFW authenticated connections tracking</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284897"></a>nuauth settings</h3></div></div></div><p>
  To achieve NuFW connection tracking it is necessary to have these options in <code class="filename">nuauth.conf</code>:
  </p><pre class="screen">nuauth_log_users_sync=1
 nuauth_log_users=9</pre><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="mysql_log"></a>Installation of MySQL server</h3></div></div></div><p>MySQL server installation is standard. Use your Linux distribution packages,
 example with Debian:
 </p><pre class="screen">apt-get install mysql-server</pre><p>
 Read <a href="http://dev.mysql.com/doc/" target="_top">MySQL Documentation</a>, section
 "2 Installing and Upgrading MySQL" to get more information.
         </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284947"></a>Installation of PostgreSQL server</h3></div></div></div><p>PostgreSQL server installation is standard. Use your Linux distribution packages,
 example with Debian (replace 8.2 by the latest server version):
 </p><pre class="screen">apt-get install postgresql-8.2</pre><p>
 Read <a href="http://www.postgresql.org/docs/" target="_top">PostgreSQL Documentation</a>, section
 "III. 14. Installation Instructions" to get more information.
         </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Note that, even though nuauth PostgreSQL support is complete, you probably want to use
         a MySQL server for now, if you want to use <a href="http://software.inl.fr/trac/wiki/EdenWall/NuLog" target="_top">Nulog</a>.
         Single Sign On modules (<a href="http://software.inl.fr/trac/wiki/EdenWall/mod_auth_nufw" target="_top">apache</a>
         and <a href="http://software.inl.fr/trac/wiki/EdenWall/squid_nufw_helper" target="_top">squid</a>) have
         PostgreSQL support.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id284997"></a>SQL configuration</h3></div></div></div><p>The connection tracking system is really useful with SQL logging modules.
 We will describe here the setup of the MySQL module.</p><p>
 You have to create the SQL database from the dump file available in the conf/
 subdir of the archive. Create a SQL account, which must have UPDATE,
 INSERT privileges on the "conntrack_ulog" table. You will have to set the
 credentials for that user in the nuauth.conf file.
 </p><p>
 You may choose between to schema an IPv4 only one and an IPv4/IPv6 one.
 Recent tools like <a href="http://software.inl.fr/trac/wiki/EdenWall/NuLog" target="_top">Nulog2</a> are able to use
 the IPv6 schema. If you have old script or older tools, you better use the IPv4 only schema.
 To import the IPv4 schema into a newly created database, you can use:
 </p><pre class="screen">mysqladmin create nufw
 cat nulog.ipv4.mysql.dump | mysql nufw</pre><p>For the IPv6 schema, simply use:</p><pre class="screen">mysqladmin create nufw
 cat nulog.ipv6.mysql.dump | mysql nufw</pre><p>
 You may also want to rotate the "ulog" table, so that it doesn't grow to infinite
 size with time. The ulog_rotate.py script is available in the
 <a href="http://software.inl.fr/trac/wiki/EdenWall/NuLog" target="_top">Nulog project</a>
 tarball.
 At the present time, it is assumed those scripts are run as the root SQL user,
 as cronjobs. Of course the better way to go is to create a separate user for
 this and grant it the needed privileges. Please provide updates for this
 document if you implement this before we do.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285053"></a>Life of a connection in the SQL table</h3></div></div></div><p>
 If nuauth is configured to log network flow information in a SQL database, here is how the logging system works :
 </p><div class="itemizedlist"><ul type="disc"><li><p>When the connexion opening datagram is authenticated (for TCP, that is the SYN datagram), nuauth creates an entry in database, with a request looking like this (for TCP) :
 </p><pre class="screen">INSERT INTO conntrack_ulog (state, oob_time_sec, ip_protocol, ip_saddr, ip_daddr, oob_in, oob_out, oob_prefix, user_id,
 username, client_os, client_app, tcp_sport, tcp_dport) VALUES (... our datagram values ...);</pre><p>
 If nuauth decision for that datagram is to drop or reject it, log of the "connexion" stops here. The connexion will never be opened, and this database entry will no longer be manipulated by nuauth.
 </p></li><li><p>At the time when connection changes state (For TCP, and for any accepted connection, state changes to ESTABLISHED as soon as the server answers the SYN datagram), this request is performed by nuauth, if the nufw daemon is run with "-C" :
 </p><pre class="screen">
 UPDATE conntrack_ulog SET state=ESTABLISHED, start_timestamp=FROM_UNIXTIME(timestamp)
 WHERE (ip_daddr=%s AND ip_saddr=%s "AND tcp_dport='%hu' AND tcp_sport='%hu' AND state=OPEN)
 </pre><p>
 The only fields that are altered by this request are "state", which changes to "ESTABLISHED", and start_timestamp, which wasn't set before. It is important to note that no information is lost when this modification is performed. It is indeed obvious that the connection was previously in "OPEN" state, since that's a TCP preamble to the "ESTABLISHED" state, and the database keeps track of the timestamp when the connection was opened in the "oob_time_sec" field. The "start_timestamp" field simply marks the timestamp of switch to the "ESTABLISHED" state.
 </p></li><li><p>When the connection expires, this request is executed by nuauth, if the nufw daemon is run with "-C" :
 </p><pre class="screen">
 UPDATE conntrack_ulog SET end_timestamp=FROM_UNIXTIME(timestamp), state=CLOSE, packets_in=%d , packets_out=%d , bytes_in=%d , bytes_out=%d
 WHERE (ip_saddr=%s AND ip_daddr=%sAND tcp_sport='%hu' AND tcp_dport='%hu' AND (state=OPEN OR state=ESTABLISHED))
 </pre><p>
 State is updated, it becomes "CLOSE", and we set the end_timestamp field, which was empty before this, as well as packet number and byte number counters for the now dead connexion. Time of opening and time of establishment of the connection remain available in the oob_time_sec and start_timestamp fields.
 </p></li></ul></div><p>
 The SQL logging feature keeps track of the whole history of each connexion, and updates that nuauth performs on the database do never erase data that was previously logged. This log mode is the most powerful one that a firewall can achieve, because it is very synthetic : one single SQL entry is maintained for each connection ; and it keeps the whole history of all elements of connections.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285120"></a>Netfilter settings</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id285124"></a>Settings on post 2.6.14 kernel</h4></div></div></div><p>
 This is the good case compared to pre 2.6.14.
 To enable authenticated connection tracking,
 you only have to add the <code class="option">-C</code> to nufw command line.
 This flag asks nufw to send any ESTABLISHED and DESTROY message coming from Netfilter connections tracking to nuauth.
 </p><p>
 As an important number of events can be sent through this mean, nufw offers the capability to only send a subset.
 It uses the fact that the initial mark can be put with CONNMARK
 on every packets of the connection.
 This mode is activated via the <code class="option">-M</code> flag of nufw.
 On Netfilter side, the following rules have to be added:
 </p><pre class="screen">iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
 iptables -A POSTROUTING -t mangle -m mark ! --mark 0 -j CONNMARK --save-mark
 </pre><p>
 </p><p>
 In short, you should always use <code class="option">-C</code> if you use libnetfilter_conntrack (this is available from linux 2.6.14), and you should use <code class="option">-M</code> if you want all your connections marked per userID (please note that you need to apply <a href="http://nufw.org/download/patches/transmit_mark.patch" target="_top">transmit_mark patch</a> on your kernel to use this). Library compatibility is better with a &gt;=2.6.16 kernel.
       </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id285174"></a>Settings on pre 2.6.14 kernel</h4></div></div></div><p>
 NuFW stores the following states in the life of a TCP connection:
     </p><div class="itemizedlist"><ul type="disc"><li><p>opening: bit SYN is set</p></li><li><p>established: SYN ACK is sent</p></li><li><p>closed: the tcp flags are FIN or FIN,ACK</p></li></ul></div><p>
 To match those packets we need to use the <code class="option">--syn</code> and the
 <code class="option">--tcp-flags</code> options.
 Let's use the following configuration as an example: our web servers are protected by a NuFW firewall. They are in the network $DMZ.
 The following rules achieve to realize a user connection tracking on the web
 server outgoing connections.
 </p><pre class="screen">iptables -A FORWARD -p tcp -m state --state ESTABLISHED --tcp-flags ACK,FIN NONE -j ACCEPT
 iptables -A FORWARD -d $DMZ -p tcp -m state --state ESTABLISHED --dport 80 --tcp-flags SYN,RST,ACK RST -j QUEUE
 iptables -A FORWARD -d $DMZ -p tcp -m state --state ESTABLISHED --dport 80 --tcp-flags FIN FIN -j QUEUE
 iptables -A FORWARD -s $DMZ -p tcp -m state --state ESTABLISHED --sport 80 --tcp-flags SYN,ACK SYN,ACK -j QUEUE
 iptables -A FORWARD -p tcp -m state --state ESTABLISHED -j ACCEPT
 iptables -A FORWARD -d $DMZ -p tcp --syn --dport 80 -m state --state NEW -j QUEUE</pre><p>
 The first rule optimizes the filter by matching an important part of the ESTABLISHED traffic. The last rule with --state ESTABLISHED is the standard accepted established packets. It has to be put after NuFW flags matching rules.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id285222"></a>Settings on &gt;= 2.6.14 kernel</h4></div></div></div><p>
           No special complicated rule should be set, the kernel will automatically send new events on connections to NuFW.
           This is the reason why you don't want to use a pre-2.6.14 kernel ;)
         </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285234"></a>Using the connection tracking</h3></div></div></div><p>
 <span><strong class="command">nutop</strong></span> is a perl script provided with nufw sources. It is a
 top like tool that displays the active and authenticated connections in real-time.
 </p><p>The best way<sup>[<a name="id285251" href="#ftn.id285251">6</a>]</sup> to use the logs generated by the connection tracking is to install
 <span><strong class="command">nulog</strong></span> which provides a convenient web interface.
 <span><strong class="command">nulog</strong></span> is available under GPL on this page:
 <a href="http://software.inl.fr/trac/trac/wiki/EdenWall/NuLog" target="_top">http://software.inl.fr/trac/wiki/EdenWall/NuLog</a>
 </p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id285251" href="#id285251">6</a>] </sup>as far as the author of this document knows at the time of the writing of
 this document</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id285280"></a>Single Sign On setup</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285284"></a>Apache</h3></div></div></div><p>All you need to do is to setup a SQL user with SELECT permissions on the
 "conntrack_ulog" table. Then setup mod_auth_nufw to use the configured SQL
 user/database/table. The source code of the apache module is available at <a href="http://software.inl.fr/trac/wiki/EdenWall/mod_auth_nufw" target="_top">NuFW Apache SSO page</a></p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285300"></a>Squid</h3></div></div></div><p>All you need to do is to setup a SQL user with SELECT permissions on the
 "conntrack_ulog" table. Then setup squid_nufw_helper to use the configured SQL
 user/database/table. The source code of the squid helper is available at
 <a href="http://software.inl.fr/trac/wiki/EdenWall/squid_nufw_helper" target="_top">NuFW Squid SSO page</a></p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285316"></a>Troubleshooting single sign on problems</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id285320"></a>General information</h4></div></div></div><p>If you experience problems with Single Sign On problems, one common way to find out where the problem lays is to check whether the SSO code performs SQL lookups correctly. You can check it out easily at the database level. On MySQL, check you have in <code class="filename">my.cnf</code> something like: </p><pre class="screen">log             = /var/log/mysql/mysql.log</pre><p> This ensures that MySQL logs request that it receives. Then all you need to do is test the module, while running </p><pre class="screen">tail -f /var/log/mysql/mysql.log</pre><p> If the Single Sign On module is doing its job, you should see lines such as : </p><pre class="screen">SELECT DISTINCT username FROM conntrack_ulog WHERE (tcp_sport=50423 AND ip_saddr=3232235761 AND tcp_dport=80 AND ip_daddr=3232235761 AND (state=1 OR state=2))</pre><p> in the log, revealing that the Single Sign On module actually requests the database. If you run a PostgreSQL database, you can do similar operations by setting </p><pre class="screen">log_min_duration_statement = 0</pre><p> in <code class="filename">postgresql.conf</code>. On Debian, the default PostgreSQL log file is probably located in <code class="filename">/var/log/postgresql/postgresql-8.X-main.log</code>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id285378"></a>Apache module troubleshooting</h4></div></div></div><p>Like any Apache module, the mod_auth[n]_nufw module dumps verbose/debug information in the Apache error log when you set :</p><pre class="screen">Loglevel debug</pre><p> in the Apache <code class="filename">httpd.conf</code> file.</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id285406"></a>User based Quality of Service</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285411"></a>Setting up Kernel on non libnetfilter_queue system</h3></div></div></div><p>
 Official Linux kernels are not able to mark packets
 with ip_queue framework before 2.6.14 release.
 It is thus necessary to patch the kernel (if pre 2.6.14), this has to be done by using
 the <code class="filename">ip_queue_vwmark</code> patch available in the
 patch-o-matic-ng from netfilter. This will generate a modified version of both
 ip_queue module and libipq.a file.
 </p><p>
 Once the new libipq.a is installed, you can now compile nufw:
 </p><pre class="screen">./configure --with-user-mark ${EXTRA_OPTIONS_YOU_LIKE}
 make
 make install</pre><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285438"></a>Setting up nufw</h3></div></div></div><p>
 nufw can now be run with <code class="option">-m</code> to use userid marking.
 This option is compatible with <code class="option">-M</code>.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285454"></a>Setting up Netfilter</h3></div></div></div><p>
 As nufw only works with initialization packets it can not pull the userid mark of each packet
 of a connection. Thus, this is necessary to use
 <span class="application">CONNMARK<sup>[<a name="id285467" href="#ftn.id285467">7</a>]</sup></span>
 which is a target able to propagate marks across connections.
 A basic setup is the following:
 </p><pre class="screen">iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
 iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark</pre><p>
 First line restores the existing mark when a packet arrives and second line
 saves mark on the connection so it can be restored later.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285484"></a>Using marking modules</h3></div></div></div><p>
 The nuauth variable <code class="option">nuauth_finalize_packet_module</code> lists module which attach a hook called just before
 nuauth answer to nufw about a packet.
 It is usually used to modify the mark of the packet following a given strategy.
 By splitting the mark in different part, this is possible to define complex marking policy which can later be used
 by Linux routing and QoS systems.
 </p><p>
       Extensive documentation can be found in the file <a href="http://software.inl.fr/trac/browser/mirror/edenwall/nufw/trunk/nufw/doc/README.mark" target="_top">README.mark</a>
       </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285510"></a>Using NuFW mark</h3></div></div></div><p>Netfilter mark can be use by the Quality of Service system and
 the routing system of Linux.</p><p>
 So it is possible to do differentiated routing between different users
 by using command like:
 </p><pre class="screen">ip rule add fwmark XXX lookup TABLE</pre><p>
 </p><p>This is almost the same for QoS, by using <span><strong class="command">tc filter</strong></span> one needs to put
 user's flows in a specific class:
 </p><pre class="screen">tc filter add dev IFACE  prio 5 protocol ip handle 102 fw flowid FLOWID</pre><p>
 </p><p>For more information about routing and quality of service you can read
 <a href="http://www.lartc.org/" target="_top">lartc</a>.
 </p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id285467" href="#id285467">7</a>] </sup>CONNMARK is only available in patch-o-matic
 before 2.6.11, it is included in 2.6.12+ kernels</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id285556"></a>Controlling nuauth finely at runtime</h2></div></div></div><p>NuFW 2.2.0 introduced new nuauth control capabilities, thanks to <span><strong class="command">nuauth_command</strong></span>. This command should
     be installed when you install nuauth, and it can be run by the administrator, on the same server as <span><strong class="command">nuauth</strong></span>.
     <span><strong class="command">nuauth_command</strong></span> connects to nuauth, and lets you do the following tasks :
     </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">help</code> display inline help with a summary of available subcommands</p></li><li><p><code class="option">version</code> display nuauth version</p></li><li><p><code class="option">users</code> list connected users</p></li><li><p><code class="option">firewalls</code> list connected nufw firewalls</p></li><li><p><code class="option">packets count</code> display number of decision waiting packets</p></li><li><p><code class="option">refresh cache</code> refresh all caches</p></li><li><p><code class="option">refresh crl</code> refresh the TLS crl file</p></li><li><p><code class="option">disconnect (ID|regexp)</code> disconnect a user with his session identifier or a regular expression apply on logging name.</p></li><li><p><code class="option">disconnect all</code> disconnect all users</p></li><li><p><code class="option">uptime</code> display nuauth starting time and uptime</p></li><li><p><code class="option">reload</code> reload the configuration and reload the modules</p></li><li><p><code class="option">reload periods</code> reload the time periods</p></li><li><p><code class="option">display debug_level</code></p></li><li><p><code class="option">display debug_areas</code></p></li><li><p><code class="option">debug_level <em class="replaceable"><code>LEVEL</code></em></code></p></li><li><p><code class="option">debug_areas <em class="replaceable"><code>AREAS</code></em></code></p></li><li><p><code class="option">help</code> display this help</p></li><li><p><code class="option">quit</code> disconnect</p></li></ul></div><p>
     You can, for instance, use the <code class="option">disconnect</code> task, in order to force a user reconnect, and have their groups reloaded.
     </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>As a POSIX compliance, <span><strong class="command">nuauth</strong></span> checks the user's authentication, as well as groups, at the time the user's NuFW agent connects. It is
      never refreshed, until the client disconnects, or the administrator forces a disconnect. Nuauth configuration file <code class="computeroutput">nuauth.conf</code> can also force all users
      to reconnect regularly, by setting the <code class="option">nuauth_session_duration</code> parameter.
      </p></div><p>
     </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id285744"></a>Time-based ACLs</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285749"></a>Global configuration</h3></div></div></div><p>
 NuFW can be used to implement strict time-based acls. When a period using time interval is defined (like say 08am-6pm)
 a authenticated connection can only start in the interval and is destroyed at the end of the interval.
     </p><p>Configuration is done by defining a set of periods and using them (by their name) in the acls backend.
     The <code class="option">plaintext</code> acl backend uses the <code class="option">period</code> key to defined the period
     to apply to the acl. The <code class="option">LDAP</code> acls backend uses the <code class="option">TimeRange</code> atttribute.
     </p><p>
     Definition of periods is done by modules and the corresponding option is <code class="option">nuauth_periods_module</code>.
     For now, the     only available module  is <code class="filename">xml_defs</code>.
     </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285793"></a>XML period definition module</h3></div></div></div><p>
 <code class="filename">xml_defs</code> is a period definition module. It uses a XML formatted file to store
 the periods. The path to this file can be set by using the <code class="option">xml_defs_periodfile</code>:
     </p><pre class="screen">
 xml_defs_periodfile="/etc/nufw/periods.xml"
 </pre><p>
 The XML structure of the file is the following:
 </p><pre class="screen">
 &lt;?xml version="1.0"?&gt;
 &lt;periods&gt;
 &lt;period name="5x8" desc="open hour"&gt;
     &lt;perioditem&gt;
         &lt;days start="1" end="5"/&gt;
         &lt;hours start="8" end="18"/&gt;
     &lt;/perioditem&gt;
 &lt;/period&gt;
 &lt;period name="long" desc="date example"&gt;
     &lt;perioditem&gt;
         &lt;dates start="1128282" end="323232323"/&gt;
     &lt;/perioditem&gt;
 &lt;/period&gt;
 &lt;period name="interval" desc="one hour interval"&gt;
     &lt;perioditem&gt;
         &lt;!-- Duration in second (1 hour) --&gt;
         &lt;duration length="3600"/&gt;
     &lt;/perioditem&gt;
 &lt;/period&gt;
 &lt;/periods&gt;
 </pre><p>
 There are two major types of period definitions:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">Time interval</code>: the period is defined by using specifying days, hours or dates interval. Days and hours can be combined to define more complex period.
 </p></li><li><p><code class="option">Duration</code>: the period is defined by a duration expressed in seconds.</p></li></ul></div><p>
 </p><p>Multiple <code class="option">perioditem</code> can be put in the same <code class="option">period</code> to increase the flexibility of period definition.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When using Nuface to manage filtering rules, time-based ACLs can be setup through the web interface, without editing any file by hand.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id285879"></a>Chaining modules in nuauth</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285883"></a>Syntax description</h3></div></div></div><p>
 The syntax is the following: Each option that sets up the use of a hook is
 a space separated list of modules.</p><p>For each module type, the syntax is as follows :
 <code class="option">name[:type[:config file]]</code>
 If syntax is:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">name</code>: loads module "name" with config file included in nuauth.conf</p></li><li><p><code class="option">name:type</code>: loads module "type" with config file CONFIG_DIR/modules/name.conf</p></li><li><p><code class="option">name:type:conf</code>: loads module "type" with config file "conf"</p></li></ul></div><p>
     </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285926"></a>Some examples</h3></div></div></div><p>
  Let's analyze the following line:
 <code class="computeroutput">nuauth_user_logs_module="syslog dblocal:mysql maindb:mysql:/etc/nufw/mainmysql.conf"</code>
 Packet will be logged multiple times:
 </p><div class="orderedlist"><ol type="1"><li><p>In syslog</p></li><li><p>In a MySQL database using configuration file /etc/nufw/modules/dblocal.conf</p></li><li><p>In a second MySQL database using configuration file /etc/nufw/mainmysql.conf</p></li></ol></div><p>
     </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="hardening"></a>Hardening NuFW</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id285976"></a>Nufw certificate verification</h3></div></div></div><p>It is highly recommended to install nuauth and nufw on a dedicated server, hardened
 for security. Other projects like GrSec <sup>[<a name="id285984" href="#ftn.id285984">8</a>]</sup> or
 SELinux <sup>[<a name="id285989" href="#ftn.id285989">9</a>]</sup> can be used to increase local (system)
 security.
 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Since NuFW 2.2.19, a SeLinux configuration is distributed in the <code class="computeroutput">selinux/</code> directory of the archive. Read the <code class="computeroutput">README.selinux</code>
 file there if you want to implement SELinux policies to the NuFW daemons. However, this security policy set is not yet considered stable and
 is distributed for testing purpose. You are welcome to send the NuFW team feedback about it!</p></div><p>
 </p><p>To ensure confidentiality of communications between nufw, nuauth, and the clients,
 all connections are encrypted using TLSv1.</p><p>
 As the firewall policy is applied by nuauth, the trust relationship between nufw and nuauth
 should be verified. The certificate provided by nuauth during the TLS negotiation
 will be checked if a certificate authority is configured in nufw.
 This is done by using the <code class="option">-a</code> option at start
 of nufw followed by the name of the certificate authority file.
 With this option set, <code class="varname">nufw</code> will require a signed certificate
 from nuauth, and verify it.</p><p>The CN (complete name) field from nufw certificate must contain the FQDN (fully
 qualified domain name) of nufw server.
 </p><p>
 Since release 2.2.18, NuFW runs in TLS strict mode by default.
  It means nufw will not start if nuauth certificate is:
 </p><div class="orderedlist"><ol type="1"><li><p>Not verifiable against an authority</p></li><li><p>Invalid</p></li><li><p>Revoked</p></li><li><p>Without signer</p></li><li><p>Signed, but the signer is not a CA</p></li><li><p>With an insecure algorithm (if GnuTLS is compiled with its support)</p></li><li><p>Not yet activated</p></li><li><p>Expired</p></li></ol></div><p>
 See the <a href="#FinerTLS" title="Managing finer TLS settings with NuFW">Managing finer TLS settings with NuFW</a> section of this document for advanced TLS options of nufw and other components.
 </p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
 Since release 2.2.18, this mode is now activated by default. You can disable it, at your own risks, using the <code class="option">-s</code> option of nufw.
 </p></div><p>
 To run nufw with strict TLS checking, you will have to specify the following option:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">-a</code>: Specify the authority file to use.</p></li><li><p><code class="option">-k</code>: Specify the key file to use.</p></li><li><p><code class="option">-c</code>: Specify the certificate file to use.</p></li><li><p><code class="option">-r</code>: Specify the certificate revocation list file to use (if available). A nufw restart  or a SIGHUP signal will be needed if you want change to the file to be taken into account.</p></li><li><p><code class="option">-d</code>: Fully qualified domain name of the nuauth server.</p></li></ul></div><p>
 Thus a typical nufw command line should look like:
 </p><pre class="screen">nufw -d nuauth.nufw.org -a localCA-cacert.pem -k server.nufw.org-key.pem -c server.nufw.org-cert.pem -r localCA-crl.pem</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p><a href="http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol" target="_top">OCSP</a>
 is currently not supported by NuFW 2.2.X. OCSP support is being worked on in the
 trunk (currently unstable) branch of NuFW. Please contact NuFW developers if you need OCSP in 2.2.X,
 maybe we can add it to the 2.2 TODO list.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286172"></a>Authentication server (nuauth)</h3></div></div></div><p>The option <code class="option">nuauth_tls_request_cert</code> defines if client
 certificates are optional or not. Possible values are:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">0</code>: nuauth will not ask client to provide a certificate, they won't send one
 even if they have some to give.</p></li><li><p><code class="option">1</code>: client is asked to send a certificate, but the server will not refuse connection if none is provided.</p></li><li><p><code class="option">2</code>: client is asked to send a certificate, and the server will drop the connection if none is provided.</p></li></ul></div><p>
 </p><p>The default setting (<code class="option">nuauth_tls_request_cert=2</code>) is that nuauth will require and verify client certificates for all
 connections (clients, and NuFW servers). Certificates are used to verify the identity
 of all components of a NuFW installation (nufw, nuauth, and clients), and ensure that
 no forgery or false representation has occurred.
 </p><p>All components must share the same certificate authority (CA).
 See the <a href="#FinerTLS" title="Managing finer TLS settings with NuFW">Managing finer TLS settings with NuFW</a> section of this document for advanced TLS options of nuauth and other components.
 </p><p>The CN (complete name) field from nuauth certificate must contain the FQDN (fully
 qualified domain name) of nuauth server. All clients and nufw servers will check that
 the DNS name of nuauth server matches the name in the certificate.
 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>It is possible to generate a certificate with additional names, using the
 <code class="computeroutput">subjectAltName</code> extension (See
 <a href="http://tools.ietf.org/html/rfc3280#section-4.2.1.7" target="_top">Section 4.2.1.7 of RFC
 </a>).
 </p></div><p>
 You have to:
 </p><div class="orderedlist"><ol type="1"><li><p>Configure the certificate authority (<code class="option">nuauth_tls_cacert</code>)</p></li><li><p>Configure nuauth certificate (<code class="option">nuauth_tls_cert</code>) and key (<code class="option">nuauth_tls_key</code>) files.</p></li><li><p>Deploy client certificates. If you only want to verify server
 identity, you can share a certificate between several clients. If you want to
 use certificates for authentication, or if you will revoke certificates, you
 have to deploy a certificate for each client.
     </p></li></ol></div><p>
 Warning: since release 2.2.18, this mode is now activated by default. You can
 disable it, at your own risks, by setting <code class="option">nuauth_tls_request_cert=0</code> in nuauth
 configuration file.
 </p><p>nuauth will check that the CN (complete name) field from nufw certificate contains the FQDN (fully
 qualified domain name) of the nufw server. You can disable it, at your own risks, by setting
 <code class="option">nuauth_tls_disable_nufw_fqdn_check=1</code> in nuauth configuration file.
 </p><p>You should also configure a Certificate Revocation List (CRL), with the
 <code class="option">nuauth_tls_crl</code> parameter in nuauth configuration file. This file contains
 the list of all revoked certificates, in standard CRL format. You have to create a
 planified task (cron job) to update this file periodically, nuauth will check for
 modifications every <code class="option">nuauth_tls_crl_refresh</code> seconds and will reload the file
 if necessary. You can use the HUP signal or the <span><strong class="command">refresh crl</strong></span> command
 to force an update of the CRL.
 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Note that currently, private keys cannot be password protected : neither nufw nor nuauth support entering a passphrase.
 The reference documentation mentions the <code class="computeroutput">nuauth_tls_key_passwd</code> option, but it is not implemented for now.
 </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286346"></a>User authentication restrictions</h3></div></div></div><p>You can restrict the number of simultaneous nuauth clients, per user or per IP address.
 </p><div class="orderedlist"><ol type="1"><li><p><code class="option">nuauth_single_user_client_limit</code>: maximum number of nuauth clients per user</p></li><li><p><code class="option">nuauth_single_ip_client_limit</code>: maximum number of nuauth clients per IP</p></li></ol></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286379"></a>On client side</h3></div></div></div><p>nuauth client (nutcpc or nuapplet) will verify nuauth certificate when connecting, if a
 certificate authority is configured on the client (option <code class="option">-A</code> of nutcpc). The certificate
 of the nuauth server will be verified, and the DNS name must match the CN field of the certificate.
 See the <a href="#FinerTLS" title="Managing finer TLS settings with NuFW">Managing finer TLS settings with NuFW</a> section of this document for advanced TLS options of nutcpc and other components.
 </p><p>You can disable, at your own risks, the verifications:
 </p><div class="orderedlist"><ol type="1"><li><p>If no certificate authority is defined, the trust relation with nuauth will not be
   checked. Other attributes of nuauth certificate (expiration,etc.) will be checked, though.
     </p></li><li><p>Option <code class="option">-N</code> disables the verification of the DNS name of nuauth server.
     </p></li><li><p>Option <code class="option">-Q</code> disables warnings if no certificate authority is configured.
     </p></li></ol></div><p>
 </p><p>Clients should provide a client certificate, signed by the same authority.
 </p><div class="orderedlist"><ol type="1"><li><p>If the certificate is used to login, the name of the user must be stored in the CN field
   of the client certificate.</p></li><li><p>If the certificate is not used to login, the CN field of the client certificate is
   not checked.</p></li></ol></div><p>
 </p><p>
 The <code class="computeroutput">nutcpc</code> client supports multiple options to achieve a strict verification of
 nuauth certificates:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">-A</code>: Specify the authority file to use.</p></li><li><p><code class="option">-K</code>: Specify the key file to use.</p></li><li><p><code class="option">-C</code>: Specify the certificate file to use.</p></li><li><p><code class="option">-R</code>: Specify the certificate revocation list file to use. A nutcpc restart or a SIGHUP signal
 will be needed if you want change to the file to be taken into account.</p></li><li><p><code class="option">-H</code>: Fully qualified domain name of the nuauth server.</p></li></ul></div><p>
 To sum up a typical nutcpc command line should look like:
 </p><pre class="screen">nutcpc -H nuauth.nufw.org -A localCA-cacert.pem -K client.nufw.org-key.pem -C client.nufw.org-cert.pem -R localCA-crl.pem</pre><p>
 It is possible to use the configuration file <code class="filename">nuclient.conf</code> to specify value
 for these options and be able to run client without having to specify all
 options on the commandline. A typical <code class="filename">nuclient.conf</code> should look like.
 </p><pre class="screen">
 # Name of the nuauth server (fully qualified domain name, or IP address).
 nuauth_ip=nuauth.nufw.org
 # Certificate authority used to check the validity of nuauth certificate
 nuauth_tls_ca=/etc/nufw/localCA-cacert.pem
 # Certificate file used to negotiate the TLS connection to nuauth.
 nuauth_tls_cert=/etc/nufw/client.nufw.org-cert.pem
 # Key of the certificate file from the nuauth_tls_cert option.
 nuauth_tls_key=/etc/nufw/client.nufw.org-key.pem
 # Certificate revocation list file to use.
 nuauth_tls_crl=/etc/nufw/localCA-crl.pem
 </pre><p>
 To combine strict TLS usage and login/password authentication, the recommended setup for
 client certificate deploiement is to deploy a per-computer certificate with FQDN matching
 computer domain name with the associated CA and key in the configuration directory of NuFW
 (usually <code class="filename">/etc/nufw/</code>). By setting the correct values in
 <code class="filename">/etc/nufw/nuclient.conf</code> (as previously seen), the computer user will be
 able to run client without providing any options (omit for -U option which is needed if the local
 user name is different from the nuauth user name).
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286566"></a>Certificate authentication</h3></div></div></div><p>Certificates can be used to authenticate clients, if a user provides
 a client certificate during the TLS negotiation. Nuauth will extract the username
 based on the CN of the provided certificate. The username computation is made by taking the
 CN string till a slash or a comma is encountered. For example, for <code class="computeroutput">admin/email=admin@inl.fr</code>,
 it will return <code class="computeroutput">admin</code>.
 The obtained username must match a known user on the system.
 Nuauth will check the certificate, and if
 validated, will mark the user as authenticated (no password asked). </p><p>
 To activate this functionality, nuauth configuration file must include:
 </p><pre class="screen">nuauth_tls_auth_by_cert=1</pre><p>
 Note that, <code class="option">nuauth_tls_request_cert</code> has to be set
 to 1 or 2 in the mean time. If set to 2, certificates authentication is
 mandatory.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286606"></a>Using secure LDAP (LDAPs) for ACLs checking</h3></div></div></div><p>
 If the LDAP server supports TLS connections, you should setup nuauth to
 have the LDAP acls checking module using LDAP over SSL.
 </p><p>To do so, edit <code class="filename">nuauth.conf</code> and modify LDAP
 port to 636 (LDAPs):
 </p><pre class="screen">
 ldap_server_port=636
 </pre><p>
 Then, edit <code class="filename">/etc/ldap/ldap.conf</code> to indicate the policy used
 for SSL connections.
 If you only want to encrypt data, you can simply add to <code class="filename">ldap.conf</code>:
 </p><pre class="screen">
 TLS_REQCERT never
 </pre><p>
 The recommended setup is to fill in <code class="filename">ldap.conf</code> with the path to certificate authority.
 <code class="filename">ldap.conf</code> should look like:
 </p><pre class="screen">
 TLS_CACERT /etc/ldap/cacert-ldap.pem
 TLS_REQCERT demand
 </pre><p>
 Please note that the certificate must precisely match the hostname set in
 the <code class="option">ldap_server_addr</code> option in <code class="filename">nuauth.conf</code>.
 </p><p>See the <a href="http://www.openldap.org/doc/admin24/tls.html" target="_top">TLS section</a> in
 <a href="http://www.openldap.org/doc/admin24/" target="_top">LDAP Configuration guide</a>, and
 <a href="http://www.openldap.org/faq/data/cache/185.html" target="_top">OpenLDAP TLS FAQ</a>
 for more information.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286701"></a>OS and application filtering</h3></div></div></div><p>
 On client side, system needs to be trustworthy to perform
 valuable application and OS filtering. You must never forget that
 it is the application on client side which tells the application name as
 well as the operating system name and version: these informations CAN and WILL
 be spoofed if a malicious user installs a modified NuFW agent.
 </p><p>Thus, the value of application and OS filtering depends on the trust you have
 on the system which issues the authentication. On a secure system (for ex. SELinux)
 where users can not install software, this sort of filtering is "quite
 secure".</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286719"></a>Intrusion Detection System (IDS)</h3></div></div></div><p>NuFW is free software, and as such does not duplicate features from other softwares, but prefer
 to integrate with them, to benefit from their experience, and specific features.
 </p><p>For example, NuFW is a native Prelude<sup>[<a name="id286731" href="#ftn.id286731">10</a>]</sup>
 sensor, using the <code class="option">nuprelude</code> module.
 This allows to send alerts (user login success or failure, connections, etc.) to Prelude, and
 use correlation, for ex., to combine a Network IDS like Snort<sup>[<a name="id286740" href="#ftn.id286740">11</a>]</sup>.
 </p><p>See <a href="https://trac.prelude-ids.org/wiki/ManualUser" target="_top">Prelude user manual</a>, and
 <a href="https://trac.prelude-ids.org/wiki/InstallingAgentThirdpartyNufw" target="_top">Configuring NuFW for Prelude</a>
 for more information.
 </p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>It is to be noted that, for now, all TLS certificates of your installation must be signed by the same CA, for
  valid checks to be performed. It is planned to implement support of chained CAs in a future release (possibly 2.2.20). Currently, using chained CAs might work, and might not. The behavior of NuFW with chained CA is considered to be unspecified for now.</p></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id285984" href="#id285984">8</a>] </sup>http://www.grsecurity.net/</p></div><div class="footnote"><p><sup>[<a name="ftn.id285989" href="#id285989">9</a>] </sup>http://www.nsa.gov/selinux/</p></div><div class="footnote"><p><sup>[<a name="ftn.id286731" href="#id286731">10</a>] </sup>http://www.prelude-ids.com</p></div><div class="footnote"><p><sup>[<a name="ftn.id286740" href="#id286740">11</a>] </sup>http://www.snort.org/</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="nuauth_auth"></a>Nuauth authentication configurations</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286785"></a>PAM/LDAP authentication with Nuauth</h3></div></div></div><p>PAM is a very convenient way for extending authentication to "exotic"
   directories. In particular, PAM lets one interface nuauth on NT domains,
   Active Directory, Radius, etc.
   </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When using PAM authentication for local users (<code class="option">shadow</code> file),
 nuauth must run as root to be able to read system files. This is the only case where nuauth should be run as root !
 It is, however, advised, that you use a real directory (LDAP, Active Directory...) rather than authenticating users
 against the shadow file.
 </p></div><p>To have nuauth authenticate users based on PAM/ldap, use the <code class="option">
   system</code> user checking module in nuauth.conf:
   </p><pre class="screen">nuauth_user_check_module="system"</pre><p>
   </p><p>
   In addition, PAM needs to be properly setup, which is external to NuFW, and
   basically out of the scope of this document. Here are a couple of files to set
   on Debian to get PAM/LDAP working with nuauth:
   /etc/pam.d/nuauth:
   </p><pre class="screen">#This is to set PAM-LDAP, modify to suit your needs!
   auth    required      /lib/security/pam_env.so
   auth    sufficient    /lib/security/pam_ldap.so
   auth    required      /lib/security/pam_deny.so
   account required      /lib/security/pam_ldap.so
   session required      /lib/security/pam_limits.so
   session optional      /lib/security/pam_ldap.so</pre><p>
   The <code class="filename">/etc/nsswitch.conf</code> file also needs to be tuned:
   </p><pre class="screen">#This is to set PAM-LDAP, modify to suit your needs!
   passwd:         compat ldap
   group:          compat ldap
   </pre><p>
   (leave the other lines unchanged).
   And you probably also need to tune the /etc/pam_ldap.conf file. This file
   works for us, provided there is no line beginning with "uri":
   </p><pre class="screen">
   host 127.0.0.1
   ldap_version 3
   scope one
   pam_password crypt
   nss_base_passwd         ou=Users,dc=nufw,dc=org?one
   nss_base_group          ou=Group,dc=nufw,dc=org?one
   </pre><p>
   You also need to install and configure libnss-ldap.
   Configuration that works for us (still on Debian) in /etc/libnss-ldap.conf:
   </p><pre class="screen">
   host 127.0.0.1
   base replace_with_your_base
   ldap_version 3
   rootbinddn cn=admin,dc=replace_with_your_base
   #Optional, set if you need these:
   nss_base_passwd ou=users,dc=nufw,dc=org?one
   nss_base_group ou=groups,dc=nufw,dc=org?one
   </pre><p>
   Of course, tune this to suit your needs, and be aware that these system
   instructions may not be accurate for other distributions!
   </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286868"></a>PAM/Winbind authentication with Nuauth</h3></div></div></div><p>On Debian/Ubuntu, you will need the following packages:
    </p><pre class="screen">
     krb5-user
     krb4-config
     samba
     winbind
    </pre><p>
   </p><p>The /etc/krb5.conf file should contain something like:
    </p><pre class="screen">
 [libdefaults]
         default_realm = DOMAIN.NAME
 # The following krb5.conf variables are only for MIT Kerberos.
         krb4_config = /etc/krb.conf
         krb4_realms = /etc/krb.realms
         kdc_timesync = 1
         ccache_type = 4
         forwardable = true
         proxiable = true
 [realms]
         DOMAIN.NAME = {
                 kdc = 10.0.122.5
                 admin_server = 10.0.122.5
                 default_domain = DOMAIN.NAME
+        }
 [domain_realm]
         .domain.name = DOMAIN.NAME
         domain.name = DOMAIN.NAME
         shortname = DOMAIN.NAME
         .shortname = DOMAIN.NAME
    </pre><p>
   </p><p>It is very important that your system is time-synchronized with the AD/NT server. You should setup NTP to achieve this!
   </p><p>
   The /etc/samba/smb.conf file should also be customized:
    </p><pre class="screen">
 [global]
 # Change this to the workgroup/NT-domain name your Samba server will part of
    realm = DOMAIN.NAME
    password server = AD-SERVER
    netbios name = NUAUTH-SERVER
    workgroup = SHORTNAME
 # server string is the equivalent of the NT Description field
    server string = %h server sexa-prn1 (Samba, Ubuntu)
 ####### Authentication #######
    security = ads
    encrypt passwords = true
    guest account = nobody
 ############ Misc ############
    socket options = TCP_NODELAY
    domain master = no
 # Some defaults for winbind (make sure you're not using the ranges
 # for something else.)
    idmap uid = 10000-20000
    idmap gid = 10000-20000
    template shell = /bin/bash
    template homedir = /home/%D/%U
    client use spnego = yes
    client ntlmv2 auth = yes
    restrict anonymous = 2
    </pre><p>
   </p><p>To join the Windows Domain:
 </p><pre class="screen">
 kinit administrator@DOMAIN.NAME
 net ads join -U administrator
 </pre><p>
   The last command should display the short domain name, and should specify that the machine was successfully added to the domain.
   </p><p>Winbind (or winbindd) should be running on your system. You can check things are going fine by reading samba logs (probably in /var/log/samba/*).</p><p>You will then have to declare that you want to use winbind authentication for nuauth by cooking a <code class="filename">/etc/pam.d/nuauth</code> file:
   </p><pre class="screen">#This is to set PAM-winbind, modify to suit your needs!
   auth    required      /lib/security/pam_env.so
   auth    sufficient    /lib/security/pam_winbind.so
   auth    required      /lib/security/pam_deny.so
   account required      /lib/security/pam_winbind.so
   session required      /lib/security/pam_limits.so
   session optional      /lib/security/pam_winbind.so</pre><p>
   </p><p>
    To be able to use winbind group fetching, the <code class="filename">/etc/nsswitch.conf</code> file should look like:
    </p><pre class="screen">
 passwd:         compat winbind
 group:          compat winbind
 shadow:         compat
 hosts:          files dns mdns
 networks:       files
 protocols:      db files
 services:       db files
 ethers:         db files
 rpc:            db files
 netgroup:       nis
    </pre><p>
   </p></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><p><sup>[<a name="ftn.id284854" href="#id284854">5</a>] </sup>The nuaclgen.conf file contains sensitive data
 and thus must have limited rights.</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id286972"></a>Chapter�5.�Authentication Agents</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id286977">Supported OSes</a></span></dt><dd><dl><dt><span class="section"><a href="#id286982">Windows</a></span></dt><dt><span class="section"><a href="#id287005">Linux</a></span></dt><dt><span class="section"><a href="#id287036">MacOS</a></span></dt><dt><span class="section"><a href="#id287046">UNIX and BSD systems</a></span></dt></dl></dd><dt><span class="section"><a href="#id287058">pam_nufw</a></span></dt><dd><dl><dt><span class="section"><a href="#id287085">Options</a></span></dt><dt><span class="section"><a href="#id287166">Configuration file example</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id286977"></a>Supported OSes</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id286982"></a>Windows</h3></div></div></div><p>NuWinC (NuFW Windows Client) provides NuFW authentication for Microsoft Windows 95/98/NT/2000/XP/2003/Vista. This software is available from <a href="http://inl.fr/" target="_top">INL</a>. NuWinC can provide, when installed on machines of a Windows domain, a 100% transparent behavior, meaning users will not even notice it starting or running. For more information about NuWinC, see <a href="http://www.inl.fr/NuWINc,68.html" target="_top">http://www.inl.fr/NuWINc,68.html</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287005"></a>Linux</h3></div></div></div><p>Several clients run on Linux :
 </p><div class="orderedlist"><ol type="1"><li><p>nutcpc : the lightest, command line agent.</p></li><li><p>Nuapplet2 : The graphical client.</p></li><li><p>PAM authentication, through the pam_nufw module. This provides transparent authentication on nuauth.</p></li></ol></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287036"></a>MacOS</h3></div></div></div><p>MacOS X is supported by the Nuapplet2 graphical client. The nutcpc command line client also runs on MacOS X.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287046"></a>UNIX and BSD systems</h3></div></div></div><p>
 nutcpc is known to work on FreeBSD. For other systems, test feedbacks are greatly welcome! Porting NuFW agents to *NIX systems should be fairly easy, too.
 </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287058"></a>pam_nufw</h2></div></div></div><p>
 The <span><strong class="command">pam_nufw</strong></span> PAM module enables transparent user authentication to NuFW. Of course, this will only work if the login and password you use to login to
 the <span><strong class="command">pam_nufw</strong></span> system are the same as requested by <span><strong class="command">nuauth</strong></span>, ie in your user directory!
 </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287085"></a>Options</h3></div></div></div><p>
 pam_nufw accepts the following command line options:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">server=<em class="replaceable"><code>nuauth_ip</code></em></code>: Nuauth server IP/hostname</p></li><li><p><code class="option">port=<em class="replaceable"><code>nuauth_port</code></em></code>: Nuauth port/service name</p></li><li><p><code class="option">lock=<em class="replaceable"><code>.pam_nufw</code></em></code>: Lock filename</p></li><li><p><code class="option">noauth=<em class="replaceable"><code>user1,user2,(...)</code></em></code>: Don't authenticate these users.</p></li></ul></div><p>
 </p><p>
 Default values:
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">port</code> is 4129</p></li><li><p><code class="option">lockfile</code> is <code class="filename">.pam_nufw</code>, located in <code class="filename">$HOME/.nufw/</code></p></li></ul></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287166"></a>Configuration file example</h3></div></div></div><p>
 PAM configuration files are located in <code class="filename">/etc/pam.d/</code>. Each program which uses PAM
 may have its own file (eg. /etc/pam.d/ssh and /etc/pam.d/kdm) ; it is up to the administrator to choose which programs should
 trigger the pam_nufw authentication. Of course, requisite are :
 </p><div class="itemizedlist"><ul type="disc"><li><p>The program concerned by the configuration is about opening a session.</p></li><li><p>The program concerned by the configuration runs on the userID you want to authenticate connections for.</p></li><li><p>The authentication is performed through a login and password.</p></li></ul></div><p>
 A typical configuration
 file looks like this:
 </p><pre class="screen">
  #%PAM-1.0
  auth    requisite       pam_nologin.so
  auth    required        pam_env.so
  @include common-auth
  auth optional pam_nufw.so server=nuauth.inl.fr port=4129
  @include common-account
  session required        pam_limits.so
  @include common-session
  session optional pam_nufw.so server=nuauth.inl.fr port=4129
  @include common-password
 </pre><p>
 We use auth because we have to know user's password in order to authenticate
 on nuauth. The pam module closes the connection to nuauth when the application
 closes the pam session. You can comment out the session line to suppress disconnection at
 logout.
 </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Make sure you use the same lock file for all pam_nufw config files on a given system, or connections will be authenticated multiple times.
  </p></div><p>
 </p><p>
 <span><strong class="command">pam_nufw</strong></span> respects the <code class="filename">nuclient.conf</code> configuration file
 for all options. See section <a href="#hardening" title="Hardening NuFW">Hardening NuFW</a> for more information
 about <code class="filename">nuclient.conf</code> usage and TLS setup.
 </p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id287254"></a>Chapter�6.�Miscellaneous</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id287258">Supported protocols</a></span></dt><dt><span class="section"><a href="#id287309">Big endian architectures</a></span></dt><dt><span class="section"><a href="#id287319">System with glibc 2.3.2</a></span></dt><dt><span class="section"><a href="#id287332">Linux distributions specific</a></span></dt><dt><span class="section"><a href="#id287348">Debian specific</a></span></dt><dt><span class="section"><a href="#id287368">Mandrake specific</a></span></dt><dt><span class="section"><a href="#id287377">Suse specific</a></span></dt><dt><span class="section"><a href="#id287387">Redhat specific</a></span></dt><dd><dl><dt><span class="section"><a href="#id287392">RedHat Enterprise Linux 4</a></span></dt></dl></dd><dt><span class="section"><a href="#id287403">Known issues</a></span></dt><dd><dl><dt><span class="section"><a href="#id287408">Problem with ip_queue on kernel prior to 2.6.12</a></span></dt><dt><span class="section"><a href="#id287420">Running NuFW in a bridged network</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287258"></a>Supported protocols</h2></div></div></div><p>The NuFW daemons can virtually support any protocol, provided a stateful inspection exists
 in Netfilter to deal with the given protocol. However, the main concern about protocol support is client-side.
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">TCP</code>: TCP is supported by all existing clients (Linux, MacOS X, Windows).</p></li><li><p><code class="option">UDP</code>: Requires some administrator operations, for now only the Windows client supports UDP.</p></li><li><p><code class="option">ICMP</code>: Uses raw socket. We are unsure whether this can be authenticated at all. For now, no client supports ICMP.</p></li><li><p><code class="option">IPv6</code>: IPv6 is supported since branch 2.2, with the same restrictions as IPv4.</p></li><li><p><code class="option">other</code>: No support. Contact us if you feel some other protocol could be supported.</p></li></ul></div><p>
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287309"></a>Big endian architectures</h2></div></div></div><p>Big endian architectures are supported since version 1.0.11. Prior
 releases do not work on big endian.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287319"></a>System with glibc 2.3.2</h2></div></div></div><p>
 Glibc 2.3.2 is buggy and you need to set
 <code class="option">system_glibc_cant_guess_maxgroups</code> to the maximum number of groups
 for a single user.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287332"></a>Linux distributions specific</h2></div></div></div><p>Packages can be provided by some distributions. However,
 these packages can be modified by the maintainer, or might not be up to date, so
 check the local modifications carefully.
 </p><p>
 While these packages can be good, it is encouraged to use the official releases from
 nufw.org, which are officially supported by the developers.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287348"></a>Debian specific</h2></div></div></div><p>NuFW packages are part of the Debian main distribution.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>However, we recommend that you use the latest available NuFW version. Debian packages are available at <a href="http://packages.inl.fr/" target="_top">packages.inl.fr</a></p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287368"></a>Mandrake specific</h2></div></div></div><p>NuFW is packaged in Mandriva Corporate Server 4.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287377"></a>Suse specific</h2></div></div></div><p>Suse version 9 seems to use a very old Glib, which is not compatible with
 NuFW. It seems this is true for all Suse versions until v9.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287387"></a>Redhat specific</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287392"></a>RedHat Enterprise Linux 4</h3></div></div></div><p>As RHEL4 is shipped with a 2.6.9 kernel that is subject to the ip_queue
 problem mentioned later in this document. With this
 kernel the bug occurs systematically (at least on SMP machines).</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id287403"></a>Known issues</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287408"></a>Problem with ip_queue on kernel prior to 2.6.12</h3></div></div></div><p>
 There's an ip_queue bug on kernels prior to 2.6.12. It can hang the system when an ACCEPT decision is done
 on the INPUT chain. Thus DO NOT use a QUEUE target on INPUT with these kernels or it could freeze your computer.
 And anyway, you should use a recent kernel and NFQUEUE, as explained here-up in this howto.
 </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id287420"></a>Running NuFW in a bridged network</h3></div></div></div><p>NuFW should run seamlessly in bridge networking. However it seems a bug in some kernel does not allow the use of
 nfnetlink without problems. The following facts were reported (with NuFW 2.2.14, but NuFW versioning is not the matter) :
 </p><div class="itemizedlist"><ul type="disc"><li><p><code class="option">Kernel 2.6.22</code> BUG : No network traffic when launching the nufw daemon.</p></li><li><p><code class="option">Kernel 2.6.24</code> Everything works.</p></li></ul></div><p>
 </p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id287450"></a>Chapter�7.�Appendix</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#FinerTLS">Managing finer TLS settings with NuFW</a></span></dt></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="FinerTLS"></a>Managing finer TLS settings with NuFW</h2></div></div></div><p>
 <a href="#nufw-tls" title="Table�7.1.�nufw daemon (command line) TLS options resume">Table�7.1, &#8220;nufw daemon (command line) TLS options resume&#8221;</a> describes the TLS options that the nufw daemon accepts. All these options are accepted since the 2.2.18 release (some options existed earlier).
 </p><div class="table"><a name="nufw-tls"></a><p class="title"><b>Table�7.1.�nufw daemon (command line) TLS options resume</b></p><div class="table-contents"><table summary="nufw daemon (command line) TLS options resume" border="1"><colgroup><col><col></colgroup><thead><tr><th>Option</th><th>Description</th></tr></thead><tbody><tr><td>-k</td><td>specifies as argument the filename of the (private) key to use.</td></tr><tr><td>-c</td><td>specifies as argument the filename of the (public) certificate to use.</td></tr><tr><td>-a</td><td>specifies as argument the filename of the certificate authority file.</td></tr><tr><td>-N</td><td>If you use this switch, nufw will skip the nuauth CN check.</td></tr><tr><td>-r</td><td>specifies as argument the filename of the certificate revocation list. The daemon will also re-read the revocation list if it is disconnected from nuauth and needs to reconnect. Since 2.2.19, nufw reloads this file when receiving a HUP signal.</td></tr><tr><td>-n</td><td>specifies as argument the string of the expected DN that should be received by nuauth. The DN advertised by nuauth will have to match the string exactly, else nufw will drop the connection. If you do not specify this option, the DN of the certificate will be checked against the FQDN of the nuauth server (nufw will obtain it from a reverse DNS lookup on nuauth IP address).</td></tr><tr><td>-S</td><td>Request that nufw strictly validates the TLS connection when opening the connection to the nuauth server. This means that the nuauth certificate has to be signed by the CA, that it is not revoked, and that the DN of the certificate is also checked (see the <span><strong class="command">-n</strong></span>) option. Since 2.2.18, this is the default behaviour of the nufw daemon.</td></tr><tr><td>-s</td><td>Opposite of <span><strong class="command">-S</strong></span>. This means all TLS checks are disabled. Use at your own risk!!</td></tr></tbody></table></div></div><p><br class="table-break">
 </p><p>
 <a href="#nuauth-tls" title="Table�7.2.�nuauth daemon configuration TLS options resume">Table�7.2, &#8220;nuauth daemon configuration TLS options resume&#8221;</a> describes the TLS options that the nuauth daemon accepts (in nuauth.conf). All these options are accepted since the 2.2.18 release (some options existed earlier).
 </p><div class="table"><a name="nuauth-tls"></a><p class="title"><b>Table�7.2.�nuauth daemon configuration TLS options resume</b></p><div class="table-contents"><table summary="nuauth daemon configuration TLS options resume" border="1"><colgroup><col><col></colgroup><thead><tr><th>Option</th><th>Description</th></tr></thead><tbody><tr><td>nuauth_tls_key</td><td>specifies as argument the filename of the (private) key to use.</td></tr><tr><td>nuauth_tls_cert</td><td>specifies as argument the filename of the (public) certificate to use.</td></tr><tr><td>nuauth_tls_cacert</td><td>specifies as argument the filename of the certificate authority file.</td></tr><tr><td>nuauth_tls_crl</td><td>specifies as argument the filename of the certificate revocation list.</td></tr><tr><td>nuauth_tls_crl_refresh</td><td>specifies the time period (in seconds) at which nuauth refreshes the <span><strong class="command">nuauth_tls_crl</strong></span> file.</td></tr><tr><td>nuauth_tls_request_cert</td><td>Whether nuauth performs TLS checks. Since 2.2.18, the default value is <span><strong class="command">2</strong></span>, which means that all certificates need to be signed by the CA, must not have expired, and must not be revoked. If you specify <span><strong class="command">0</strong></span>, nuauth will perform no TLS check at all (use at your own risk!!). If you specify <span><strong class="command">1</strong></span>, nuauth will ask the clients and nufw to provide a certificate, but will not fail if no certificate is provided. You should always use the default setting of <span><strong class="command">2</strong></span> if you want a safe installation!</td></tr><tr><td>nuauth_tls_disable_request_warning</td><td>If you set <span><strong class="command">nuauth_tls_request_cert</strong></span> to an insecure value, nuauth will complain in the log everytime a client connects, but will not reject connections. If you want to prevent such logging from nuauth, you can set this option to <span><strong class="command">1</strong></span>. The default value is <span><strong class="command">0</strong></span>.</td></tr><tr><td>nuauth_tls_disable_nufw_fqdn_check</td><td>If you set <span><strong class="command">nuauth_tls_request_cert</strong></span> to <span><strong class="command">2</strong></span> (the default value), the nufw daemon certificate DN will be checked against the nufw fully qualified domain name (which nuauth obtains thanks to a reverse DNS lookup). If they do not match, nuauth will reject the connection. You can set this parameter to <span><strong class="command">1</strong></span> if you want nuauth to accept the connection without checking this match.</td></tr><tr><td>nuauth_tls_auth_by_cert</td><td>This lets clients authenticate with a certificate, rather than with a login/password.</td></tr></tbody></table></div></div><p><br class="table-break">
 </p><p>
 <a href="#nutcpc-tls" title="Table�7.3.�nutcpc command line TLS options resume">Table�7.3, &#8220;nutcpc command line TLS options resume&#8221;</a> describes the TLS options that the nutcpc client accepts on command line. All these options are accepted since the 2.2.18 release (some options existed earlier).
 You can also get nutcpc to read configuration from <span><strong class="command">nuclient.conf</strong></span> config file (see below).
 </p><div class="table"><a name="nutcpc-tls"></a><p class="title"><b>Table�7.3.�nutcpc command line TLS options resume</b></p><div class="table-contents"><table summary="nutcpc command line TLS options resume" border="1"><colgroup><col><col></colgroup><thead><tr><th>Option</th><th>Description</th></tr></thead><tbody><tr><td>-C</td><td>specifies as argument the filename of the (public) certificate to use.</td></tr><tr><td>-A</td><td>specifies as argument the filename of the certificate authority file.</td></tr><tr><td>-K</td><td>specifies as argument the filename of the (private) key.</td></tr><tr><td>-W</td><td>if you use a keyfile (with <span><strong class="command">-K</strong></span>), and it is password-protected, you can specify the password to use with this switch. Use with <span><strong class="command">-q</strong></span> for security reasons.</td></tr><tr><td>-R</td><td>specifies as argument the filename of the certificate revocation list. This file is only checked when nutcpc is launched : you currently need to stop and restart nutcpc if the revocation list is changed. Since 2.2.19, nutcpc reloads this file when receiving a HUP signal.</td></tr><tr><td>-a</td><td>specifies as argument the string to use to check the CN nuauth certificate contains. If you do not use this option, nuauth certificate DN will be checked against nuauth fully qualified domain name, which will be found by performing a reverse DNS lookup on nuauth IP address.</td></tr><tr><td>-N</td><td>If you use this switch, nutcpc will skip the nuauth CN check.</td></tr><tr><td>-Q</td><td>By default, nutcpc leaves with an error if the CA is not configured (see <span><strong class="command">-A</strong></span>), and (since 2.2.19) forces user to type "yes" to bypass the warning. If you use this option, the problem will be ignored. Use at your own risk!!</td></tr></tbody></table></div></div><p><br class="table-break">
 </p><p>
 <a href="#nuclient-tls" title="Table�7.4.�nuclient.conf TLS options resume">Table�7.4, &#8220;nuclient.conf TLS options resume&#8221;</a>  describes the TLS options that the libnuclient client accepts on command line. All these options are accepted since the 2.2.18 release (some options existed earlier).
 Currently, these options work with nutcpc, as well as nuapplet.
 </p><p>
 </p><div class="table"><a name="nuclient-tls"></a><p class="title"><b>Table�7.4.�nuclient.conf TLS options resume</b></p><div class="table-contents"><table summary="nuclient.conf TLS options resume" border="1"><colgroup><col><col></colgroup><thead><tr><th>Option</th><th>Description</th></tr></thead><tbody><tr><td>nuauth_tls_cert</td><td>specifies as argument the filename of the (public) certificate to use.</td></tr><tr><td>nuauth_tls_ca</td><td>specifies as argument the filename of the certificate authority file.</td></tr><tr><td>nuauth_tls_key</td><td>specifies as argument the filename of the (private) key.</td></tr><tr><td>nuauth_tls_crl</td><td>specifies as argument the filename of the certificate revocation list. This file is checked when the client is launched, and anytime the client is disconnected from nuauth and needs to reconnect.</td></tr><tr><td>nuauth_suppress_fqdn_verif</td><td>If set to <span><strong class="command">1</strong></span>, the client will skip the nuauth CN check.</td></tr></tbody></table></div></div><p><br class="table-break">
 </p></div></div><div class="glossary"><div class="titlepage"><div><div><h2 class="title"><a name="id288119"></a>Glossary</h2></div></div></div><dl><dt>nufw</dt><a class="indexterm" name="id288125"></a><dd><p>nufw is the server running on the firewall which receives the packets coming from
 kernel and send them to the authentication server and wait a response.</p></dd><dt>nuauth</dt><a class="indexterm" name="id288146"></a><dd><p>nuauth is the authentication server which receives the packets coming from
 nufw and the packets coming from user and send back a decision to nufw.</p></dd></dl></div></div></body><!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=iso-8859-15"><!-- /Added by HTTrack -->
 </html>