Using your IPCop for web hosting/mail hosting

Given the instructions from the previous article, you should have a full installation of IPCop running. The current focus remains two-fold: to get your server in the Orange (DMZ) segment of your IPCop Network and opening up the ports on your firewall to allow web traffic to it.

Additionally, our second goal in this article will be securing our (application layer) web traffic, email and personal privacy with a wonderful add-in, called Copfilter.

As we detailed in part one, I suggested the 192.168.10.x network for our “Orange” DMZ segment. In this part of the network I will place hosts that I want visible to the outside world. Port forwarding will permit the flow of traffic from external RED (DHCP interface/network) to DMZ ORANGE network.

Orange Network Requirements

• Installed and configured server with the Distro of your choice with the email (SMTP & POP3 or IMAP and webserver of your choice. Free & Open Source Software (FOSS) is all about choice so pick what fits your needs..
• This orange network server must have a static IP address and not be on DHCP. For the sake of this article, we are using the static IP of 192.168.10.25 for our single internal ORANGE hosting server.

Secure your Orange Network Hosts

• Security is a process not any one tool or technology. Rather, it is many tools, technologies and processes. Consider a holistic view.
• Remember to consistently patch and monitor logs patches are an important measure to mitigate known vulnerabilities.
• Make sure you fully patched, secured and backed up any host before you expose it to the Internet.
• The best security is a layered approach so consider using a HID (Host Intrusion Detection), chroot, xinetd and Tcpwrappers to name a few.
• Shut down any unnecessary network services on this node.
• Join the mailing lists or RSS feed for the Free/Open Source applications you are using and general security mailing lists so you are sure to be aware of vulnerabilities and issues that might arise. Also check out CERT for a general mailing list or RSS feed on security vulnerabilities. http://www.us-cert.gov/current/

Secure your Green Network

• Don’t have a false sense of security just because you have strong and extensive IPCop/Copfilter configuration. Be sure to secure ALL of your machines. Consider a holistic view of security.
• Consistently patch your internal green nodes
• Have a Anti-Virus/Malware Scanner and Anti-Spyware Defense. In my view that extends to ALL Operating Systems.
• Enable a software firewall on your machines.

Hosting a server on a dynamic connection

As you are using a cable modem that gives your RED IPCop network interface a dynamic DHCP address, you will need to set up Dynamic DNS services to resolve to this host via a human usable form, other than IP Address.

NOTE – Some ISPs block TCP port 80 (HTTP) 110 (POP3) and 25 (SMTP). To navigate around this, you can purchase port forwarding services from some of these dynamic DNS providers, run services on different non-blocked ports or upgrade to another provider. For the sake of this article we assume you have no ISP blocked ports.

Setting up Dynamic DNS

Along with your dynamically assigned IP address (RED), you will want to use a Dynamic DNS service to be able to allow external access to your external web/mail. Setting up Dynamic DNS with IPCop is easily achieved. Simply pick a Dynamic DNS provider listed in the IPCop DYNDNS settings.

• Go into your IPCop settings in Service Pulldown — Services >> Dynamic DNS and under >> Add a host. Pick one of these supported DYNDNS providers.
• Open up your favorite browser and go to the DYNDNS provider you have chosen from the list above and register with them.
• Return to your IPCop web administration GUI and add the information in to your IPCop settings in Service Pulldown — Services >> Dynamic DNS.
• Now return to your IPCop web administration GUI and fill in the information as listed below and then click Add. It will then display under “current hosts”.

What is Copfilter

An amazing project by open source developer Markus Madlener, to extend his IPCop’s capabilities to the application layer (see OSI Model). Copfilter greatly enhances the capabilities of the already powerful IPCop by offering the jaw dropping and impressive large list of capabilities:

• POP3/SMTP Scanning – via P3Scan and ProxSMTP which allow for scanning of incoming and outgoing Email.
• HTTP Scanning – via HAVP which is a powerful HTTP scanning engine for scanning and securing your web traffic.
• FTP Scanning – via frox which allows for proxying of FTP traffic.
• Privacy Protection – via Privoxy which is an extremely powerful HTTP privacy protection filter which filters and or removes cookies, web ads, pop-ups and other annoying Internet junk.
• Antivirus Scanning – via ClamAV or F-Prot which can be used to scan your traffic for the ever prevalent malware. Please note F-Prot is a commercial product and you have to acquire a license to use it. This article utilizes the FOSS email scanner ClamAV.
• AntiSpam – via Spam Assassin, Vipul’s Razor, DCC, renattach, RulesDuJour which coupled together make a very effective anti-spam defense.
• Process Monitoring – via Monit which allows you to monitor all of these processes and restart them as needed.

Why Copfilter?

You might ask yourself, if I have a IPCop firewall why would I need Copfilter? As a network security mechanism, the firewall has undergone a serious metamorphosis from a simple packet filter that only understood little of what it carried across the wire, to fully stateful inspection mechanisms that understand layer 5-7. This a far cry from the days of a simple packet filtering router or even a stripped down set of ipchains. And as security is not one technology, process or technique alone, but many of them, Copfilter is another powerful mechanism of defense in protecting your application layer.

Installing Copfilter

IPCop does not contain add-on binaries by default so they need to be copied via SCP to your IPCop. Then you will be logging in securely via SSH to your IPCop to install these binaries.

Turn on SSH on your IPCop

• Via the Webgui -> System -> Ssh Access
• Then click Save

NOTE – It is recommended that you shut off SSH access after you finish copying this code as SSH has many exploits.

Enable Squid on your IPCop

Via the Webgui go to -> Services -> Proxy

• Enabled on Green
• Transparent on Green
• Then click Save.

SSH and SCP Clients

Depending on your OS you may or may not have a native SCP or SSH client on your machine. Note the port number as TCP port 222 and NOT the default SSH/SCP port.

GNU/Linux, Unix, BSD & OSX Clients – Command Line #

Command Line SCP

scp -P 222 <Copfilterpackage_version.tar.gz root@ipcop_green_address>:/root

Command Line SSH

ssh -p 222 -l root ipcop_green_address

Graphical SCP/SSH –>

If you are wary of the command line or not interested, alternatively, there are several GUI clients in almost every OS. I will not address each and every one as they are so easy to use, simply requiring a drag and drop, or point and click operation.

OS X Clients –>

Cyberduck

http://cyberduck.ch/

Fugu

http://rsug.itd.umich.edu/software/fugu/

Windows –>

WinSCP – SCP Client

http://www.winscp.net/

Putty – SSH Client

http://www.putty.nl/

OpenSSH for Windows

http://sshwindows.sourceforge.net/

*NIX –>

gFtp

http://gftp.seul.org/

Installing Copfilter

After you have SCP copied the Copfilter-x.x.tgz file to /root on your IPCop as detailed above you are now ready to install it.

SSH into your IPCop with whatever client you possess on your respective Operating System.

MD-What?

Takes an MD5 to assure that the code you downloaded is not altered or corrupted by an external source. Doing this is a simple step verifying that what you have the original, legitimate binary.

Linux/UNIX MD5

Md5sum is available in GNU/Linux and Unix by default

md5sum Copfilter-x.x.tgz and compare the output to what is listed on the download link as the MD5.

Microsoft Windows

Windows users can use the easy to use and GPLd wxChecksums or MD5Summer. Both are FOSS software which is freedom geared and light on cost.

Apple OS X

Apple users will need to open up a terminal window and type md5 Copfilter-x.x.tgz to verify the file.

Extract and Install the Binary

• cd /root
• tar xzvf Copfilter-x.x.tgz (change x to your version number)
• cd Copfilter-x.x.x
• ./install

Follow the prompts and you are all done. Reboot your IPCop and to be safe empty your browsers cache. After rebooting your IPCop you should see the Copfilter navigation item on the right most top part of the screen (next to the IPCop penguin).

Initial Copfilter Configuration

Go to Copfilter -> Email and configure your email address, SMTP server and then save those settings. The email address is your (root or administrator) email address and it will be used to notify you of updates and other important Copfilter messages.

IMPORTANT – It is strongly recommended that you READ the Copfilter documentation to have an in-depth understanding of the configuration options that you choose to implement. RTFM before you design and definitely before you deploy.

Monit – Monitoring Copfilter

This service enables you to monitor the core services of the Copfilter application. It provides you some resilience by automatically restarting applications should they fail.

Your Configuration Monitoring

• Go to Copfilter >> Monitoring

• Monitor all enabled services ON

• Then click on Save settings (and restart service)

Copfilter Configuration Options

In controlling the three network services we are going to have ingress (ingoing) and egress (outgoing) control of in our IPCop/Copfilter configuration we have many granular options. Copfilter is going to be filtering our HTTP traffic, POP3, and SMTP traffic. The wonder of the Copfilter add-on is the plethora of options one can chose to deploy our configuration is of course only one of the many.

Copfilter – POP3 configuration – P3Scan

The Post Office Protocol Version 3 is the industry standard for receiving email. The goal of our configuration is to block spam/malware from being received via our email clients.

To access these setting go to Copfilter >> POP3 configuration

P3Scan Configuration

The following options detail those to be turned ON and all others will be left in the default OFF configuration.

• Enable P3scan on incoming traffic on Green ON
• Enable P3scan on incoming traffic on Orange ON
• Add Copfilter Comment to Email Header
• Quarantine Spam if … *** OFF
• Tag Spam in Emails and modify the subject ON
• Stop Virus email and send virus notification instead ON
• Send a copy of virus notification to Email address ON
• Quarantine virus infected emails ON
• Remove emails in quarantine if older than (in days) 7
• Then click on Save settings (and restart service)

The net effect of this configuration will be an aggressive stance on scanning, dropping and notifying you of the spam/malware, before it reaches your internal network.

Copfilter – SMTP configuration – ProxSMTP

Simple mail transfer protocol is the standard for email transmission on the the Internet today. With the power of Copfilter one can get very granular on controlling the flow of mail message to and from our network. The goal of our configuration is to block spam/malware from being sent/received via our email clients.

To access these setting go to Copfilter >> SMTP configuration

The following options are to be turned ON and all others will be left in the default OFF configuration.

SMTP Filtering Configuration

• Enable ProxSMTP to filter outgoing traffic on GREEN ON
• Enable ProxSMTP to filter outgoing traffic on ORANGE ON
• Add Copfilter Comment to Email Header ON
• Enable ProxSMTP to filter incoming traffic on RED
• Email Server is located in network ORANGE
• Email Server IP Address 192.168.10.25
• Red IP Alias Ethernet Interface – eth2:1
• Tag Spam in emails and modify the subject ON
• Stop virus emails and opt. Send virus notification instead ON
• Send user a virus notification ON
• Use Copfilter Whitelist and Blacklist ON
• Remove emails in quarantine if older than (in days) 7
• Then click on Save settings (and restart service)

NOTE – Choices of the ProxSMTP on RED interface entails 2 options:

• RED scanning ON – Copfilter manages the creation of Iptables rules so these are not needed to be created manually through IPCop.
• RED scanning OFF – Copfilter with portforwarding rule to orange mail server with scanning done at the server. I.e. you could do your ingress smtp scanning on the Email server itself & not with Copfilter.

This configuration will be an proactive stance on the capturing, quarantining and deleting malware before it infect our trusted machines in the GREEN network. With quarantining ON it is recommended that an administrator be very responsive to the systems warnings about quarantine Spam, and process consistently, or it will be deleted on a weekly basis. I would not recommend keeping a Spam Quarantine setup if you are short on disk space and or want to increase this interval beyond one week. If you do you run the risk of filling up your disk. Also as whitelisting and blacklisting has been turned on remember to add in your whitelisted domains (trusted email sources) and blacklisted (domains you do not trust or want spam from).

HTTP Scanning – HAVP/Privoxy

HyperText Transfer Protocol is the protocol we use when we are surfing the Internet. HAVP (HTTP Antivirus Proxy) is a proxy server with the ClamAV anti-virus scanner. This will be crucial in your configuration to scan incoming HTTP traffic and keep malware off your machines.

To access these setting go to Copfilter >> HTTP Filter

HTTP Configuration

The following options are to be turned ON and all others will be left in the default OFF configuration.

• Deny access to HTTP traffic ON
• Enable Transparent mode ON
• Filter HTTP traffic for Internet Junk ON
• Then click on Save settings (and restart service)

This configuration will allow for malware to be filtered out at our IPCop box, such as browser exploits, phishing attempts and viruses. Additionally, ads, banners and other Internet advertising junk with Privoxy.

With web banners and such that are blocked you will either see the item labeled “Advertisement” or an image of a checkered pattern indicating it has been blocked. If you hate ads as much as do I you can get an add-on for Firefox called Adblock that will allow client side blocking as well. Adblock

AntiSpam – SpamAssassin and Rules Du Jour

Spam Assassin will help your email server identify and filter Spam before it reaches your email client inbox. SpamAssassin uses Bayesian filtering, DNS blocklist, header and text analysis and collaborative filtering databases to keep your Spam at a minimum. Please note that the more filtering you do before delivering to the client the higher the load on the server.

• Rules Du Jour is a simple back script which will download new versions of Spam Assassin rules. This is very helpful in keeping your anti-spam defense in optimal shape.
• Razor is a distributed, collaborative spam detection and filtering network.
• DCC or Distributed Checksum Clearinghouse is an anti-spam content filter.
• DNSBL are DNS Blacklists or ban lists based upon DNS entries of known spammers or known nodes/networks that once emanated Spam.

To access these setting go to Copfilter >> AntiSpam configuration

AntiSpam Configuration

The following options are to be turned ON and all others will be left in the default OFF configuration.

• Enable Spamassasin ON
• Score required to identify email as spam 6
• Send daily spam digest ON
• Razor, DCC, DNSBL ON
• Rules Du Jour – ON
• Automatic Update Enable every 1 days
• Then click on Save settings (and restart service)

AntiVirus – ClamAV

ClamAV is an amazing FOSS project virus scanner. Within Copfilter this is used to virus scan email and web traffic for malware.

To access these settings go to Copfilter >> Antivirus

Copfilter – Antivirus Configuration

• ClamAV ON
• Automatic Update – Enable every 24 hours
• Then click on Save settings (and restart service)

The effect of these settings is that ClamAV is going to update its virus definitions on its own and be available for scanning your SMTP/POP3 and HTTP traffic.

Allowing traffic between Different Networks

Please note that there are certain default rules that IPCop implements on your network and be aware of the implications. See the following link for further details.

By default the configuration uses the /etc/rc.d/rc.firewall.local and changes can be made through web GUI or via SSH. Any good firewall by default setup to deny any external connections behind its trusted networks. In IPCop speak that means that there is no ingress (incoming) access by default from the RED interface/network to any other Network. By default access from ORANGE to RED is Open so there is no need for any special configuration in this example. If you for whatever reason need access from your Orange “DMZ” to Internal GREEN you can define rules via DMZ Pinholes.

IPCop Port Forwarding – HTTP

As detailed above SMTP and POP3 rules are created by Copfilter are automatically created. As for HTTP (RED to ORANGE) it is NOT so you have to create it in Port Forwarding as below. If you would like to open other ports to external access (ex. FTP, SSH) please be aware the services should be hardened and security as much as possible (see layered approach I detail above).

Copfilter Test & Log

The most obvious way is via surf the web. Send and receive a test email. The Copfilter Test & Log page can help you ascertain if your configuration is proper. The tests listed are very self-explanatory in that you can examine your Email/Spam defense by clicking on the buttons in the Test POP3 & SMTP Scanning section. Below is the Test HTTP & FTP Scanning section which you can click on to verify the functionality of your HAVP HTTP virus scanner by clicking on the link to the Eicar “test” virus. This page will come up blocked with the default HAVP message to show you that your HTTP is now secured from common malware, phishing attempts, and other threats.

Sending and testing the variety of email options on the test page will allow you to verify your SMTP/POP3 configuration. If you can send and receive your emails and see the following in your email headers — you are all set.

X-Filtered-With-Copfilter: Version 0.82 (ProxSMTP 1.3.91)

X-Copfilter-Virus-Scanned: ClamAV 0.88/1291 – Thu Feb 16 21:15:09 2006

Copfilter Test and Logs Screen

Lastly, your log files are to the right bottom of your Copfilter Test & Log page where you can see all the details of your Copfilter configuration.

Bravo! You are good to go! =) Now you can enjoy the fact you are much more secure than when you began this article!

If you like what you see, I welcome you to join our FOSS community. Free and Open Software (FOSS) does not sustain on developers alone but by the work of all sorts in technical writing, support, marketing, graphics, web developers and a multitude of other supporters like you! FOSS is built upon community, so join us and take part in reinventing computing in the positive directions from which we all collectively benefit.

In speaking with Markus I was able to ask him why he was motivated to create Copfilter and he answered, he said: “I created Copfilter to help protect the computers of my friends and family and the greater Internet community.” Markus I don’t think there is a better way to describe the spirit of FOSS. Much thanks to Markus and the entire IPCop Team and all the other projects that made this possible!

..::Check out the FOSS community Projects related to this article ::..

IPCop Homepage –>http://www.ipcop.org

Copfilter Homepage –> http://www.copfilter.org

Copfilter Forum –> http://copfilter.endlich-mail.de/

Incoming search terms:

• perfect firewall linux (4)
• testing linux firewall (2)
• linux firewall latest tech (2)
• ipcop addon havp (2)
• ipfire set aliases (1)
• linux firewall compare (1)
• best linux firewall (1)
• reassign network adaptor ssh plesk (1)
• scan entire network centos (1)
• secure directadmin sshd (1)

This document describes how to install the GNU/Linux GPL IPCop firewall and create a small home office network. In the second installment we cover creating a DMZ for hosting your own web server or mail server and the Copfilter proxy for filtering web and email traffic.

This is intended to be a quick and dirty overview on creating a IPCop firewall and comes without warranty of any kind!

What is IPCop
The IPCop project is a GNU/GPL project that offers an exceptional feature packed stand alone firewall to the internet community. Its comprehensive web interface, well documented administration guides, and its involved and helpful user/administrative mailing lists make users of any technical capacity feel at home. It goes far beyond a simple ipchains / netfilter implementation available in most Linux distributions and even the firewall feature sets of commercial competitors.

Firewalls have had to undergo a tremendous metamorphosis as a result of evolving threats. IPCop is exemplary in offering such a range of default features and even further a large set of optional plug-ins which can provide further functionality.

Some of IPCops impressive base install features include: secure https web administration GUI, DHCP Server, Proxying (Squid), DNS Proxying, Dynamic DNS, Time Server, Traffic Shaping, Traffic/Systems/Firewall/IDS graphing, Intrusion Detection (Snort), ISDN/ADSL device support and VPN (IPSec/PPTP) functionality. As if these base features were not an astounding enough there are dozens of add-ons which can further expand the functionality of your IPCop from Web Filtering to Anti virus scanning.

Pre-Requisites for Your IPCop
IPCop installation generally runs 25 minutes, and you can complete it with relatively modest hardware requirements such as a 386 processor with 32MB RAM and >300MB of disk, and 3 Network Cards (2 if there is no need for a DMZ). If you plan to utilize caching proxy, IDS or other add-ons, consider additional horsepower in terms of RAM/Processor.

Building Your IPCop What you need

• 386 Processor with 32MB RAM, 300MB hard disk and 3 Network Cards
• 2 x 5 port 10/100/1000 switch or a Layer 3 switch
• Network Cables
• Burned ISO CD

Architectural Decisions: Segmentation
One essential consideration you have to make before installing is network architecture (segmentation/address space). IPCop uses color-coding system of Red, Green, Blue and Orange to describe the roles or security levels which an interface/network segment will have in protecting your network. Color coding is logical in that it represents a continuum of network access from restricted to permissive. A RED interface is your untrusted interface/segment like the Internet, whereas Green is the trusted interface/segment of your internal network. Additionally, Blue is for a separate segment for Wireless Devices, while Orange is for a DMZ or where any publicly accessible servers you want available to the Internet. In this case we are only configuring a Green/Red/Orange network installation with 3 network interfaces one of which is your cable broadband providers cable modem (Ethernet).

Understanding and Picking your address space
Before you begin it is important to know how your ISP TCP/IP settings. Does your ISP give you a DHCP address or a static IP address? In many cases simply going to your ISP’s Support page offers you this information. Most ISPs use DHCP to dynamically allocate IP address space so you get a non-static IP address that applies to your RED interface. Make note of the TCP/IP setting your ISP would have you use before you install.
In architecting your IPCop solution you have the choice of setting up NAT (Network Address Translation) network address space. Green, Blue and Orange networks depend entirely on how many nodes or machines you will have on each network. There are 3 network spaces defined by the standards body, IETF, that can be used for these NAT’ed networks and they are:

10.0.0.0 – 10.255.255.255 (10/8 prefix)
172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

If your Green network contains 15 hosts you can use 192.168.1.2-16. Your Green interface will run DHCP and pass out addresses to your internal network in this range. The same logic applies to address space on your Orange or DMZ network select a network space appropriate for the number of hosts/networks you will require.

Installing your IPCop

Verify hardware compatibility at IPCop website.
Download the ISO’s and burn them.
Connect all the physical layer i.e. Ethernet cables, hook up your monitor, keyboard and mouse to the machine that will be your IPCop
Boot off the CD.
Run through the simple prompt-based installation. NOTE: These are all very self-explanatory steps such as selecting your Language. The arrow Keys, Tab and Enter will help you navigate.

Install Process

• Select your language.
• Select your Installation Medium, a CD in this case.
• Configure your network cards The fastest way to configure your network interface cards is by selecting Probe option. If you know the network card information you can choose to your exact interface from Select.

Next, when you are asked enter your Green Interface an address which must be within your chosen address space (192.168.1.x in our example). Enter in place 192.168.1.1 in the IP address field.

Following this, IPCop will format and copy itself to your hard drive. See below.

After the install has completed you will be prompted to reboot and run setup as shown. See below.

Initial Setup
Having installed IPCop we now have to enter some further configuration information in setup for our setup to be complete.

• Enter in Keyboard, Time Zone and Hostname/Domain.
• ISDN Setup As you are not using ISDN you should select to disable it
• Network Configuration Type – Select the Interface configuration you will be running by tabbing to Network Configuration Type and hit the Enter key.

In our case you would select Red / Orange / Green.

Since we have 3 interfaces and only have set up Green, repeat the interface setup options for the Red and Orange interfaces as described above.
Configure the RED interface to use DHCP as this is interface connected to the Internet (i.e. Your ISP). Then configure your ORANGE interface to use the 192.168.10.x address space. For Red tab over to the DHCP box and select it by hitting Enter. So if your Green network will contain 15 hosts you can use 192.168.1.2-16. To set this up simply add in this range 192.168.1.2-16 and tab down to OK.

Password Setup – IPCop has 2 users which you will be asked to setup passwords for the root and admin. Set these both to a strong password > 8 character password that is not a word in any language and contains Caps. A good example would be 1luv19c0p. Root password will be used to log on and add any add-ons or upgrades via SSH. Admin user is used to manage your IPCop day to day.

At the end of the IPCop installation you will be asked to reboot. After reboot go to another machine on your LAN and force your network interface card to update your dynamic (DHCP) address with ifconfig (Linux/Unix) or ipconfig (Windows). Verify you are live and active on the new network you have setup with an address on 192.168.1.x. With this validated connect to secure https web interface of IPCop. Type https://192.168.1.1:445 or https://192.168.1.1:81 and log in as the admin user.

Validate all your settings and connectivity. Then check out all the features you get with this great GNU Open Source Firewall. In the second installment of this how to we will discuss setting up a dynamic DNS, filtering email/web/proxing with Copfilter and allowing access to web/mail server of your choice in the DMZ or orange network. Until then go check out the www.IPCop.org website & Happy Hacking!!

Incoming search terms:

• ipcop snort (10)
• vmware snort network cards (1)
• using an l3 switch with a linux firewall (1)
• ipcop snort addon (1)
• firewall with snort (1)
• ipcop firewall (1)
• ipcop dowload (1)
• how to set plesk firewall for squid (1)
• how to configure ipc op on centos 5 5 (1)
• xen ipcop 2 x (1)

As usual, to create a firewall object I use main menu “Object/New object” which opens a menu of object types:

Figure 4. Creating first member firewall object

Figure 4. Creating first member firewall object

After I choose the type “Firewall”, a wizard used to create new firewall object opens:

Figure 5. Choosing the name, platform and host OS for the firewall object

Figure 5. Choosing the name, platform and host OS for the firewall object

To make things simpler, I am going to use preconfigured template object “web server” that comes with the package. This object represents a machine with one interface “eth0″ and comes with some basic firewall policy that can be useful as a starting point for the firewall configuration for a web server.

Figure 6. Choosing template firewall object

Figure 6. Choosing template firewall object

Template firewall object has IP address that does not match address chosen for this example. The next page of the wizard allows me to change the address and add two more:

Figure 7. Changing ip address of the firewall object

Figure 7. Changing ip address of the firewall object

Once I am done changing ip addresses and click “Finish”, the new firewall object is created and is added to the library of objects that was opened at the moment. In this example this library is called “Cookbook2″. I “floated” the object tree panel to make the screenshot more compact. You can see the new firewall object in the tree, its interfaces and ip addresses, as well as preconfigured policy rule set on screenshot Figure 8:

Figure 8. Firewall object created from the template

Figure 8. Firewall object created from the template

The member firewall object’s interface “eth0″ has only one IP address which is its own, in our example 10.3.14.108. Virtual addresses managed by heartbeat will be added to the cluster object later.

Next, I create the second member firewall linux-test-2 with its own ip address:

Figure 9. Two member firewall objects

Figure 9. Two member firewall objects

Because our firewall objects represent web servers which should never have to forward packets, we should turn ip forwarding off. To do this, double click the firewall object in the tree to open it in the editor, then click “Host OS settings” button and turn IP forwarding off as shown in Figure 10. Turning ip forwarding off in this dialog has several consequences: generated firewall script will actually turn it off on the server and Firewall Builder policy compiler will not generate any rules in the FORWARD chain.

Figure 10. Turn off ip forwarding

Figure 10. Turn off ip forwarding

Now that I have both firewall objects, I can create cluster object that will represent my HA pair. To do this, I select both firewall objects in the tree by clicking on them while holding Ctrl key, then click right mouse button to open context menu and choose item “New cluster from selected firewalls”:

Figure 11. Create cluster object from two member firewalls

Figure 11. Create cluster object from two member firewalls

This opens a wizard that will walk you through the process of creating new cluster object. The wizard was opened using “New cluster from selected firewalls” menu, because of that there are only two firewall objects in the list. If I used main menu “Object/New Object” and then “New Cluster”, I would see all firewalls defined in my data file in the list which can be quite long.

Figure 12. Choosing the name for the new cluster object

Figure 12. Choosing the name for the new cluster object

Figure 13. Choosing interfaces of the member firewalls

Figure 13. Choosing interfaces of the member firewalls

This page of the wizard allows me to establish correspondence between interfaces of the member firewalls create cluster interface objects that will represent them. Cluster interface object should have the same name as corresponding member firewall interfaces. The program tries to guess what interfaces of the member firewalls can be used for the cluster and in a simple configuration like the one I am working with, guesses right.

On the next page of the wizard I can choose failover protocol used by the cluster on each interface (in principle, I can run different protocols on different interfaces) and virtual IP addresses.

Figure 14. Choosing IP addresses for the interfaces of the cluster

Figure 14. Choosing IP addresses for the interfaces of the cluster

Next page of the wizard is particularly interesting. Here I can choose which member firewall policy to use for the cluster. This feature is designed mostly for those who convert from the old manually maintained configuration of redundant firewalls to the new cluster object and want to reuse policy rules that used to belong to one of the member firewalls.

Figure 15. Cluster will inherit rules of one of the member firewalls

Figure 15. Cluster will inherit rules of one of the member firewalls

When new cluster object inherits policy and other rule sets of one of the members, the program copies rules from the designated member to the cluster, then it creates copies of all member firewalls, clears their rule sets and sets the cluster up to use these copies as members. It keeps old member firewall objects in the file, but they are marked as inactive and renamed. These objects are kept as a backup in case you may want to check their configuration or copy rules. New cluster object is shown in Figure 16:

Figure 16. New cluster object

Figure 16. New cluster object

Each cluster interface has child “Failover group” object with the name “firewall:eth0:members” or similar. This is where you configure associated member firewall interfaces. Double click this object in the tree and then click “Manage Members” button in the dialog. Select interfaces of the member firewalls in the panel on the left hand side and click arrow button to add them to the list on the right. When you create cluster object using the wizard, the Failover Group objects are created automatically.

Figure 17. Failover group object

Figure 17. Failover group object

Failover Group object not only ties interfaces of the member firewalls together, it is also the place where you configure failover protocol and its parameters. I am using heartbeat in this example and failover group object “web_server_cluster:eth0:members” is configured with this protocol as shown in Figure 17. To configure parameters of the protocol, click “Edit protocol parameters” button. This opens dialog Figure 18:

Figure 18. Parameters of heartbeat protocol

Figure 18. Parameters of heartbeat protocol

These parameters are used to generate policy rules that permit packets of the protocol.

About the author: This article seires is contributed by Vadim Kurland {vadim at fwbuilder DOT org}, the main author of Firewall Builder.

Incoming search terms:

• directadmin spoof network address (2)
• iptables plesk centos (2)
• centos firewall cluster (1)
• cpanel iptables (1)
• firewall builder web server example (1)

I start with member firewalls. Open each one in the editor and change its name, platform and host OS as shown in Figure 26 for the first member:

Figure 26. Converting member firewall to PF/OpenBSD

Figure 26. Converting member firewall to PF/OpenBSD

Set version of PF to match version of your OpenBSD machine. Do the same change to the second member firewall, then check failover group of interface “eth0″ of the cluster object:

Figure 27. Failover group indicates that the cluster configuration does not match members

Figure 27. Failover group indicates that the cluster configuration does not match members

Failover group declares status of both members “Invalid”, this is because the platform and host OS of members do not match configuration of the cluster object anymore. They should match exactly, so we have to reconfigure the cluster object to platform “PF” and host OS “OpenBSD” as well. This should fix the status of both members in the failover group dialog.

To switch to OpenBSD from Linux we need to change failover protocol from heartbeat to CARP as well. The protocol is configured in the failover group object. List of available protocols depends on the firewall platform chosen in the parent cluster object. While cluster was set up as “iptables”, possible choices of failover protocols were “heartbeat”, “VRRP”, “OpenAIS” and “None”. “CARP” was not in the list because it is not available on Linux. After the cluster is switched to “PF”, the list consists only of “CARP” and “None” as shown in Figure 28:

Figure 28. Failover protocol choices for PF/OpenBSD

Figure 28. Failover protocol choices for PF/OpenBSD

Firewall Builder can configure CARP interfaces on BSD. For that, it needs some parameters of the CARP protocol. You can configure these if you click “Edit protocol parameters” button in the failover group object dialog. This brings another dialog where you can configure CARP password, vhid and some other parameters:

Figure 29. CARP parameters

Figure 29. CARP parameters

Last thing we have to change is the names of interfaces. On OpenBSD loopback is “lo0″ and ethernet interface can be for example “pcn0″. To rename interfaces find them in the tree, open in the editor and change the name. This needs to be done with interface objects of both member firewalls and the cluster. Significant difference between CARP protocol and heartbeat on Linux is that CARP creates its own network interfaces named “carpNN”. In Firewall Builder terms this means we need to name cluster interface object “carp0″ (remmber that in case of Linux cluster, cluster interface name was the same as names of corresponding member firewalls). After all interfaces have been renamed, my final configuration looks like shown in Figure 30:

Figure 30. Final configuration for PF cluster

Figure 30. Final configuration for PF cluster

Now we can recompile the cluster again. For PF fwbuilder generates two files for each member firewall. One file has extension .conf and contains PF configuration. The other file has extension .fw and is an activation script.

Looking inside the generated .conf file, we see PF implementation of the same policy rules (this is just a fragment with first few rules):

# Tables: (2)
table <tbl.r0.d> { 10.3.14.50 , 10.3.14.152 , 10.3.14.151 , 10.3.14.150 }
table <tbl.r0.s> { 10.3.14.152 , 10.3.14.151 , 10.3.14.150 , 10.3.14.50 }
# # Rule -2 CARP (automatic)
pass quick on pcn0 inet proto carp from any to any label "RULE -2 -- ACCEPT "
#
# Rule backup ssh access rule
# backup ssh access rule
pass in quick inet proto tcp from 10.3.14.0/24 to <tbl.r0.d> port 22 \
    flags any label "RULE -1 -- ACCEPT "
#
# Rule 0 (carp0)
block in log quick on pcn0 inet from <tbl.r0.s> to <tbl.r0.s> \
    no state label "RULE 0 -- DROP "
#
# Rule 1 (lo0)
pass quick on lo0 inet from any to any no state label "RULE 1 -- ACCEPT "

Figure 31. Example of a rule associated with a cluster interface

Figure 31. Example of a rule associated with a cluster interface

Look at the rule #0 in the screenshot Figure 19 (the anti-spoofing rule). The same rule is shown in Figure 31, except I removed label “outside” from the interface carp0 to make it clear which interface is placed in the “Interface” column of the rule.

This rule has interface object that belongs to the cluster in its “Interface” column. Firewall Builder GUI does not accept member firewall interface in this column. Only interfaces of the cluster are allowed in the “Interface” column of the rule set that belongs to the cluster. Interfaces of the Linux cluster have the same names as corresponding member firewall interfaces. In my example above member interfaces were “eth0″ and cluster interface had the same name. This is because cluster interface object is an abstraction that serves several purposes: it is a place where failover protocol parameters are configured and also it represents member firewall interfaces in rules when the program compiles the policy and generates firewall script or configuration file. Cluster interface object will be replaced with interface of the member firewall for which the policy is being compiled. When fwbuilder compiles it for the member #1, it replaces cluster interface objects with interfaces of member #1. When it then compiles the same rules for member #2, it replaces cluster interfaces with interfaces of member #2.

This feels intuitive when we build Linux cluster because names of member interfaces and cluster interfaces are the same. When I use cluster interface “eth0″ in the rule, it is essentially the same as using firewall’s interface with the same name (except it is not the same, internally) so it is the configuration I am used to when I start configuring clusters have spent some time working with regular firewalls in fwbuilder.

Interfaces of BSD cluster have names that directly correspond to the names of failover protocol interfaces carpNN which really exist on the firewall machine. The problem is that PF does not inspect packets on these interfaces and therefore PF rules should not be attached to these interfaces. Yet, fwbuilder uses BSD cluster interfaces carpNN in the same way as explained above. if you want to attach rules to particular interfaces using “on <intf>” clause, you need to use cluster interface object in the rules. In this case, just like when we were building Linux cluster, fwbuilder will replace carpNN with interfaces of member firewall that are configured in the failover group of the cluster interface.

I realize this can be counter-intuitive, especially to those who know all details of BSD cluster configuration by heart and are very used to working with CARP. We may be able to improve the model in future versions of fwbuilder if there is enough user demand.

The bottom part of the activation script is interesting. This is where CARP interface is configured and PF configuration is activated. Here is how this looks like:

configure_interfaces() {
    sync_carp_interfaces carp0
    $IFCONFIG carp0 vhid 100 pass secret    carpdev pcn0
    update_addresses_of_interface \
  "carp0 10.3.14.152/0xffffff00 10.3.14.151/0xffffff00 10.3.14.150/0xffffff00" ""
    update_addresses_of_interface "lo0 ::1/128 127.0.0.1/0xff000000" ""
    update_addresses_of_interface "pcn0 10.3.14.50/0xffffff00" ""
}
log "Activating firewall script generated Thu Mar 18 20:19:42 2010 by vadim"
set_kernel_vars
configure_interfaces
prolog_commands
$PFCTL   \
     -f \
    ${FWDIR}/bsd-test-1.conf || exit 1

Shell function “sync_carp_interfaces” is defined at the beginning of the same script, it compares list of carp interfaces defined in Firewall Builder with carp interfaces that really exist on the firewall machine. Interfaces that are missing are created and those that exist but are not defined in fwbuilder are deleted. If the set of carp interfaces matches those defined in fwbuilder, this function does nothing. Next, the script configured interface carp0 using parameters entered in the failover protocol dialog Figure 29 shown above. Calls to shell function “update_addresses_of_interface” update ip addresses of interfaces, including carp0. This function also does it incrementally by comparing required list of addresses with those that really are configured on the interface. If lists match, the function does not do anything, otherwise it adds or deletes addresses as appropriate.

Basically, you can start with OpenBSD or FreeBSD machine configured with one IP address on the interface that you can use to communicate with it. Script generated by fwbuilder will set up other addresses and failover protocol.

As you can see, conversion required few changes but not that much. I had to change firewall platform and host OS in member firewalls and cluster object, rename interfaces, possibly change IP addresses, change the name of the failover protocol and its parameters. Relationships between the cluster and member firewalls remained the same and so I did not have to add or remove firewalls to cluster failover group objects. Most importantly, I did not have to touch rules at all. Granted, this was very simple example and in more complicated cases some rules may need to be adjusted. Most often this is the case when original iptables policy used some modules and features unique to iptables. Most typical rules can be translated automatically with no change in the GUI.

About the author: This article seires is contributed by Vadim Kurland {vadim at fwbuilder DOT org}, the main author of Firewall Builder.

Incoming search terms:

• convert a linux machine in firewall (1)
• pf on linux (1)
• pf iptables (1)
• openbsd (1)
• network object in linux iptables (1)
• linux firewall vs openbsd (1)
• iptables translate (1)
• fwbuilder openvz (1)
• fwbuilder cluster ip (1)
• firewall builder sql interface (1)

You create a script as follows and use it to stop or flush the iptables rules.

Please don’t type rules at command prompt. Use the script to speed up work.

Procedure for Debian / Ubuntu Linux

A) Create /root/fw.stop /etc/init.d/fw.stop script using text editor such as vi:

#!/bin/sh
echo "Stopping firewall and allowing everyone..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

(B) Make sure you can execute the script:
# chmod +x /root/fw.stop

(C) You can run the script:
# /root/fw.stop

A note for RedHat and friends Linux user

Please note that RedHat enterprise Linux (RHEL) and Fedora / Centos Linux comes with pre-installed script, which can be used to stop the firewall:
#/etc/init.d/iptables stop

Incoming search terms:

• /root/fw stop: no such file or directory (1)
• centos cpanel flush iptables (1)
• commandsysctl freebsd (1)
• flush iptables cpanel (1)
• iptables rule is removed (1)
• plesk flush iptables (1)

nmap port scanning

TCP Connect scanning for localhost and network 192.168.0.0/24
# nmap -v -sT localhost
# nmap -v -sT 192.168.0.0/24

nmap TCP SYN (half-open) scanning

# nmap -v -sS localhost
# nmap -v -sS 192.168.0.0/24

nmap TCP FIN scanning

# nmap -v -sF localhost
# nmap -v -sF 192.168.0.0/24

nmap TCP Xmas tree scanning

Useful to see if firewall protecting against this kind of attack or not:
# nmap -v -sX localhost
# nmap -v -sX 192.168.0.0/24

nmap TCP Null scanning

Useful to see if firewall protecting against this kind attack or not:
# nmap -v -sN localhost
# nmap -v -sN 192.168.0.0/24

nmap TCP Windows scanning

# nmap -v -sW localhost
# nmap -v -sW 192.168.0.0/24

nmap TCP RPC scanning

Useful to find out RPC (such as portmap) services
# nmap -v -sR localhost
# nmap -v -sR 192.168.0.0/24

nmap UDP scanning

Useful to find out UDP ports
# nmap -v -O localhost
# nmap -v -O 192.168.0.0/24

nmap remote software version scanning

You can also find out what software version opening the port.
# nmap -v -sV localhost
# nmap -v -sV 192.168.0.0/24

A note about Windows XP / 2003 / Vista version

Windows user can find ipEye and IPSecScan utilities useful. Please note that Nmap also runes on Windows OS.

Read the man page of nmap for more information:
$ man nmap

Incoming search terms:

• rdate :couldnt connect to host is refused when trying with windows (4)
• linux scan port command (1)
• nmap how to scan network (1)
• nmap plesk centos (1)
• rdate connection refused redhat (1)
• script port scanning unix or linux (1)
• unix scan network (1)
• using nmap to inventory systems (1)
• you can not scan local host with ipeye (1)

passed klogd skipped #daemon klogd $KLOGD_OPTIONS

Replace it with lines below,

#passed klogd skipped
daemon klogd $KLOGD_OPTIONS

Now search ‘status klogd’ (nearly at line #61) and uncomment it.

If you change the file, remember to restart syslog via /etc/init.d/syslog restart

Incoming search terms:

• syslogd appears to be running but not klogd which logs kernel firewall messages to syslog you should ensure that klogd is running (10)
• directadmin syslogd appears to be running but not klogd which logs kernel firewall messages to syslog you should ensure that klogd is running (2)
• debian syslogd appears to be running but not klogd which logs kernel firewall messages to syslog you should ensure that klogd is running (2)
• csf logs (1)
• klogd passed (1)
• klogd log where (1)
• how to install klogd (1)
• fedora klogd not started (1)
• error log for csf firewall (1)
• ensure that klogd is running (1)

Port numbers which are recognized by Internet and other network protocols, enabling the computer to interact with others. Each Linux server has a port number (see /etc/services file). For example:

1. TCP port 80 – HTTP Server
2. TCP port 443 – HTTPS Server
3. TCP port 25 – Mail Server
4. TCP port 22 – OpenSSH (remote) secure shell server
5. TCP port 110 – POP3 (Post Office Protocol v3) server
6. TCP port 143 – Internet Message Access Protocol (IMAP) — management of email messages
7. TCP / UDP port 53 – Domain Name System (DNS)

Block Incoming Port

The syntax is as follows to block incoming port using IPtables:

/sbin/iptables -A INPUT -p tcp –destination-port {PORT-NUMBER-HERE} -j DROP

### interface section use eth1 ###
/sbin/iptables -A INPUT -i eth1 -p tcp –destination-port {PORT-NUMBER-HERE} -j DROP

### only drop port for given IP or Subnet ##
/sbin/iptables -A INPUT -i eth0 -p tcp –destination-port {PORT-NUMBER-HERE} -s {IP-ADDRESS-HERE} -j DROP
/sbin/iptables -A INPUT -i eth0 -p tcp –destination-port {PORT-NUMBER-HERE} -s {IP/SUBNET-HERE} -j DROP

To block port 80 (HTTP server), enter (or add to your iptables shell script):

# /sbin/iptables -A INPUT -p tcp --destination-port 80 -j DROP
# /sbin/service iptables save

Block Incomming Port 80 except for IP Address 1.2.3.4

    # /sbin/iptables -A INPUT -p tcp -i eth1 -s ! 1.2.3.4 –dport 80 -j DROP

Block Outgoing Port

The syntax is as follows:

 

/sbin/iptables -A OUTPUT -p tcp –dport {PORT-NUMBER-HERE} -j DROP

### interface section use eth1 ###
/sbin/iptables -A OUTPUT -i eth1 -p tcp –dport {PORT-NUMBER-HERE} -j DROP

### only drop port for given IP or Subnet ##
/sbin/iptables -A OUTPUT -i eth0 -p tcp –destination-port {PORT-NUMBER-HERE} -s {IP-ADDRESS-HERE} -j DROP
/sbin/iptables -A OUTPUT -i eth0 -p tcp –destination-port {PORT-NUMBER-HERE} -s {IP/SUBNET-HERE} -j DROP

To block outgoing port # 25, enter:

# /sbin/iptables -A OUTPUT -p tcp --dport 25 -j DROP
# /sbin/service iptables save
You can block port # 1234 for IP address 192.168.1.2 only:
# /sbin/iptables -A OUTPUT -p tcp -d 192.168.1.2 --dport 1234 -j DROP
# /sbin/service iptables save

How Do I Log Dropped Port Details?

Use the following syntax:

# Logging #
### If you would like to log dropped packets to syslog, first log it ###
/sbin/iptables -A INPUT -m limit –limit 5/min -j LOG –log-prefix “PORT 80 DROP: ” –log-level 7

### now drop it ###
/sbin/iptables -A INPUT -p tcp –destination-port 80 -j DROP

How Do I Block Cracker (IP: 123.1.2.3) Access To UDP Port # 161?

 

/sbin/iptables -A INPUT -s 123.1.2.3 -i eth1 -p udp -m state –state NEW -m udp –dport 161 -j DROP

# drop students 192.168.1.0/24 subnet to port 80
/sbin/iptables -A INPUT -s 192.168.1.0/24 -i eth1 -p tcp -m state –state NEW -m tcp –dport 80 -j DROP

Incoming search terms:

• block network iptables (1)
• close port iptables centos (1)
• cpanel block wmh iptables (1)
• iptables in linux programming (1)
• iptables ipaddresshere (1)
• linux block ip port (1)
• linux centos mengenai ip tables (1)
• port number for http in linux (1)

Firewall Builder is a firewall configuration and management GUI that supports configuring a wide range of firewalls from a single application. Supported firewalls include Linux iptables, BSD pf, Cisco ASA/PIX, Cisco router access lists and many more. The complete list of supported platforms along with downloadable binary packages and soure code can be found at http://www.fwbuilder.org.

In this tutorial we are going to cover how to use Firewall Builder clusters to manage a single firewall policy that gets deployed on multiple servers. An example of where you could use this would be managing a shared firewall policy for a collection of web servers that are all providing the same service and should have the same rules.

Normally the cluster feature is used to create high availability firewall pairs, but in this case we are going to use it creatively to create a “master” firewall policy that gets deployed on multiple servers. This allows you to create a cluster object with a “master” firewall policy and then add servers as members to this cluster that will inherit the master firewall policy.

For this tutorial we are going to use the web farm example shown below. The example starts with two servers running Linux with iptables should have identical firewall polices. We’ll cover creating the firewalls and cluster and assigning rules to it. At the end we’ll walk through adding a 3rd server to the cluster.

While we are using a small number of servers for this example, the technique we are using can scale to manage a common firewall policy for hundreds or more servers.

On these servers we want to implement the following basic firewall rules.

• Allow system to commuicate to its own loopback interface
• Allow inbound HTTP and HTTPS from anywhere to the server
• Allow inbound SSH from a specific set of trusted subnets
• Allow outbound connectivity to port 8009 (jboss) to a group of application servers

This tutorial assumes knowledge of basic Firewall Builder concepts and common actions like creating firewall objects and rules. You can find more information about Firewall Builder commands on the Firewall Builder website http://www.fwbuilder.org.

Step 1 – Create firewall objects for your servers

To create a cluster we first need to create the firewall objects that will be members of the cluster. Each server is represented by a firewall object in Firewall Builder. Go through the New Firewall wizard and create a firewall called web-01 with two interfaces. The first interface is the Ethernet interface “eth0″ that connects the server to the Internet and the second interface is the loopback interface “lo”.

After you have created the firewall object it should look like this in the object tree:

By default Firewall Builder sets the firewall object to route (forward) IP packets. Since this is a server firewall we should disable IP forwarding on the host. Do this by double-clicking on the firewall object and then click on Host OS Settings in the Editor Panel at the bottom. Change the setting for IPv4 Packet Forwarding to Off.

To create a second firewall object for web-02 you can use the Duplicate feature in Firewall Builder.

• Right-click on web-01 firewall and select Duplicate -> place in library User
• Edit the name of the newly created firewall object to web-02
• Double-click on web-02′s IP object under the eth0 interface and set the IP address to 192.0.2.12 / 24

Step 2 – Create a new cluster

To create a new cluster right-click on the Clusters folder in the object tree and select New Cluster. This will launch the New Cluster wizard. Name the cluster, for example web-servers, and select both web-01 and web-02 to be members of the cluster. Since we are not using failover it does not matter which firewall is set to Master.

Click Next >

Since both servers use eth0 as the outside interface leave the interface mapping as is. If you have servers with different interface names on your server, for example if one server uses eth0 and the other server uses eth1, you can set the mapping here.

Click Next >

To make the cluster interface easy to identify update the label associated with interfaces eth0 and lo. Since we are not running our servers as a high availability cluster with failover set the Failover protocol to None.

Make sure to update both the eth0 and lo interfaces.

Click Next >

We want to create new rules for our cluster, so set the source of the cluster rules to be “do not use any, i will create new policy and NAT rules”.

Click Finish

Once you are done you should see a new cluster object in the tree that looks like this:

Step 3 – Define cluster policy rules

After you create the cluster, the Policy object is automatically opened in the Rules Panel. Make sure to create the rules in the cluster object, called web-servers in our example, and not in one of the individual firewalls that are members of the cluster. Remember we wanted both of our servers to have the following rules:

• Allow system to commuicate to its own loopback interface
• Allow inbound HTTP and HTTPS from anywhere to the server
• Allow inbound SSH from a specific set of trusted subnets
• Allow outbound connectivity to port 8009 (jboss) to a group of application servers

After you configure these rules in the web-servers Policy object the rules should look like this:

NOTE: For objects that are related to the firewall itself, such as interfaces, make sure to use the objects from the cluster when creating the rules. The cluster objects will automatically get translated to the correct object for the individual cluster members.

Step 4 – Compile and install rules

The next step is to compile and install the rules on our servers. When Firewall Builder compiles the cluster it will generate a firewall script for each of the cluster members including substituting the cluster objects used in the rules for the matching local object on the cluster member.

For example, the IP address for the eth0 cluster object is automatically translated to the correct address for web-01 (192.0.2.11) and web-02 (192.0.2.12).

You can see this substitution by inspecting the generated file for web-01 after the compile is completed. Note that the destination in the rule shown below is set to the IP address of web-01′s eth0 interface.

echo “Rule 0 (eth0)”
#$IPTABLES -A INPUT -i eth0 -p tcp -m tcp -m multiport \
-d 192.0.2.11 –dports 80,443 -m state –state NEW -j ACCEPT

Modifying rules

Now that you have a cluster setup to generate firewall policies for each of the server firewalls it is easy to make changes that affect all your servers. For example, to add a new rule to all members of the web-servers cluster to allow ICMP from the Trusted Networks object to servers simply add the rule in the cluster policy and compile and install it to the members.

Adding a new server to the cluster

To add a new server to the cluster you first need to create the firewall object to represent the server. You can do this manually, or you can follow the same duplication process we used to create the web-02 firewall object.

• Right-click on web-02 firewall and select Duplicate -> place in library User
• Edit the name of the newly created firewall object to web-03
• Click on the Host OS Settings and disable IPv4 Packet forwarding
• Double-click on web-03′s IP object under the eth0 interface and set the IP address to 192.0.2.23 / 24

The next step is to add the new web-03 firewall object to the cluster.

Repeat this process for the “lo” loopback interface. Remember the steps are:

• Double-click on the interface named web-servers:eth0:members
• Click on the Manage Members button at the bottom of the Editor Panel
• Click to select the “lo” interface under the web-03 object
• Click the right arrow > button to add the interface to the cluster member list
• Click Ok

Installing firewall policy on new server in cluster

To deploy the firewall policy on web-03 you need to compile and install the cluster policy. Since the cluster policy hasn’t changed we don’t need to re-install the policy on web-01 or web-02 so we unselect them from the install list.

You can add and remove servers to the cluster as needed. Here’s our configuration now that we have three servers in the cluster all running the same firewall rules.

Incoming search terms:

• firewall builder cpanel (2)
• firewall builder sample firewall policy file (1)
• sync two vps xen (1)

Completely block Ftp access on the server:

    # iptables -A INPUT -p tcp --dport 21 -j DROP

Block Ftp access for a specific IP address, say 11.12.13.14

    # iptables -A INPUT -p tcp -s 11.12.13.14 --dport 21 -j DROP

Block Ftp access for a specific subnet

    # iptables -I INPUT -p tcp -s 11.12.13.0/24 --dport 21 -j DROP

Make sure you save the iptable rules else they will be erased after a iptable/server restart:

    # service iptables save

CSF firewall use iptables in the background to apply it’s rules. Edit the csf configuration file,

    # pico /etc/csf/csf.conf

Remove port 21 from the TCP_IN list and restart the csf firewall

    # csf -r

Block Ftp access for a specific IP address, edit the csf.deny file

    # pico /etc/csf/csf.deny

and place the following line

    tcp:in:d=21:s=11.12.13.14

Save the file and restart the csf firewall.

Incoming search terms:

• csf vs iptables (3)
• centos cpanel disable ftp 21 port (1)
• ftp block csf (1)
• how to block ftp port in centos (1)
• how to block specified network not access ftp using iptables (1)
• iptables ftp acces (1)
• steps to block a port in iptables (1)
• why firewall ftp ports with iptables (1)