barefoot   Frontpage - Barefoot - Download - Usage - Status - Support - Modules - Docs - Links - Survey - GDPR
 

Integration with libwrap

This page describes how some of the functionality in libwrap can be used with Barefoot.

Overview

The libwrap library provides a wide range of operations such as access control, insertion of banners and running of arbitrary commands in case of specified events. Use of the rfc931/identd functionality in Barefoot is covered in the RFC 931 Authentication page. This page looks at access control and execution of external commands.

Environment setup

The libwrap library must be installed and compiled into Barefoot for this functionality to be available. The /etc/hosts.allow and /etc/hosts.deny configuration files can be used but are not necessary.

Server privileges

#server identities (not needed on Solaris)
user.libwrap: libwrap

No special privileges are required to use libwrap. The server should however specify a separate username with the user.libwrap keyword if the server is started as root (this is not necessary on Solaris).

Access control

The Barefoot server can be configured to use the libwrap /etc/hosts.allow and /etc/hosts.deny files for access control in addition to the client pass/deny rules in the Barefoot configuration file. The primary reason for wanting to do this would typically be to be able to use an existing set of access control files or to share the access control rules with other servers that support libwrap. The name to use for the Barefoot server in the libwrap configuration files is barefootd.

#enable libwrap /etc/hosts.allow and /etc/hosts.deny access control
libwrap.hosts_access: yes

By default, the Barefoot server will not perform this type of lookup, but it can be enabled using the libwrap.hosts_access keyword as shown above. When enabled, the Barefoot server will check with libwrap before applying the Barefoot client pass/deny rules; the libwrap access rules can be seen as a filter before Barefoot. If libwrap indicates that a packet or connection should be denied, it will be dropped and no further processing will be done by the Barefoot server. If libwrap indicates that a packet or connection should be allowed, the normal Barefoot rule processing will be applied, resulting in the connection or packet either being dropped or forwarded.

Running libwrap commands

The libwrap library also supports execution of commands, described in the libwrap hosts_options(5) manual page. Some of these commands can be specified in Barefoot rules, allowing them to be executed upon a rule being matched.

#match clients from 192.0.2.0/24
client pass {
        from: 192.0.2.0/24 to: eth0 port = http
        bounce to: www.example.org port = http
        log: error # connect disconnect iooperation 
        #special log message in case of rule match
        libwrap: spawn logger -t '%d[%p]' 'pass to webserver from %c'
        protocol: tcp
}

#all other clients
client pass {
        from: 0.0.0.0/0 to: eth0 port = http
        bounce to: www.example.org port = http
        log: error # connect disconnect iooperation 
        protocol: tcp
}

One possible usage is to run an external command each time a rule matches. The example above has libwrap run the command logger, in order to add an additional log message with information on the client (hostname or IP-address) when clients connect from the network 192.0.2.0/24. Note that stdin/stdout/stderr are by default redirected to /dev/null by libwrap, so if the output of the command is desired, it must be piped to some other command or redirected to a file.

client pass {
        from: 0.0.0.0/0 to: eth0 port = myserv
        bounce to: serv.example.org port = myserv
        log: error # connect disconnect iooperation 
        libwrap: banners /etc/banners
        protocol: tcp
}

The above banners command will result in the contents of the file /etc/banners/barefootd being sent to the client before any data coming from the server. The barefootd filename is fixed by libwrap; if it is desired to have multiple rules with distinct banners, these will have to be placed in different directories, each with a file called barefootd containing the banner contents.

A practical limitation with using banners is that most commonly used protocols will either ignore or not react well to a banner being inserted into the protocol interaction, but banners are a simple way to return a specifically crafted error message to a client.

client block {
        from: 10.0.0.0/8 to: eth0 port = http
        log: error # connect disconnect iooperation 
        libwrap: banners /etc/banners/web-deny/
        protocol: tcp
}

The above client block statement combined with the contents below in the file /etc/banners/web-deny/barefootd will give HTTP clients a more descriptive HTTP error message, rather than simply a closed connection. The libwrap keyword expansion also works in these banners; e.g., %a will be expanded to the IP-address of the client.

HTTP/1.1 403 Forbidden
Connection: close
Content-Type: text/html; charset=iso-8859-1

The requested address is forbidden for %a.

For a client from the address 10.0.0.1, this will produce a message similar to the following:

   The requested address is forbidden for 10.0.0.1.

Command support

The following libwrap commands are supported:

  • spawn, banners

These commands will not work with Barefoot or will likely not result in correct behavior due to Barefoot processes possibly relaying data for multiple clients:

  • twist, keepalive, linger, nice, setenv, umask, user

The functionality of the rfc931 command is available via the rfc931 authentication method.


Copyright © 1998-2024 Inferno Nettverk A/S