|
6. Maintaining
- Overview
- hwctl Utility
- Dialog Menu
- Web Interface
- Operating System
- Updates
6.1 Overview
Once you have your Honeywall installed, configured and deployed, now what?
How do you maintain the system, how do you keep it updated, how do you modify
configurations? We will cover three different options for administering
your Honeywall; hwctl, the Dialog Menu and Web Interface,
We will then finish with updates, how you automate keeping the OS and Honeywall
functionality current.
Before we can begin with administration, you need to quickly understand how the
system saves and uses the information you give it. All of the values you give
the system (IP addresses, email addreses, etc) are stored as variables in
a special configuration directory in /hw/conf.
Each value is stored in its own unique filename, similar to how /proc
file systeme works on many Unix systems. For example, the file
/hw/conf/HwTCPRATE contains the value for the limit of how many
outbound TCP connections are allowed. There are currently over 50
files (unique variables) stored in this location. The system scripts
and Honeywall functionality use these to determine its behavior.
Whenever you use one of the utilities below to configure or modify the
system, you are changing the values stored in the variables. At no
time should you manually modify any of these variables, such as trying
to use vi(1). Instead, use one of the three interfaces we provide,
as include a variety of internal checks.
Now, trying to archive or transport these values can be a pain in the butt.
So, in addition, we created the configuration file
/etc/honeywall.conf. This is a simple ASCTII text file that takes all
the variables and their values from /hw/conf, and stores them in a
single file. This file is NOT used by the system. Instead, this is a
simple way for you to store the system configuration (such as to a
floppy) or transport to another system (such as over scp). This file
is updated automatically everytime a variable is updated.
For more information on how variables are stored and
used, please refer to Sec 9: Internals.
6.2 hwctl Utility
/usr/local/bin/hwctl (which stands for "HoneywallControl") is a command
line utility that allows you to change
the values of Honeywall variables, updates and backs up /etc/honeywall.conf.
In addition, when a variable is changed it gives you the option to automatically
restart only those services that are affected by the variables
changed. It is the only supported method of interacting
with the Honeywall from the command line, and provides the interface
for remote administration and management of your Honeywall. In addition,
both the Dialog Menu and the Walleye interface call on the utility
hwctl whenever they need to make a change to any variable or restart
any service. Advanced users will most likely want to know about the command line
interface, as well as the programming API methodology, to customize
and enhance the Honeywall. If you know what variable you want to
change, there is no need to go through the extra motions (mouse
or keystrokes) of traversing menu interfaces just to set a single
variable and make it take effect. This is where the command line
interface, hwctl, comes in most handy.
You can learn more about hwctl with its help command
hwctl -h or reading the
Sec 9: Internals Section.
Here are some examples. First, there is a variable named HwTCPRATE (stored
as the file /hw/conf/HwTCPRATE)
which holds the value for how many outbound TCP connections
the system will allow before restricting anymore connections. You
can see the value of this variable using hwctl like this:
# hwctl HwTCPRATE
HwTCPRATE = 20
You can change the value of HwTCPRATE to 30 using this command:
# hwctl HwTCPRATE="30"
You can change the limits for TCP outbound connections and have
those changes take effect immediately with the '-r' option.
hwctl -r HwTCPRATE="30"
You can have the system check to see if any variables have been
changed, and if they have been changed, automatically start any
services. If no variables have been changed, report as such.
hwctl -r
You can see all variables currently being used with the -A
flag, as shown here:
# hwctl -A
HwUDPRATE=20
HwTCPRATE=20
HwFWBLACK=/etc/blacklist.txt
HwMANAGE_NETMASK=255.255.255.0
HwWALLEYE=yes
HwSEBEK=yes
HwSEBEK_LOG=yes
HwLAN_BCAST_ADDRESS=10.0.0.255
. . .
[Note: Using -a does not put spaces around the equals signs,
which is the same format as the /etc/honeywall.conf file.
If you wish to parse the output easier with programs like
awk, you can use the -a option and output will
look more like the earlier example showing just HwTCPRATE.]
6.3 Dialog Menu
The Dialog Menu is the classic interface to
administering the Honeywall CDROM. It was originally used in the Eeyore
version. The new version is very similar, except it has new features added
(and is blue instead of red).
While this interface has the advantage of working locally on the system, it has
the disadvantage of not being very user friendly.
To start the menu, execute the command menu. (It is in the PATH,
but if you need to know, its location is /usr/sbin/menu.) You can have
multiple instances of the menu running at the same time, but it is not
advised to be in the Honeywall Configuration menu more than once (as
there is no locking of variables and some scripts may not be
in sync with changes made in another menu, or the Walleye admin
interface for that matter.)
The menu is pretty
self explanatory. Whenever you highlight an option, you will see a description
of that option in the lower-left hand corner. To find out what all the
different options are, refer to the Dialog Menu
document. To learn how the Dialog Menu works and the commands it
executes, refer to Section 9: Internals
section. The one key point to remember is that your changes in the Dialog
Menu do NOT take effect until after you "Return to previous menu". The reason
for this is the Dialog Menu is collecting all changes within a sub menu and then take
appropriate action when you "Return to previous menu". To take appropriate
action on each and every change would likely get frustrating with all of the
stopping and starting of services between each option.
6.4 Web Interface
The Web Interface is the new and improved (at least we hope :)
interface to administering the Honeywall. It allows you
to remotely point and click the day to day administration of your system. This system
is designed to be the primary method for remote administration. The web
interface has all the functionality of the Dialog Menu and more. Not only can
it be used for administration, but for full system data analysis.
As such, we have given it the sexy name Walleye (either for
"Eye on the Honeywall", or in tribute to the late Douglas Adams: So long, and thanks for the fish.) From this point
on, any reference to Walleye means the web based user interface that
is used for Honeywall administration, configuration, and data analysis. This is
not enabled by default, unless you use the automatic configuration features.
Most users will have to enable it from the Dialog Menu.
To enable Walleye, go to your Dialog Menu and select option
"4: Honeywall Configuration", then "3: Remote Management", then
"11: Walleye". From here you will enable the Walleye
functionality, including Argus and the web server, which will listen on port
443 (HTTPS using SSL). Before connecting to the Wallye interface
for the first time, you will need to get the SSL certificate.
This is used to confirm the identity of Walleye webserver the first time
you access it with your browser.
Make sure that during your initial setup process you allowed inbound
management connections to port 443 on the management interface and from
the IP address of your management system(s).
Once Walleye is up and running, you can connect to it using your
browser (we currently test and support either Firefox or IE). Also, ensure
cookies and JavaScript are both enabled (we know, we prefer not to use these either,
but we figure if you can't trust the webserver, you probably should not be using
the Honeywall CDROM: Create a profile just for the Walleye, to be
safe. :). The URL to Walleye should look like
https://ip-address-mgmt-interface
You will get a login screen. Just like the
operating system, the default user account for Walleye is the user roo with the
default password honey. Upon your first login you will be requested to change
the password. Note, Walleye comes with a password checking
mechanism to enforce good passwords (its pretty strict). Be sure to have a good
password ready before you login for the first time. It requires
- 8 or more characters
- One character must be a capital letter
- One character must be a number
- One character must be a symbol
Once you have set the password, be advised the user interface has a lockout
feature. After 3 failed login attempts, that user will be blocked for 15 minutes.
After 15 minutes have expired, you will be able to login again.
Once you are successfully logged in, you can begin
to adminster the system. First, you will want to select "System
Admin" from the GUI. This will take you to a window that has
very similar options to the Dialog Menu, but is web based.
There are several difference between the Dialog Menu and the Walleye.
The first is Walleye does not have the ability go through the
initial setup, it cannot take you through the interview process and
reconfigure your system. You have to use the Dialog Menu to do that.
The second difference between the two is the addition of the
"Manage Users" option. This
allows you to add, modify, or delete users that can
have access to "Walleye". Users can be assigned one of three roles.
- User: Has read access to only the data analysis section.
- Admin Read-Only: Has read to the data analysis and status sections.
- Admin: Has read and write access to everything.
6.5 Operating System
Managing the operating system should be similar to any Fedora Core
installation. However, there are some minor differences due to the
modifications we have made for honeywall functionality. The biggest
difference can probably be found in the startup scripts. A variety of
scripts have been added. These scripts replace some of the existing
startup scripts, so they should no longer be used. The reason the non-used
startup scripts are still on the system is they are part of the RPM
packages. These scripts are
For Snort, use '/etc/init.d/hwflow-snort', do not use '/etc/init.d/snortd'
For MYsql, use '/etc/init.d/hflow-mysqld', do not use '/etc/init.d/mysqld'
For Apache, use '/etc/init.d/walleye-httpd', do not use '/etc/init.d/httpd'
6.6 Updates
Unlike the previous Honeywall CDROM Eeyore, with the new Roo
you should have to burn and install the CDROM only once. After that
the entire operating system and all functionality is installed on the
local hard drive. To keep the system current, you use the system
tool yum This tool can be used to query a
remote source for updated RPM's, and if found download and install them,
ensuring your systeme is up to date in a fully automated manner. You can
find all yum configuration files at
/etc/yum.repos.d/*
After doing a fresh install you simply type (as root) yum update
in order to update the entire honeywall. This includes both OS and
Honeywall functionality. Yum will go out to the
Fedora website and download/install all the latest OS updates and
packages. In addition the Honeynet Project maintains honeywall specific
RPMs in our own yum repository (repo). Specifically these are the
packages that transpose Fedora CORE 3 (roo's base OS) into a fully
functioning Honeywall. RPM updates come from one of the following repos:
By default, yum is not enabled to happen automatically every day.
To enable this feature, you will want to use the chkconfig command.
This will ensure yum will update your system every day at
0402 hours(default):
chkconfig yum on
/etc/init.d/yum start
This will continue every day, including after reboots, until you:
chkconfig yum off
For security purposes, all RPMs are signed by their organizations
respective GPG key (including all Honeynet Project RPM packages). Rather
than install static public RPM GPG signing keys for each of
the repos roo depends on, we decided to place links to respective keys for
each repo. This should make it easier to retrieve new keys should the repo
maintainer need to re-key at some point in the future.
What this means is that the first time yum updates or installs RPMs
from a given repo you will be prompted to "Confirm"
download/install of a public RPM GPG signing key for the repo you
are receiving files from. Once you have confirmed the key, just hit "y" to
continue.
For those of you new to Yum, here are some basic Yum commands. You can also learn
more at
http://www.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO/.
- Update the entire system: yum update
- Install new package "foo": yum install foo
- Search for package "foo-something": yum search foo-* (regexes are ok here)
- List available updates (but don't install them): yum check-update
- Update only package "foo": yum update foo
<-Back Home Next->
|
