Installing And Using OpenVZ On CentOS 6.0

View the original article here

Using Version Control For Your /etc Directory With etckeeper And Bazaar On Debian Squeeze

This tutorial explains how you can store the contents of your /etc directory in a version control system (VCS) with the help of etckeeper on Debian Squeeze. etckeeper hooks into Debian's package manager apt so that whenever you install/remove a package with apt, etckeeper will commit all changes to the /etc directory to your VCS; it also tracks file metadata such as permissions which is important for files such as /etc/shadow. Using etckeeper, you can go back to a previous version of /etc if an update has overwritten valuable configuration files. Not only will etckeeper track apt's changes to /etc, it will also do a daily auto-commit so that your manual changes go to VCS as well; in addition to that, you can do commits at any time manually.

Comments (0)
You must be logged in to post a comment. Please register if you do not have an account yet.

View the original article here

Using Firewall Builder Settings to Manage Firewalls

Last week we looked at managing rules in Firewall Builder. In the last installment of our series on Firewall Builder, I'll take a look at managing firewall settings with the Firewall Builder.

We've covered quite a bit already about Firewall Builder This week, I want to open up the Firewall Settings window to illustrate how much further a Firewall can be flexed, stretched, and configured — all from a single, user-friendly window.

As should be expected, getting to the settings window is simple — so long as it's not overlooked. What I'm talking about is not the Firewall Builder Preferences. The settings I am referring to actually apply to individual firewalls. So, in order to reach the settings window, a firewall must be open within Firewall Builder. Once the firewall is open (double click on the firewall to edit it),

When the Firewall Settings button is clicked, it will open the settings window only for the currently open firewall.

The Firewall Settings button is located near the center of the window. Click that button to get to the settings in question. Let's examine this window, tab by tab.

The compiler tab (see Figure 2), as the name implies, deals with the compiling settings for the firewall. There are a few options, in particular, that I want to point out. The first option is 'Assume firewall is part of "any"'. If this option is checked, rules that are configured with "Any" in the Source or Destination fields will also generate rules for traffic destined to or from the firewall. In iptables this will result in a rule being added to either the OUTPUT or INPUT rule chain.

The configuration options here will be automatically compiled into the firewall in question.

Another important option is 'Always permit ssh access from the management workstation with this address'. This helps prevent situations where a user cuts off their access to the firewall because there isn't a rule allowing SSH access to the firewall itself. If this option is enabled, enter either a single IP address or a network using CIDR notation (e.g. 192.168.1.0/24). When the firewall is compiled, Firewall Builder will automatically add a rule permitting SSH access to the firewall from this IP address or network at the top of the generated rules.

The Installer Tab has three settings that you should pay close attention to. The first is the option "Directory on the firewall where script should be installed". This should match a directory that exists on the firewall where the firewall script should be run. Typically for iptables firewalls the directory is either /etc/ or /etc/fw (if this directory has been created on the firewall).

The second setting to pay attention to is the username. This is the username that will be used when Firewall Builder connects to the firewall to install the generated firewall script. If the username configured in the installer tab does not have administrative rights, the installation will fail. So in this section, enter a username that does have admin rights and can actually install firewall rules (if the user can use the iptables command, that user most likely has rights enough.) If the username setting is left blank the user will be prompted to enter the username when they run the install wizard.

Finally, in the installation tab, there is the additional command line parameters for both ssh and scp options. This is an incredibly helpful should ssh and/or scp use alternative ports. Should that be the case, simply add something like -p 2222 to instruct ssh to use non-standard port 2222 (instead of standard port 22).

The next tab that should be of use is the Prolog/Epilog. This tab allows for the addition of script commands in bash format to be added either to the beginning or to the end of a firewall script. For example, the amount of traffic being served up by an HTTP server can be controlled by using the Traffic Control command (tc). The commands would need to be added to the epilog (end) of the firewall as shown in Figure 3.

 

Prolog scripts can be added in three different locations, whereas Epilog scripts can only be added to the end. Make sure that the commands entered can be run as a bash shell script without any errors.

Finally, the Script Tab offers a number of setting options, of which there are four settings to pay close attention to. It is important to note that this tab directly effects the script generated for the firewall being configured and not the machine that Firewall Builder is running on. The first is "Configure Interfaces of the firewall machine." If this option is not checked the script generated will not include shell code necessary to manage IP Addresses. By default this is on.

The next option in the Script tab is for VLAN interfaces. If the checkbox for "Configure VLAN interfaces" is checked the script generated by Firewall Builder can create and remove VLAN interfaces for the firewall. If left unchecked, this feature will not be available. In other words, if VLAN interfaces are necessary, make sure this check box is checked. This same option is available for bridged interfaces. If the firewall to be installed needs to configure any bridge interfaces, the check box for "Configure bridged interfaces" must be checked, otherwise bridged interfaces will not be available to the firewall machine.

Finally, "Use iptables-restore to activate policy" is the last option I will deal with. There are two ways in which generated scripts can be loaded:

Using iptables command: This command will load the rules of a firewall one at a time.Using iptables-restore: This command will activate the rules of the firewall all at once.

The biggest difference between the two methods, with regard to Firewall Builder, is that the iptables-restore is a much faster process. This can make a significant difference when the firewall becomes longer and more complicated. If, on the other hand, a firewall is short and basic, the standard method of running iptables commands line-by-line will work just fine.

I have only scratched the surface of the Firewall Builder Firewall's Settings window. Although I have touched on many of the more important options, it would behoove you to comb through all of the tabs to make sure there aren't options available that would make a difference in a particular firewall. But the settings options illustrated here are those that most users will want to at least examine for their firewall rules, before they are compiled and installed.

View the original article here

Using Firewall Builder Objects for Linux Firewalls

Firewall Builder is one of the most powerful and user-friendly firewall creation utilities available for Linux. One of the many reasons Firewall Builder is both powerful and easy to use is its objects feature. Objects are reusable elements that can be added and removed from firewall rules by dragging and dropping the object into firewall rules. Firewall Builder comes with plenty of pre-defined objects that can be used right away, and also makes for easy creation of new objects.

Objects are so crucial to the ease of use and understanding of Firewall Builder, I want to dedicate this entire article to the creation, editing, and use of objects. With a sound understanding of objects under the belt, any one should be able to create secure and flexible firewalls to fit nearly any need.

Firewall Builder stores objects in what are known as Libraries. By default Firewall Builder includes two Libraries.

Standard: The predefined objects that can be dragged and dropped into firewalls. These objects can not be edited.User: An empty pre-categorized library where users can add their own objects and then drag and drop them into firewalls.

To select a library, click on the Library drop-down (see Figure 1) and select either the Standard Library or the User Library. Let's say, for example, the firewall being created will be used to secure an HTTP server. Why bother creating TCP/UDP service objects when they already exist in the Standard Library? Simply open up the Standard Library (click the Library drop-down and click Standard), expand the Services entry, Expand the TCP entry, and the HTTP and HTTPS entries will be available. Drag and drop all of the related entries necessary for the new firewall into the desired rules for the firewall.

Another way to find the object is to use the convenient filter feature, located just below the Library drop down, that lets you quickly filter the objects in the tree to find what you are looking for.

 

It is also possible to create a Custom Library by clicking the drop-down to the left of the Libraries drop-down and selecting New Library.

In my previous article I discussed how to create objects specific to firewall used for SSH connections into a host. The methods discussed in that article describe the creation of objects for the User Library. One of the nice features of Firewall Builder is that those objects can be then reused in other firewalls. So even if the objects were initially created for the SSH firewall, they can then be re-purposed for a firewall focused on a Web server. That doesn't just apply to services; any of the objects created in a previous firewall can be re-used over and over.

Don't think objects are limited to services or addresses. In fact quite a few object types can be created and used, and here is a listing of the types:

Address Ranges: A range of addresses can be configured into a single object.Address Tables: This is an address-based object that can be created when a range of addresses is needed but the actual addresses are not known when the firewall or policy is being written. The Address Tables object has an added feature which allows for the object to be loaded at either compile time (during firewall compilation) or during run time (when Firewall Builder runs the firewall script). More on this in a moment.Addresses: A single address that can be used for an interface, source, or destination (such as a host).DNS Names: This object represents a DNS "A" or "AAAA" name and resolves to an IP address during either compile or run time. What this highlights is the intelligence of the compiler and its ability to resolve addresses to names during compilation.Groups: A group is a container that holds references to multiple objects of the same or similar type (Addresses, Address Ranges, Network Objects).Hosts: A host object represents hosts on a network: Desktops, Workstations, and any other network node that has a network address.Networks: This object describes an IP network or an entire subnet.

A group is a container that holds references to multiple objects of the same or similar type (Addresses, Address Ranges, Network Objects). When a new group is created (see Figure 2) the member objects can either be created from within the configuration of the group itself (click the "Create new object and add to this group" drop-down) or objects can be dragged and dropped into the group from one of the Libraries. During compile time the Firewall Builder compiler will determine if a group should be expanded and multiple chains needed or if a single chain can take care of the group.

 

Make sure the name given to the group adequately describes the purpose of the group so that group can be re-used without having to examine its contents.

Address Tables are incredibly handy. Essentially this object allows you to define a list of addresses and/or networks into a rule, even if the actual addresses are unknown at the time the rule is created. What must be done, however, is (when the addresses are known) a file is created that will house the addresses. That file name and location is configured into the Address Tables setup (see Figure 3).

To configure the file the addresses will be read from click the Choose File button and then navigate to file.

When you have configured the Address Table to be aware of the file containing the addresses, it is also possible to directly edit the file from within Firewall Builder. To do this click the Edit File button and the Firewall Builder Script Editor will open (see Figure 4).

Figure 4
fwbuilder_script_editor.png

You can create a file using the script editor, just enter the full path to the file and click Edit. The file will be created when you click Save.

The services objects are all fairly self-explanatory (Custom, Groups, ICMP, IP, TCP, UDP, Users). The only Service that may need explanation is the TagServices. The TagServices object allows packets to be tagged by one rule and then acted on by another rule. Packet tagging is fairly complex. Essentially a TagServices object is created and configured with either a tag number or string. To match a tag in a rule just drag and drop the service object to the Service column of the rule. To create a rule that sets the tag, set the Action to Tag and drag and drop the TagService to the bottom of the screen where it says "Drop object here."

It is also important to know that TCP and UDP Services can have definitions for both source and destination ports configured and that if a configuration of 0 is used all ports will be matched. Say, for example, it is necessary to create a service for HTTP using port 8080 as the destination, but a specific source port is not necessary. To do this enter 8080 as the destination port and leave the source port as is (set at 0).

A handy trick to know is how to locate where a service is being used within a firewall. With a firewall open, navigate to a service (either from the Standard or User Library) and right-click the service. When the context menu opens select Where Used. A pane will open in the lower half of the Firewall Builder window (see Figure 5) that will, upon clicking the Find button, display where the service is used within the firewall. This is especially handy when trying to troubleshoot a particular firewall.

 

If any child services were created from the original, make sure to search for those as well.

The creation and manipulation of objects serves as the foundation and building blocks which all firewalls are created within Firewall Builder. Because objects make the creation of firewalls more efficient and user friendly, it is important to understand how they can be best utilized. When used correctly, Firewall Builder objects help to make the administration of firewalls a far easier task.

View the original article here

Installing And Using OpenVZ On CentOS 5.6

In this HowTo I will describe how to prepare a CentOS 5.6 server for OpenVZ. With OpenVZ you can create multiple Virtual Private Servers (VPS) on the same hardware, similar to Xen and the Linux Vserver project. OpenVZ is the open-source branch of Virtuozzo, a commercial virtualization solution used by many providers that offer virtual servers. The OpenVZ kernel patch is licensed under the GPL license, and the user-level tools are under the QPL license.

This howto is meant as a practical guide; it does not cover the theoretical backgrounds. They are treated in a lot of other documents in the web.

This document comes without warranty of any kind! I want to say that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

In order to install OpenVZ, we need to add the OpenVZ repository to yum:

cd /etc/yum.repos.d
wget http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ

The repository contains a few different OpenVZ kernels (you can find more details about them here: http://wiki.openvz.org/Kernel_flavors). The command

yum search ovzkernel

shows you the available kernels:

[root@server1 yum.repos.d]# yum search ovzkernel
...
ovzkernel.i686 : Virtuozzo Linux kernel (the core of the Linux operating system)
ovzkernel.x86_64 : Virtuozzo Linux kernel (the core of the Linux operating system)
ovzkernel-PAE.i686 : The Linux kernel compiled for PAE capable machines.
ovzkernel-PAE-debug.i686 : The Linux PAE kernel compiled with debug config
ovzkernel-PAE-devel.i686 : Development package for building kernel modules to match the PAE kernel.
ovzkernel-debug.i686 : The Linux kernel compiled with debug config
ovzkernel-debug.x86_64 : The Linux kernel compiled with debug config
ovzkernel-devel.i686 : Development package for building kernel modules to match the kernel.
ovzkernel-devel.x86_64 : Development package for building kernel modules to match the kernel.
ovzkernel-ent.i686 : The Linux kernel compiled for huge mem capable machines.
ovzkernel-ent-debug.i686 : The Linux ent kernel compiled with debug config
ovzkernel-ent-devel.i686 : Development package for building kernel modules to match the ent kernel.
ovzkernel-xen.i686 : The Linux kernel compiled for Xen VM operations
ovzkernel-xen.x86_64 : The Linux kernel compiled for Xen VM operations
ovzkernel-xen-devel.i686 : Development package for building kernel modules to match the kernel.
ovzkernel-xen-devel.x86_64 : Development package for building kernel modules to match the kernel.
[root@server1 yum.repos.d]#

Pick one of them and install it as follows:

yum install ovzkernel

This should automatically update the GRUB bootloader as well. Anyway, we should open /boot/grub/menu.lst; the first kernel stanza should now contain the new OpenVZ kernel. The title of that kernel just reads "CentOS". I think it's a good idea to change that title and add something with "OpenVZ" to it so that you know that it's the OpenVZ kernel. Also make sure that the value of default is 0 so that the first kernel (the OpenVZ kernel) is booted automatically instead of the default CentOS kernel.

vi /boot/grub/menu.lst

# grub.conf generated by anaconda## Note that you do not have to rerun grub after making changes to this file# NOTICE: You have a /boot partition. This means that# all kernel and initrd paths are relative to /boot/, eg.# root (hd0,0)# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00# initrd /initrd-version.img#boot=/dev/sdadefault=0timeout=5splashimage=(hd0,0)/grub/splash.xpm.gzhiddenmenutitle CentOS OpenVZ (2.6.18-238.5.1.el5.028stab085.5) root (hd0,0) kernel /vmlinuz-2.6.18-238.5.1.el5.028stab085.5 ro root=/dev/VolGroup00/LogVol00 initrd /initrd-2.6.18-238.5.1.el5.028stab085.5.imgtitle CentOS (2.6.18-238.el5) root (hd0,0) kernel /vmlinuz-2.6.18-238.el5 ro root=/dev/VolGroup00/LogVol00 initrd /initrd-2.6.18-238.el5.img

Now we install some OpenVZ user tools:

yum install vzctl vzquota

Open /etc/sysctl.conf and make sure that you have the following settings in it:

vi /etc/sysctl.conf

[...]net.ipv4.ip_forward = 1net.ipv4.conf.default.proxy_arp = 0net.ipv4.conf.all.rp_filter = 1kernel.sysrq = 1net.ipv4.conf.default.send_redirects = 1net.ipv4.conf.all.send_redirects = 0net.ipv4.icmp_echo_ignore_broadcasts=1net.ipv4.conf.default.forwarding=1[...]

If you need to modify /etc/sysctl.conf, run

sysctl -p

afterwards.

The following step is important if the IP addresses of your virtual machines are from a different subnet than the host system's IP address. If you don't do this, networking will not work in the virtual machines!

Open /etc/vz/vz.conf and set NEIGHBOUR_DEVS to all:

vi /etc/vz/vz.conf

[...]NEIGHBOUR_DEVS=all[...]

SELinux needs to be disabled if you want to use OpenVZ. Open /etc/sysconfig/selinux and set the value of SELINUX to disabled:

vi /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - SELinux is fully disabled.SELINUX=disabled# SELINUXTYPE= type of policy in use. Possible values are:# targeted - Only targeted network daemons are protected.# strict - Full SELinux protection.SELINUXTYPE=targeted

Finally, reboot the system:

reboot

If your system reboots without problems, then everything is fine!

Run

uname -r

and your new OpenVZ kernel should show up:

[root@server1 ~]# uname -r
2.6.18-238.5.1.el5.028stab085.5
[root@server1 ~]#

Installing And Using OpenVZ On CentOS 5.6 - Page 2

View the original article here