sec-wall, a recently released security proxy is a one-stop place for everything related to securing HTTP/HTTPS traffic. Designed as a pragmatic solution to the question of securing servers using SSL/TLS certificates, WS-Security, HTTP Basic/Digest Auth, custom HTTP headers, XPath expressions with an option of modifying HTTP headers and URLs on the fly. . This article is an introductory material that will guide you through the process of installing the software on Ubuntu and preparing the first security configuration - using HTTP Basic Auth with and without tunneling it through SSL/TLS. The core of sec-wall is a high-performance HTTP(S) server built on top of gevent framework which in turn is a Pythonic wrapper around the libevent notification library. Most of the project's dependencies may be fetched using apt-get and that's what will be used below. Note the installation of pip, an installer for Python packages, it will come in handy because Spring Python, another of the project's dependencies isn't available in Ubuntu repositories yet (although there's an ITP for that). Installing zdaemon with pip will make sure the command will be consistently available under the same name regardless of the Python version you're using. pip will also be used for installing sec-wall itself, the software's just too new for there being a DEB in the repositories. $ sudo apt-get install python-pip python-pesto python-gevent python-yaml python-lxml $ sudo pip install zdaemon $ sudo pip install springpython $ sudo pip install sec-wall And that's it, we can proceed to use sec-wall now. Firstly, an instance of the proxy needs to be initialized in an empty directory. That sets up the place for future internal log files, places a dot-prefixed 'hidden' file to mark the directory as belonging to a sec-wall instance and - most importantly - creates a skeleton config file, one that we need to customize. $ mkdir ~/sec-wall-tutorial $ sec-wall --init ~/sec-wall-tutorial Note the newly created~/sec-wall-tutorial/config.py file, it's the central place for configuring a sec-wall instance, that's where the actual configuration takes place. The file is a regular Python source code file which means it's very readable and there's no need for learning yet another specialized config format. Besides, being written in Python, it means the configuration can be fetched from any data source, be it an SQL database, LDAP etc. Let's have a closer look at the config.py file: # -*- coding: utf-8 -*-# stdlib import os.path as path, uuid # Don't share it with anyone. INSTANCE_SECRET = '12a857db5b1d49e887a0e448429d2826' # May be shared with the outside world. INSTANCE_UNIQUE = uuid.uuid4().hex # Useful constants cur_dir = path.dirname(__file__) # Crypto keyfile = path.join(cur_dir, './crypto/server-priv.pem') certfile = path.join(cur_dir, './crypto/server-cert.pem') ca_certs = path.join(cur_dir, './crypto/ca-cert.pem') # ############################################################################## def default(): return { 'ssl': True, 'ssl-cert': True, 'ssl-cert-commonName':INSTANCE_SECRET, 'host': 'http://' + INSTANCE_SECRET } urls = [ ('/*', default()), ] By default, no client applications are allowed in. To achieve it, an application is required to have an SSL/TLS certificate and that certificate's commonName field must be equal to an INSTANCE_SECRET variable which - as stated in the reference documentation and repeated in the config file - should always be a secret known only to sec-wall admins. The 'urls' variable is the starting point - that's where an URL pattern is being matched with the accompanying security configuration and as stated above, the default configuration is paired with a catch-all /* pattern, hence the result of no one being let in by default. Let's we'd like the URL paths beginning with /admin/ to be fenced with HTTP Basic Auth. What we need to do is to add add an URL pattern and have it use a propersecurity config, just like below: # -*- coding: utf-8 -*-# stdlib import os.path as path, uuid # Don't share it with anyone. INSTANCE_SECRET = '12a857db5b1d49e887a0e448429d2826' # May be shared with the outside world. INSTANCE_UNIQUE = uuid.uuid4().hex # Useful constants cur_dir = path.dirname(__file__) # Crypto keyfile = path.join(cur_dir, './crypto/server-priv.pem') certfile = path.join(cur_dir, './crypto/server-cert.pem') ca_certs = path.join(cur_dir, './crypto/ca-cert.pem') # ############################################################################## def admin(): return { 'basic-auth': True, 'basic-auth-username':'my-user', 'basic-auth-password':'my-password', 'basic-auth-realm':'Secure area', 'host': 'http://' } def default(): return { 'ssl': True, 'ssl-cert': True, 'ssl-cert-commonName':INSTANCE_SECRET, 'host': 'http://' + INSTANCE_SECRET } urls = [ ('/admin/ ', admin()), ('/*', default()), ] The expression '/admin/ ' should be read as an '/admin/' prefix followed by any URL path, the value of which will be stored in the 'my_path' run-time variable in case we'd like to use URL rewriting - but we won't be using it in the article. An important point is that the order of patterns in the 'urls' variable is important - had '/*' been on the first position, it would've been a quick match and the request would've been rejected with a 403 HTTP Forbidden response code. Use the sec-wall command to start the proxy, passing it the name of the directory the config.py file is in as its only argument, like here: $ sec-wall --start ~/sec-wall-tutorial The proxy will start on port 15100 by default so in another browser's tab fire up the address and witness the pop-up asking you for credentials (my-user/mypassword remember?). Now open the URL and you will be greeted with a "You are not allowed to access this resource" message, that because the latter URL fall intothe /* pattern whose course of action is to reject any requests. How about making the traffic be wrapped in SSL/TLS, how hard is it to expose the proxy through HTTPS instead of HTTP? The proxy needs to be stopped first: $ sec-wall --stop ~/sec-wall-tutorial Let's have a closer look at keyfile, certfile and ca_certs variables from the config file. They specify paths to PEM-formatted files to, respectively, the private key, certificate and the list of CAs the proxy is willing to trust. For the sake of keeping the article focused on sec-wall, we'll be using a set of already prepared crypto files that can be found in the attachment. Put the PEM files in a newly created ~/sec-wall-tutorial/crypto directory: $ mkdir ~/sec-wall-tutorial/crypto What's left now is to specify that the proxy's underlying server must be of 'https' instead of the default 'http' one. The 'server_type' variable does just that: # -*- coding: utf-8 -*-# stdlib import os.path as path, uuid # Don't share it with anyone. INSTANCE_SECRET = '12a857db5b1d49e887a0e448429d2826' # May be shared with the outside world. INSTANCE_UNIQUE = uuid.uuid4().hex # Useful constants cur_dir = path.dirname(__file__) # Crypto keyfile = path.join(cur_dir, './crypto/server-priv.pem') certfile = path.join(cur_dir, './crypto/server-cert.pem') ca_certs = path.join(cur_dir, './crypto/ca-cert.pem') server_type = 'https' # ############################################################################## def admin(): return { 'basic-auth': True, 'basic-auth-username':'my-user', 'basic-auth-password':'my-password', 'basic-auth-realm':'Secure area', 'host': 'http://' } def default(): return { 'ssl': True, 'ssl-cert': True, 'ssl-cert-commonName':INSTANCE_SECRET, 'host': 'http://' + INSTANCE_SECRET } urls = [ ('/admin/ ', admin()), ('/*', default()), ] And now the proxy may started and accessed at the address sothat the traffic between a client application and sec-wall is being encrypted. sec-wall is full of customization options yet all of them have sane defaults so that you don't have to deal with it at all if you're not interested in a given functionality. But these interesting features are there. For instance, you probably haven't noticed it but each time you were accessing sec-wall, the proxy was returning a pair of custom HTTP headers, X-sec-wall-invocation-id and X-sec-wall-invocation-id-signed whose purpose is to uniquely identify each of the requests proxied over and to prove the request has actually passed through sec-wall - it's useful when client and backend applications can't get to an agreement over who sent what and when. See the Firebug session's capture for an overview of how it looks like. That would conclude the introduction, don't hesitate to let us know if you'd like to learn more about sec-wall and don't forget that it's a friendly open-source project whose author is always keen to hear about what people would like to use the software for. In other words, it's there for you, speak up if you think anything's missing or should be better tailored towards your needs! Resources Visit us at Contact Dariusz Suchojad Download image of secured headers (PNG) Download certificates ZIP . This article is an introductory material that will guide you through the process of installing the s. sec-wall, recently, released, security, proxy, one-stop, place, everything, related, securing. . Dave Wreski
This article will discuss installing and configuring a secure, centralized file-integrity program. Later articles in this series will discuss specific features, like deploying packaged clients to hosts on your network, creating customized reports, and other cool Samhain features. . Centralized monitoring is critical today with the large number of servers that are deployed in many organizations. Reading reports from individual servers can be quite cumbersome and time-consuming. Programs are needed that will provide accurate and secure information about the state and health of servers in a timely manner in a centralized location, whether with one server or multiple servers. One of the most critical needs is a program that will alert an administrator when files have been changed on a system whether intentionally or as the result of a security compromise. Many programs exist that provide from very basic file-integrity to very specific file-integrity. For example, some file-integrity checks look for any file that has changed within a directory and others can ignore if a file has been accessed or grown in size but alert if the permissions have changed. The level of security needed for file-integrity can depend on a number of factors. How many servers are in an organization, the time an administrator has to spend looking at file-integrity reports, the level of training for the administrator, the cost of a good file-integrity program, the sensitivity of data stored on a server, etc.. There are some superb commercial applications that provide fine-grain control of file-integrity configurations. Of course, it can cost quite a bit of money for these programs but if the needs fit an organization this may be their only solution. There are some great free programs that can rival many of the commercial applications. However, some require extra configuration with other third-party software to have logs sent to a central location securely, for example. Some organizations don't have theadministrators who have the time to create custom programs to add extra functionality to the software. There exists software that will run as a daemon on all servers to be monitored, including the centralized monitoring server, send reports over a secure channel, by default, provide access control to determine whether that hosts is allowed to send alerts to the daemon, deploy the client on remote hosts over SSH, runs on Windows, Solaris, Linux, AIX, and other platforms, with tons of other features that is available under the GPL license, Samhain. Samhain ( pronounced "Sowen". "sow" as in a female pig ) is a file-integrity program that provides high-level configuration for determining what files and/or directories have been changed, deleted, or added. It can also keep a record of files that have the suid or sgid bit set, as well. For Linux, it can send an alert if a new kernel-module has been loaded. Samhain provides a secure, centralized logging facility by having the client(s), that perform the integrity checks, on servers, send encrypted reports to a remote server. Samhain provides a ton of extra features that are very well documented in the manual that comes along with the distribution. Of course, this series of articles will give you a real-world working example of how to deploy Samhain. Installing Samhain The central logging server will be called pango.. To install Samhain download the samhain tarball, verify the pgp signatures, and extract it. Linux: tar xzvf samhain-x.x.x.x.tar.gz Solaris & AIX: gzip -dc samhain-x.x.x.x.tar.gz | tar xvf - ############################################################# SERVER INSTALL -- ONLY NEEDED FOR THE CENTRAL FILE-INTEGRITY SERVER If you are using RPMS then you will need to download the mysql-devel package in order to compile Samhain with MySQL support FILE INTEGRITY SERVER...IN THIS CASE, pango.. Samhain server install configured to log to a mysqldatabase: cd / /samhain-x.x.x ./configure --enable-network=server --with-database=mysql --enable-xml-log --with-libs=-L/usr/lib/mysql/ -with-cflags=-I/usr/include/mysql make make install NOTE: the " --with-libs=-L/usr/lib/mysql/ " and " --with-cflags=-I/usr/include/mysql " are specified, explicitly, because on Red Hat the configure script doesn't properly locate the " libmysqlclient.a " library or the " mysql.h " header file. NOTE: On AIX 4.3, the Makefile had to be modified and have the "-O3" optimizations flags removed. These appear to specific to gcc. If gcc is installed on the server then it may work with the modifying the Makefile. This only needs to be done if an optimize error occurs during the " make " process. The "make install" will create a program called yule in /usr/local/bin . Yule is the server that listens on pango. for incoming integrity reports. Its configuration file is /etc/yulerc, by default. The " DatabaseSeverity " directive will have to be specified in the /etc/yulerc file on pango.. DatabaseSeverity=crit DbHostname=pango. DbName=samhain DbTable=log DbUsername=samhain DbPassword=password Be sure that the yulerc file is configured to be readable and writeable only by root. chmod 600 /etc/yulerc The next article will explain how to setup the yulerc file so that the database password (actually the entire yulerc file) and the Samhain daemon can be virtually hidden. Samhain currently supports MySQL and PostGRESQL. The nice thing about logging to a database is that you can then use PHP, Java, PERL or some other language to extract the data and view it over the web or create your own purdy reports. Samhain has a beta program called Beltrane that will do this work for you and provide an interface over the web to view the alerts and logs for clients. END SERVER INSTALL ############################################################# Client install: (See NOTE: for AIX install) cd / /samhain-x.x.x ./configure --enable-network=client --enable-xml-log make make install This will add the samhain configuration file, samhainrc , to /etc and install the " samhain " executable in " /usr/local/sbin ". That executable will be overwritten with the next step. Create a unique 16-digit number that will be added to pango. to validate sending logs to the Samhain server daemon. All logs will be encrypted and sent to pango. in the XML format, which will allow logging to the mysql server. While in the root directory of the samhain source distribution run the command: /usr/local/sbin/samhain_setpwd samhain pudding eg. /usr/local/sbin/samhain_setpwd samhain pudding 1234567890123456 You have to choose a random 16-digit number to pass to the "samhain_setpwd" command. This will create a new executable for samhain in the current directory called, samhain.pudding . The " pudding " is really an arbitrary name, actually it is my sister's nickname. Move that one to the " /usr/local/sbin/ " directory which will overwrite the default samhain executable created during the " make install " process. mv -f samhain.pudding /usr/local/sbin/samhain Copy the 16-digit number to a sheet of paper or open a console on pango.. This number will be used to create the unique checksum to allow this server to authenticate and send logs to pango.. On pango....run the command: /usr/local/sbin/yule -P For example, in the example above. Run the command: /usr/local/sbin/yule -P 1234567890123456 The above command creates this checksum: Client=HOSTNAME@FBE67F98C36DB5DF@30015639090F9CB064937DC58A0E70644B20EEA083AB7 E2BFF6C1D521D7675FD2DDC7BAEB745F59695B342028D548C72E7DFF135D1E9A05987EC 1D503E8FB1E248F035497924C2C1069B6615DDB35E2FA64D3608DFA3BDD53DD8D D7B997A4B8BE0FB2C2BA2F50E0895B8015D795D7B5623FB924CEF3AC8E065FE6D810D971 append the output of the " yule -P " command to the end of the /etc/samhainrc file, under the [Clients] section and change " HOSTNAME " to the name of the server that the number was created on. Configuring the client : The /etc/samhainrc file is heavily documented and provides various levels of file-integrity. It can be configured to check files and directories, that always change, ignore access times, size, check for new files, deleted files, etc.. It can also check for new suid and sgid permissions, it will also send alerts if a file or directory has a uid or gid that doesn't exist on the system. Below are some specific cofigurations added outside of what already exists in the samhainrc file. The default configuration file is very well documented with some examples. Below are some configurations that were added for my setup. ChecksumTest=check SetNiceLevel=19 SetIOLimit=500 SetFilecheckTime=1800 SetMailTime=86400 #Wait for this many messages to accumulate before sending an email SetMailNum=10 #Prevent messages from being echoed to the console SetConsole=/dev/null SetLogServer=pango. #Time between sending TIMESTAMP messages SetLoopTime=86400 Don't send duplicate reports for a modified file: #Takes a yes/no argument ReportOnlyOnce=yes After configuring the Samhain /etc/samhainrc file, create the database. This may take some time, depending on what files and directories it has to create a checksums for and the suid files it has to check. Also, the priority specified in the configuration file can impact how fast the database is created. samhain -t init After the database is created and the steps have been followed above to create a unique key for the host the samhain client is on,start the samhain client samhain -t check -D -e 120 This will run samhain as a daemon ( -D ) and send alerts every 120 seconds ( -e 120 ) to pango.. Use 120 seconds until you are comfortable with your setup then you can set the time between checks longer. Note that in the configuration file the "SetNiceLevel" is set to 19, which means the file check will run quite slow. This will keep the samhain daemon from using up a lot of CPU but it will cause the reports to be delayed when sent to pango.. You may want to set the "SetNiceLevel" to something lower until you have Samhain configured correctly. Be sure to check the /var/log/yule_log file on pango. for any problems with the hosts sending alerts. If Samhain, on pango., doesn't have a valid key for the hosts then it will not accept any alerts from it. A message will be echoed to /var/log/yule_log alerting that the host is invalid. To start the server on pango., in this case: yule -S This will run the yule server in the background. Again, check the /var/log/yule_log file for an error messages with yule starting up or check it to be sure that the yule server started properly. If you started the server after the client, wait a few minutes to see the connection attempts by the clients: tail -f /var/log/yule_log When the connection attempts start and are successful, there will be a lot of information echoed to the /var/log/yule_log file. This information can be tuned up or down depending on how much information you want. There is also an html file in the /var/lib/samhain directory called " yule.html ". This file is updated every 120 seconds, by default. It reads the /etc/samhainrc file for the hosts that are allowed to connect to the yule server and gives their status. It will display whether a client is connected or whether a policy has been sent from that client, etc.. You can create a symbolic link from that location to the webserver directory on pango. and view it anytime. Be sure that you read and understand the security risks involved with creating symbolic links in a web directory. For any monitoring server, I like to use SSH tunneling to access it. Generally, no services are available directly from the public interface. For example, the web server can be forced to listen on the local interface for incoming http requests in the httpd.conf file with the Listen directive set to: 127.0.0.1:80 In order for anyone to connect to the server they will have to be on pango. from the console or they can create an SSH tunnel to access the web server. Conlusion It is hoped that this article provides a good introduction with some of the capabilities of Samhain, how to install it, and set up a centralized file-integrity server. Samhain comes with a detailed manual in the source distribution. The next series of articles will explain other features of Samhain especially how to deploy Samhain, quickly, to multiple servers, hiding Samhain, using the yule server for a remote syslog server, how to setup Beltrane, and sample php and servlet scripts for extracting data from the Samhain log file or database to create customized web-based reports. Special thanks First and foremost, thanks to the Linuxsecurity.com team for their continued support with publishing my articles. Especially, Dave Wreski since I never send him an article on time because I always catch something that isn't right about it at the last minute. Thanks for your patients Dave. ;-) Some LinuxSecurity list members provided a lot of help with proofreading this article and giving suggestions and comments: Emily Ratliff (many thanks!!), Bernard Hoffmann, Matt Hemingway, and Andy Grimm. Thanks to Bone, Chris, Cris, Barium Spring Home for Children ("The Foundation of Duane's Path to Liberation"), Charla, Chrissy, Mr. David, Bob, Donna, CFCC, Pfeiffer University , Leslie, Adam, STG, NCDC, Lauren , Jason, andmutsman for their continued support for all that I do. About the Author Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS . He writes poetry, just started photography, and hangs out at Old Europe Cafe, Early Girl's eatery (tell'em Duane sent you), and still wakes up every morning ready to go to work. If anybody works at NBC who reads this, tell Ann Curry he says, "Hello", again. . Centralized monitoring is critical today with the large number of servers that are deployed in many . article, discuss, installing, configuring, secure, centralized, file-integrity, program. . Duane Dunston
Get the latest Linux and open source security news straight to your inbox.