Informations technologies

Odoo 14 requirements installation - the easy way !!! one command solution !!!

2021-01-30T03:02:00.003-08:00

To install odoo 14 requirements (python 3 libraries ) you need a lot off work , installing other dev headers to compile python code sources , for that i decide to make a github repository that contains all required libraries .whl files , all you need to do is :

1- install python 3.9 in your system .

2- clone github repo : https://github.com/ibrahimdsv/odoo14-wheels.git

3- go to the folder off your system ( if your system is windows go to : wheels_win32 , else if your system is linux go to wheels_linux) with this command : cd wheels_win32 or cd wheels_linux .

4- execute this command : pip install --no-index --find-links . -r requirements.txt

Thats all enjoy your odoo 14 environnement is ready !!! .

How an IDS Works

2016-04-27T02:29:00.003-07:00

Now that we have looked at some of the capabilities of an IDS as far as alerting
on malicious traffic, it’s time to take a closer look at what exactly IDSs can keep
an eye on, what data sources they use to do this monitoring, how they separate
attack traffic from normal traffic, and some possible responses to seeing malicious
traffic.
What the IDS Is Watching ??
Let’s start by looking at what your IDS is able to see.This is going to depend
greatly on what type of IDS it is, and where it’s placed in your network. IDSs are
classified by their functionality, loosely grouped into the following three categories:

■ Network-Based Intrusion Detection System (NIDS)
■ Host-Based Intrusion Detection System (HIDS)
■ Distributed Intrusion Detection System (DIDS)
Network IDS
The NIDS derives its name from the fact that it monitors an entire network seg
ment, or subnet.This is done by changing the mode on the NIDS’ network
interface card (NIC). Normally, a NIC operates in nonpromiscuous mode, lis
tening only for packets destined for its own media access control (MAC) address.
Other packets are not forwarded up the stack for analysis; they are ignored.To
monitor all traffic on the subnet, not just those packets addressed to the NIDS
machine itself, the NIDS must accept all packets and forward them up the stack.
This is known as promiscuous mode.
In promiscuous mode, the NIDS can eavesdrop on all communications
on the network segment. However, that’s not all that is necessary to ensure that
your NIDS is capable of listening to all traffic on the subnet.The network device
immediately upstream of your NIDS must also be configured to send all packets
on the subnet to your NIDS. If that device is a hub, all packets are automatically
sent since all ports on a hub receive all traffic flowing through the hub. However,
if that device is a switch, you may have to put the port on the switch into a
monitoring mode, turning it into a span port. After setting up your NIDS, it is
advisable to run a sniffing tool on the interface, to ensure that you can see all
traffic on the subnet.
The advantage of a NIDS is that it has no impact on the systems or networks
it is monitoring. It doesn’t add any load to the hosts, and an attacker who com
promises one of the systems being watched can’t touch the NIDS and may not
even know it is there. One downside of the monitoring is maxing out your span
ports that you are allotted on a given network, and maxing out the bandwidth
on the span itself. If you have 20 100MB ports spanning to one port, you begin
filling up backplane… once that 5GB or 11GB backplane is saturated, you are in
a world of hurt.
In view of emerging privacy regulations, monitoring network communications is a responsibility that must be considered carefully. Make sure that you are familiar with your local legal requirements for such activity.
In Figure 1.1, we see a network using three NIDS.The units have been placed on strategic network segments and can monitor network traffic for all devices on the segment.This configuration represents a standard perimeter security network topology where the screened subnets housing the public servers are protected by NIDSs. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits. Careful monitoring is necessary to prevent further damage.

The internal host systems are protected by an additional NIDS to mitigate
exposure to internal compromise.The use of multiple NIDS within a network is an example of a defense-in-depth security architecture.

Host-Based IDS
Host-based IDSs, or HIDSs, differ from NIDSs in two ways. First, an installed
HIDS protects only the system on which it resides, not the entire subnet, and
second, the network card of a system with a HIDS installed normally operates in
nonpromiscuous mode.This can be an advantage in some cases—not all NICs
are capable of promiscuous mode, although most modern NICs are. In addition,
promiscuous mode can be CPU intensive for a slow host machine.
Another advantage of HIDS is the ability to tailor the ruleset to be very spe
cific to the particular host system. For example, there is no need to configure mul
tiple rules designed to detect Network File System (NFS) exploits on a host that is
not using the NFS. Being able to fine-tune your ruleset will enhance performance
and decrease false positives (or true positives that you simply don’t care about).The
major advantage of a HIDS, however, lies in its capability to detect specific changes
to the files and operating system of its host. It can monitor file sizes and checksums
to ensure that crucial system files are not maliciously modified without someone
noticing. It can intercept rogue system calls that may be an attempt at exploiting a
local vulnerability. Moreover, it can watch traffic within a system that never crosses
the network, and therefore would never be seen by the NIDS.
There are a few downsides to electing to use a HIDS.You’ll have to choose
one that is tailored to your operating system. If you have many different oper
ating systems on your network and want to use the same vendor for all your
HIDSs, you may have to do a little shopping to find the right vendor that sup
ports all of your operating systems. A HIDS will add load to the host on which it
is configured, as the HIDS process(es) will consume resources.This is usually not
a problem on an individual’s desktop, but can become one on a busy network
server. Make sure you are familiar with the details of any HIDS that you choose
and how it operates—some HIDSs will watch file accesses, usage times, process
loads, and/or system calls, while others may also watch network activity from the
point of view of that host. Know what features you want in your HIDS, and
make sure that the HIDS you select will support those features on all the plat
forms you need.

In addition, maintaining a large network of systems with many HIDS
deployed can be very challenging.The HIDS solution alone does not always scale
well, and without centralized management, you may be a very busy system
administrator indeed trying to keep up with all those alerts.
Figure 1.2 depicts a network using a HIDS on specific servers and host com
puters. As previously mentioned, the ruleset for the HIDS on the mail server is
customized to protect it from mail server exploits, while the Web server rules are
tailored for Web exploits. During installation, individual host machines can be
configured with a common set of rules. New rules can be loaded periodically to
account for new vulnerabilities.

Distributed IDS :
A Distributed Intrusion Detection System, or DIDS, is a combination of NIDS
sensors, HIDS sensors, or both, distributed across your enterprise, and all
reporting to a central correlation system. Attack logs are generated on the sensors
and uploaded (either periodically or continuously) to the central server station
where they can be stored in a central database. New attack signatures are created or downloaded to the management station as they become available, and can
then be downloaded to the sensors on an as-needed basis.The different kinds of
sensors may or may not be managed by the same server, and the management
servers are frequently separate from the servers that collect the logs.The rules for
each sensor can be tailored to meet its individual needs, suiting the network or
the host that each sensor monitors. Alerts can be forwarded to a messaging
system located on the correlation system station and used to notify the IDS
administrator.

Creating a Strong Firewall Security Policy:in checkpoint firewall product

2016-04-26T04:50:00.000-07:00

Using the Firewall Rule Base The firewall is the core of a well-defined network security policy. The goal of the Check Point Firewall Rule Base is to create rules that only allow the specified connections.

Managing the Firewall Rule Base Use SmartDashboard to easily create and configure Firewall rules for a strong security policy.

These are the fields that manage the rules for the Firewall security policy.

No: Rule number in the Firewall Rule Base. Implied rules do not have a number.

Hits : Number of connections that match this rule.
Name : Name that the system administrator gives this rule.
Source : Network object that starts the connection.
Destination : Network object that completes the connection.

VPN : Definitions of the allowed or blocked traffic between VPN sites.
Service : Type of network service that is allowed or blocked.
Action: Firewall action that is done when traffic matches the rule.
Track :Tracking and logging action that is done when traffic matches the rule.
Install On :Network objects that will get the rule(s) of the security policy. The Policy Targets option installs the rule(s) on all Security Gateways.
Time : Time period that the Firewall enforces this rule.
Comment : An optional field that lets you summarize the rule.

for more details about checkpoint firewalls configuration download this manual :

http://downloads.checkpoint.com/dc/download.htm?ID=22913

SOFTWARE-DEFINED PROTECTION Modern security architecture powered by collaborative intelligence

2016-04-26T04:34:00.002-07:00

Business today is driven by free-flowing information. Corporate data travels through the cloud and mobile
devices and radiates through ideas and posts in social networks. BYOD, mobility and cloud computing have
revolutionized static IT environments, introducing the need for dynamic networks and infrastructures.
But if our IT environment has changed quickly, the threat landscape has changed even faster. The
sophistication and velocity of this evolution is growing exponentially by unleashing new attack types
frequently, combining known and unknown threats, taking advantage of “zero-day” vulnerabilities, and
utilizing hidden malware inside documents, websites, hosts and networks.
In a world with high-demanding IT infrastructures and networks, where perimeters are no longer well defined,
and where threats grow more intelligent every day, we need to define the right way to protect enterprises in the
ever changing threat landscape.
There is a wide proliferation of point security products; however these products tend to be reactive and
tactical in nature rather than architecturally oriented. Today’s corporations need a single architecture that combines high performance network security devices with real-time proactive protections.
A new paradigm is needed to protect organizations proactively.
Software-defined Protection is a new, pragmatic security architecture and methodology. It offers an infrastructure that is modular, agile and most importantly, SECURE.
Such architecture must protect organizations of all sizes at any location: headquarters networks, branch offices, roaming through smartphones or mobile devices, or when using cloud environments.
Protections should automatically adapt to the threat landscape without the need for security administrators to follow up manually on thousands of advisories and recommendations. These protections must integrate seamlessly into the larger IT environment, and the architecture must provide a defensive posture that collaboratively leverages both internal and external intelligent sources.
The Software Defined Protection (SDP) architecture partitions the security infrastructure into
three interconnected layers:
• An Enforcement Layer that is based on physical, virtual and host-based security enforcement points
and that segments the network as well as executes the protection logic in high-demand environments.
• A Control Layer that analyzes different sources of threat information and generates protections and
policies to be executed by the Enforcement Layer.
• A Management Layer that orchestrates the infrastructure and brings the highest degree of agility to the entire architecture.

GHOST critical liux security hole

2015-02-10T02:37:00.002-08:00

Description
Heap-based buffer overflow in the __nss_hostname_digits_dots function in glibc 2.2, and other 2.x versions before 2.18, allows context-dependent attackers to execute arbitrary code via vectors related to the (1) gethostbyname or (2) gethostbyname2 function, aka "GHOST." The GHOST vulnerability is a serious weakness in the Linux glibc library. It allows attackers to remotely take complete control of the victim system without having any prior knowledge of system credentials. CVE-2015-0235 has been assigned to this issue. Qualys security researchers discovered this bug and worked closely with Linux distribution vendors. And as a result of that we are releasing this advisory today as a coordinated effort, and patches for all distribution are available January 27, 2015.

What is glibc?:

The GNU C Library or glibc is an implementation of the standard C library and a core part of the Linux operating system. Without this library a Linux system will not function.
What is the vulnerability? During a code audit Qualys researchers discovered a buffer overflow in the __nss_hostname_digits_dots() function of glibc. This bug can be triggered both locally and remotely via all the gethostbyname*() functions. Applications have access to the DNS resolver primarily through the gethostbyname*() set of functions. These functions convert a hostname into an IP address.
During a code audit performed internally at Qualys, discovered a buffer overflow in the __nss_hostname_digits_dots() function of the GNU C Library (glibc). This bug is reachable both locally and remotely via the gethostbyname*() functions, so we decided to analyze it -- and its impact -- thoroughly, and named this vulnerability "GHOST".
Main conclusions are: Via gethostbyname() or gethostbyname2(), the overflowed buffer is located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the overflowed buffer is caller-supplied (and may therefore be located in the heap, stack, .data, .bss, etc; however, we have seen no such call in practice).
 At most size of(char *) bytes can be overwritten (ie, 4 bytes on 32-bit machines, and 8 bytes on 64-bit machines). Bytes can be overwritten only with digits ('0'...'9'), dots ('.'), and a terminating null character ('\0').
Despite these limitations, arbitrary code execution can be achieved. As a proof of concept, we developed a full-fledged remote exploit against the Exim mail server, bypassing all existing protections (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will publish our exploit as a Metasploit module in the near future.
 The first vulnerable version of the GNU C Library is glibc-2.2, released on November 10, 2000.
 We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are):Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7,Ubuntu 12.04, for example.

Analysis

The vulnerable function, __nss_hostname_digits_dots(), is called internally by the glibc in nss/getXXbyYY.c (the non-reentrant version) and nss/getXXbyYY_r.c (the reentrant version). However, the calls are surrounded by #ifdef HANDLE_DIGITS_DOTS, a macro defined only in:
 inet/gethstbynm.c
 inet/gethstbynm2.c
 inet/gethstbynm_r.c
 inet/gethstbynm2_r.c
 nscd/gethstbynm3_r.c
These files implement the gethostbyname*() family, and hence the only way to reach __nss_hostname_digits_dots() and its buffer overflow. The purpose of this function is to avoid expensive DNS lookups if the hostname argument is already an IPv4 or IPv6 address.
The code below comes from glibc-2.17:
35 int
36 __nss_hostname_digits_dots (const char *name, struct hostent *resbuf,
37 char **buffer, size_t *buffer_size,
38 size_t buflen, struct hostent **result,
39 enum nss_status *status, int af, int *h_errnop)
40 {
..
57 if (isdigit (name[0]) || isxdigit (name[0]) || name[0] == ':')
58 {
59 const char *cp;
60 char *hostname;
61 typedef unsigned char host_addr_t[16];
62 host_addr_t *host_addr;
63 typedef char *host_addr_list_t[2];
64 host_addr_list_t *h_addr_ptrs;
65 char **h_alias_ptr;
66 size_t size_needed;
85 size_needed = (sizeof (*host_addr)
86 + sizeof (*h_addr_ptrs) + strlen (name) + 1);
87
88 if (buffer_size == NULL)
89 {
90 if (buflen < size_needed)
91 {
..
95 goto done;
96 }
97 }
98 else if (buffer_size != NULL && *buffer_size < size_needed)
99 {
100 char *new_buf;
101 *buffer_size = size_needed;
102 new_buf = (char *) realloc (*buffer, *buffer_size);
103
104 if (new_buf == NULL)
105 {
...
114 goto done;
115 }
116 *buffer = new_buf;
117 }
...
121 host_addr = (host_addr_t *) *buffer;
122 h_addr_ptrs = (host_addr_list_t *)
123 ((char *) host_addr + sizeof (*host_addr));
124 h_alias_ptr = (char **) ((char *) h_addr_ptrs + sizeof (*h_addr_ptrs));
125 hostname = (char *) h_alias_ptr + sizeof (*h_alias_ptr);
126
127 if (isdigit (name[0]))
128 {
129 for (cp = name;; ++cp)
130 {
131 if (*cp == '\0')
132 {
133 int ok;
134
135 if (*--cp == '.')
136 break;
...
142 if (af == AF_INET)
143 ok = __inet_aton (name, (struct in_addr *) host_addr);
144 else
145 {
146 assert (af == AF_INET6);
147 ok = inet_pton (af, name, host_addr) > 0;
148 }
149 if (! ok)

In order to reach the overflow at line 157, the hostname argument must meet the following requirements:
 Its first character must be a digit (line 127).
 Its last character must not be a dot (line 135).
 It must comprise only digits and dots (line 197) (we call this the "digits-and-dots" requirement).
 It must be long enough to overflow the buffer. For example, the non-reentrant gethostbyname*() functions initially allocate their buffer with a call to malloc(1024) (the "1-KB" requirement).
Impact of this Bug
The impact of this bug is reduced significantly by the following
Reasons:
 A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013:
[BZ #15014]
 nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME))
[HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was successful.
 nss/digits_dots.c (__nss_hostname_digits_dots): Remove redundant variable declarations and reallocation of buffer when parsing as IPv6 address. Always set NSS status when called from reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when buffer too small. Correct computation of needed size.
 nss/Makefile (tests): Add test-digits-dots.
 nss/test-digits-dots.c: New test.
 The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.
 Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the "inet-aton" requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe.
 Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
"a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets." This makes it impossible to satisfy the "1-KB" requirement

Actually, glibc's DNS resolver can produce hostnames of up to(almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes ('\\')
and makes it impossible to satisfy the "digits-and-dots" requirement.

ADVANCED WIRESHARK FEATURES

2015-01-20T02:42:00.001-08:00

Once you master the basic concepts of
Wireshark, you will probably want to delve
further into some of its more advanced
features. In this chapter we’ll look at some of
these powerful features, including name resolution,
protocol dissection, and packet reassembly.
Name Resolution
Network data is transported via various alphanumeric addressing systems
that are often too long or complicated to remember, such as the physical
hardware address 00:16:CE:6E:8B:24. Name resolution (also called name lookup)
is the process a protocol uses to convert one identifying address into
another. For example, while a computer might have the physical address
00:16:CE:6E:8B:24, the DNS and ARP protocols allow us to see its name as
Marketing-2. By associating easy-to-read names with these cryptic addresses,
we make them easier to remember and identify.

galaxy s4 exploit

2013-03-16T00:21:00.001-07:00

Amid the XDA community's ongoing quest to root every Android handset it comes across, one forum user appears to have found a serious exploit that affects certain Exynos devices. While fiddling with his Galaxy S III, XDA user Alephzain discovered a way to obtain root without flashing with Odin. The Samsung kernel apparently allows read / write access to all physical memory on the device, including the kernel itself. This makes for an easy root, Alephzain writes, but leaves devices open to attack -- allowing Kernel code injections and RAM dumps from malware-laden apps from the Google Play store.
It isn't the only avenue for attack on an Android handset, but it is an exceedingly easy attack. Luckily, a community fostered fix seems pretty simple too -- XDA user RyanZA has already created a patch to modify write permissions on affected devices -- though Galaxy S III users are reporting that the fix cripples the phone's camera app. So far, Alephzain has confirmed that the Galaxy S II, III, Note II and the Meizu MX are at risk, but notes that the exploit might work on any device running a Exynos 4210 or 4412 processor. Samsung has not yet made a comment about the vulnerability, but forum members say that the issue has been reported. As for the exploit's lasting implications? Head on over to the XDA forums to join the discussion.
Update: François Simond (aka Supercurio) wastes no time plugging holes, and has already released a root-free fix for the vulnerability. Simond's solution is wrapped up in a simple APK, and requires no root, no flashing and no special know-how. It can be enabled or disabled manually, too -- allowing Galaxy S III users to regain full use of their front-facing camera, which as previously stated, is disrupted by the fix. Best of all, it's free -- skip on over to Project Voodoo at the source to get protected.
Update 2: Our good friend Supercurio also brought our attention to a statement released by Samsung France to Le Monde: the company will be issuing an official patch "very quickly," and it emphasized that this is an issue "only if a malicious application is installed." Obviously, for now you can use Supercurio's patch to ease your mind.

IPhone 5 hacked

2013-03-16T00:18:00.003-07:00

successfully breached an iPhone 4S at the mobile Pwn2Own hacker contest held this week at the EUSecWest event in Amsterdam.

As we reported that Joost Pol and Daan Keuper won the mobile Pwn2Own contest by compromising a fully patched iPhone 4S device and stealing contacts, browsing history, photos and videos from the phone.

The vaunted security of the iPhone (4S) took an epic fail tumble during the event when they was able to build an exploit for a vulnerability in WebKit to beat Apple's code-signing features and the MobileSafari sandbox. The same bug is present in the iOS6 Golden Master development code base, which means iPhone 5 is also vulnerable to the same exploit. Apple iPads and iPod Touch devices are also vulnerable.

"We specifically chose this one because it was present in iOS 6, which means the new iPhone coming out today will be vulnerable to this attack," Pol said. The duo won $30,000 for their efforts.

A good thief can hack into your personal data given enough time, we estimate that may mean a full working day of hacking.

Windows 8 exploit

2013-03-16T00:14:00.001-07:00

Less that a week after Microsoft released is long awaited Windows 8, with new and improved security features, French bug hunters VUPEN Security have announced that they have created an exploit for the new OS version that takes advantage of several zero-day flaws.

In the light of this discovery, the tweet that VUPEN CEO and head researcher Chaouki Bekrar posted upon the OS's release seems almost to mock Microsoft's efforts.

The company, which has become well known in security circles following their decision to begin selling information about software vulnerabilities instead of sharing them with developers, is for quite some time now one of the biggest players in the vulnerability market.

Their research team has repeatedly demonstrated their abilities during the annual Pwn2Own contest at the CanSecWest conference, which proved to be very good advertising for the company.

VUPEN Security sells information about vulnerabilities and ready-made exploits to NATO governments and "partners", intelligence agencies and corporations, who use the information for both offensive and defensive purposes.

"The in-depth technical details of the flaws will be shared with our customers and they can use them to protect their critical infrastructures against potential attacks or for national security purposes,” Bekrar commented this latest news for Forbes.

OsmocomBB: A tool for GSM protocol level security

2012-05-29T02:50:00.003-07:00

osmocombb its good ?????,,,

hacking GSM Networks ...illustration ..its real NoW ...

2012-05-29T02:45:00.001-07:00

watch the video and you will be able to do anything in the gsm network like any other network ..so
have a nice day ......

The First Windows 8 exploit ????????

2012-03-11T05:15:00.000-07:00

According to ZDNET Peter’s hack is believed to be the first proof-of-concept that has found a vulnerability in Microsoft’s new operating system which will launch in 2012.

After the exploit has been launched the OS operates under the SYSTEM account which then lets a hacker run a command prompt where they can defeat the User Account Control by avoiding the user prompt.

The Windows 8 OS is currently in Beta testing and the exploit will likely be fixed ahead of shipping however the small size of the code and the ease for which it was executed still deal a small humiliating blow to Microsoft as the company continues to emphasize their platforms stronger security standards via Windows Defender improvements.

Included with the new system is a real-time detection and protection suite along with a SmartScreen filtering system for Windows 8 and security improvements to Internet Explroer.

programing for smart card in QT how to :SOLVED

2012-02-22T00:33:00.001-08:00

to start programing for smart card in QT is a problem , why ...........???
because the library of winscard.h in windows SDK does not properly included ,so
the problem is solved ,we will go step by step :

1- download windows sdk and install it .
2- in QT create a new project (gui or console).
3- copy this files ( SCardErr.h , winscard.h ,winsmcrd.h) from the directory of widows sdk and paste him into the directory of your project .
4-add him to your project from QT interface , after that they will appear in the
headers group in QT interface.
5-in the file .pro of your project add this

win32:LIBS += "C:/Program Files/Microsoft SDKs/Windows/v6.0A/Lib/WinSCard.lib" \
"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Lib/SCardDlg.Lib" \
"C:/Program Files/Microsoft SDKs/Windows/v6.0A/Lib/wscapi.lib"

HEADERS += mainwindow.h \
winscard.h \
SCardErr.h \
winsmcrd.h

6- add this lines to your header file (mainwindow.h)

#include "winscard.h"
#include "windows.h"
#include "winnt.h"
#include "iostream"
#include "SCardErr.h"
#include "winsmcrd.h"

7- after that the smart card api is included properly.
8-you can start programing using all classes and functions in winscard.h .

**** winscard api use the windows api types so to convert from windows types to QT types (QString ,QByteArray) so i will put it here another day .

************* to get more information about smart card in QT post here your Questions or send me a mail to roky2003@gmail.com ..................................
please post your opinion ...................................................................................
authors : Debeche Ibrahim and Boukazoula Mehdi ----------from algeria

snort rules (network intrusion detection system)

2011-10-07T01:05:00.000-07:00

How the rules files are organized ?
Snort’s rules directory sorts hundreds of rules into rules files according to
their purpose. Although the rules are cataloged a few different ways and
some of the rule categories have overlapping domains, there’s certainly a
method to the madness.
Rules files fit into eight major categories:
ߜ Low-level protocols (icmp, netbios, tcp, udp)
ߜ High-level protocols (http, ftp, dns, pop3, imap)
ߜ Web server specific (web-attack, web-cgi, web-client)
ߜ Exploit specific (shellcode, backdoor, exploit)
ߜ Service impacting (dos, ddos)
ߜ Policy specific (policy, info, misc, porn)
ߜ Scanning and probing activities (scan, bad-traffic)
ߜ Viruses, worms, and other malware (virus)
The best way to find out how the whole rule system works is to get your
hands dirty with a typical example:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS CodeRed v2 root.exe access”;flow:to_server,established;uricontent:”/root.exe”; nocase; classtype:web application-attack; reference:url,
www.cert.org/advisories/CA-2001 19.html; sid:1256; rev:7;)

This rule demonstrates many of the options that you’re likely to encounter
with your own setup. We picked the Code Red worm alert from the web-
iis.rules file as our starting point.
Here’s a piece-by-piece explanation of that Code Red worm rule, which
appeared earlier in this section:
ߜ The alert directive (in bold in the following alert snippet) tells Snort
that if the packet matches this rule, then the rule should send its output
through the alert facility.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The overwhelming majority of Snort’s rules use the alert facility,
although optionally, you can use the log facility. Chapter 6 explains the
difference between these two facilities.
ߜ The tcp keyword is an argument that identifies which network protocols
the rule applies to. The following alert snipped shows the tcp keyword
in bold:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
Because the tcp keyword is specified, Snort knows to match this rule
only to network traffic using the TCP protocol (other protocols, such as
UDP) will be ignored.
ߜ The network source and destination arguments are highlighted in bold
in the following statement:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The preceding network source and destination arguments (including
port numbers) tell Snort to alert on any traffic that is either
• From the $EXTERNAL_NET on any port
• To any of our Web servers on the defined Web ports.
The network source and destination arguments use the variables estab-
lished at the beginning of the snort.conf file (the arguments beginning
with the $). These substitutions provide convenience and readability for
managing a large collection of rules, which can easily top a few thousand
entries. The last part of the rule gets even more granular with information the
rule should match on, as well as what Snort should do if the rule does
match . The following snippet shows what this looks like:
(msg:”WEB-IIS CodeRed v2 root.exe access”; flow:to_server,established;
uricontent:”/root.exe”; nocase; classtype:web application-
attack; reference:url, www.cert.org/advisories/CA-2001-19.html;
sid:1256; rev:7;)
• A few other tests tucked away in that last section must be passed
before an alert is generated. The flow: and uricontent: keywords
further refine the rule. In this case, if the uricontent (URI stands for
universal resource identifier) contains the text “/root.exe”. The
flow says that the connection should be going to the server and
should already be established. IP listed in your var HTTP_SERVERS
section of snort.conf, then an alert is generated with the message
“WEB-IIS CodeRed v2 root.exe access”.
Snort also identifies the type of attack by classifying it as a “web
applications-attack.” It further identifies the exact nature of the
alert setting the “sid” (Snort IDentification) field to 1256. Sids are
unique identifiers to Snort. They can nail down an offense to exactly one
alert. The reference: keyword provides a log entry regarding any other
information that’s known about the nature of the attack. References are
often URLs to security-related Web sites, such as CERT, Whitehats, or
SecurityFocus, which provide advisories on what the attack is and how
to patch for it (if possible). In our Code Red example, we point to the
CERT Web site with the following URL:
http://www.cert.org/advisories/CA-2001-19.html
Figure 8-1 shows a graphical overview of how a Snort rule is laid out. In it,
you see many of the bits and pieces of a rule.
Flow or direction operators represent how traffic is traversing the network.
Their use is pretty straightforward:
ߜ The > operator tells Snort that the network on the left should be regarded
as the source, and the one on the right should be the destination.
There isn’t a <- operator. All instances using it are written by flip-
flopping the arguments around the > command.
ߜ The <> operator will match any traffic between the network on the left
and the network on the right, regardless of which network originated the
traffic.
The directionless operator (<>) can sometimes cause a bit of confusion
with its use. It seems to makes sense that you would inspect traffic flowing
both ways from one computer or network to another, but that inspection
happens infrequently. Most Snort rules look something like this:
$EXTERNAL_NET any -> (internal host / port)
A rule that matches too broadly (which the preceding rule would do if it
contained <>) produces a huge Snort log and unduly burdens the pro-
cessing engine as it inspects everything that passes by.
Elements of the rule header
Sifting through the directory of rules shows that all the rules contain header
information, though most have a jumble of different items in their bodies. The
header is just a front-end filter that separates out traffic by using five key sift-
ing factors: source IP address, destination IP address, source port, destination
port, and protocol.
Rule actions
Snort comes built-in with five different rule actions. Each gives you a lot of
power in building your arsenal.
Before changing the default behavior of your Snort rules, spend some time
watching it operate in your environment and use its output to help you
reduce noisy false positives.
Here are Snort’s five rule actions:
ߜ The log action merely logs the offending packets to the output logging
that we set up when the Snort sensor was configured. The output plug-
ins options are many and varied, giving you a rich set of choices. A per-
rule log directive lets you customize logging down to a remarkable level.
ߜ The alert action can print a log entry and post a notification when
some event is associated with a higher priority and probably needs a
personal touch.
The alert action is the default action for most rules that come with
Snort. Snort’s job, after all, is to alert us of an attack on our network!
ߜ The pass action can ignore a matched packet and continue processing.
The pass action is useful when you’re tuning your rules and need to dis-
able some of the noisier ones so that you can actually see the output of
what you’re working with.
ߜ The most powerful of the Snort actions is the activate keyword.
Activate operates in concert with the dynamic action by triggering an
alert and running what’s specified by the associated dynamic rule.
The activate/dynamic pair is ideal for catching a complex series of
attacks that may otherwise go unnoticed.
ߜ The dynamic action is associated with a rule that shouldn’t run until
another event is encountered. You combine the dynamic action with
the activate action to set up a second level of processing in certain
circumstances.
The activate/dynamic pair isn’t often used in common Snort setups,
but it can be a handy tool for advanced intrusion detection.
Protocols
Snort, as a network IDS, must operate on the lowest level of the network to
do its job. Snort grabs Ethernet frames directly from the wire. Inside of those
frames are the four protocols that the free version of Snort normally scans: IP,
ICMP, TCP, and UDP.
Snort’s developers are attempting include other protocols, such as HTTP,
802.11, and ARP. The keywords for building your rules should include only
one of the original four.
For example, let’s say employees aren’t allowed to use the eBay auction Web
site on the job. A particular employee has been reprimanded for spending
hours browsing eBay, and HR wants to monitor his behavior. The following
rule logs all Web traffic that contains ebay.com coming from the host
192.168.1.18 with the message eBaying:
log tcp 192.168.1.18/32 any -> any 80 (msg:”eBaying”; uricontent:”ebay.com”;)
Source/destination
The last part of a well-formed Snort rule is probably the most important
piece of configuration data: The two IP address ranges that are involved with
the communication. The source and destination networks are identified in a
rule that takes this form:
(source network) (port) -> (destination network) (port)
CIDR (Classless Inter Domain Routing) notation is used for the network argu-
ments. CIDR notation is that funny way of expressing an IP address using a /
and another number — for example, 10.35.24.0/24, which means a Class C
network of 254 hosts on network 10.35.24.0 (plus the first and last
addresses that are reserved for the network address and the broadcast
address, namely 10.35.24.0 and 10.35.24.255).
For the Snort rules files, you really deal with only two types of entries:
ߜ Networks (which contain a /)
ߜ Hosts (which omit /)
Omitting / is a shorthand way of saying, “Just the single IP address, if
you please.” For example, the address 10.35.24.66 indicates just one
host for matching against.
You can also enter ranges of port numbers, similar to ranges of IP addresses.
Most of the examples that we cover in this chapter are single ports, such as
80 for the Web port, 443 for the encrypted Web port, and 25 for sendmail.
The entire range of available ports extends from 0 to 65535.
For a range of ports, you just place a colon between the two ports. The fol-
lowing rule looks for any traffic containing “ebay.com” occuring on any TCP
port between 1 and 1023.
log tcp 192.168.1.18/32 any -> any 1:1023 (msg:”eBaying”;
uricontent:”ebay.com”;)
You can also include the maximum and minimum ports ranges by simply
leaving off a number. For example :1023 means a range of ports from 0–1023,
and 1024: refers to a range of 1024–65535.
Wildcards
Wildcards simplify rules. Wildcards work just like those “splat” asterisks that
you can type into a DOS window or Unix shell to list only certain files. In
Snort, the any keyword is the most powerful wildcard — and it’s all over the
place. You’re allowed to use the any wildcard in both the network and port
configurations: any matches everything for the category you placed it in.
In the preceding section, we used the any wildcard in a couple of places. When
the host 192.168.1.18 tries to start a communication on any port with any
host on ports 1–1023 with the text “ebay.com” as part of a URI, then . . . bingo!
That’s a match, and the message eBaying appears in the logs.
Elements of the rule body
After being mangled by the pre-processors and whittled down by the filters of
the rule’s header, the rule’s body contains a virtual cornucopia of tests.
The most powerful test is pattern-matching what slips through for either spe-
cific keywords, phrases, or strings of binary data. Often, this inspection is the
most critical, because what’s being searched for is the “fingerprint” of the
attack itself.
Many of the most powerful features of Snort’s detection engine reside in the
body of the rule. Each feature has a different style, syntax, and set of options.
This flexibility can make rule management somewhat complicated, but very
worthwhile.
The layout of the rule body
Snort’s rule body must follow this specific structure:
ߜ The body section of a rule is always wrapped by one set of parentheses.
ߜ Body options (keywords, instructions, tests, and commands) are within
the parentheses.
ߜ Each body option is separated by a semicolon.
ߜ Each body option usually conforms to this format (the value is wrapped
in double quotes):
item: “value”;
ߜ The entire line is terminated with a semicolon.
While the structure contains a lot of punctuation, it helps keeps things
straight for both Snort and the person managing it.
The “content” option
Content analysis flushes out specific attack signatures within the packet. The
particulars of the content option is applied to each and every packet that
matches the header of the rule and can be expressed in either plain text form
(ASCII) or geek-speak (Hexadecimal).
Worms, viruses, and server cracks are normally transmitted onto your network
as raw machine code, which, to the naked eye, looks like gobbledy-gook, but is
in fact a series of instructions that harm your computers and servers.
Content matching is typically done at the application layer (Layer 7) of the
OSI networking model.
Text content matching (ASCII)
As a simple scenario for demonstration purposes, let’s say you’re concerned
about employees trading computer hacking information within your organiza-
tion. You can create a rule that generates an alert whenever an e-mail is sent
to your primary mail server (the mail server’s IP address is 172.16.30.7)
containing the word “hacking”. The mail port is 25; most mail is transmitted
using the TCP protocol, so the following rule illustrates how we can use the
content keyword to craft a rule to meet our goal.
alert tcp $EXTERNAL_NET any -> 172.16.30.7 25 (msg:”Found hacking reference in
e-mail”; content:”hacking”;)
Content analysis (by either text or hexadecimal matching) is used in more
than two-thirds of the rules that come with Snort.
Hexadecimal content matching
Hexadecimal (hex) content, although expressed differently than ASCII text, is
ultimately treated the same as ASCII by the Snort processing engine. In both
cases, the text is reduced to what the computer deals with best: bits, which is
then matched against the data streaming across your network. Hex is just a
shorthand way of representing the zeros and ones of binary machine code.
Hexadecimal is like a numerical alphabet that is 16 characters long, as com-
pared with English (which has 26 letters) or decimal math (which has 10
numerals). Hexadecimal is often referred to as base-16 because the “alpha-
bet” it uses has only 16 “letters” (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Hexadecimal
strings entered into a Snort rule body contain only those characters and
none others. If you create a hexadecimal string with nonhex characters,
expect that Snort will turn up its nose.
Here’s a real example right out of the rules directory:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:”EXPLOIT ssh CRC32 overflow
filler”; flow:to_server,established; content:”|00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00|”; reference:bugtraq,2347;
reference:cve,CVE-2001-0144; classtype:shellcode-detect; sid:1325;
rev:3;)
To use a hex match for content searching, wrap the hexadecimal characters
to find with the pipe symbols (|). White space can separate out single bytes
of hexadecimal data (“00 00”). Snort ignores the white space, which is only
there to preserve the readability to the rule crafter.
The preceding rule is meant to watch for an attempted exploitation of the
Secure Shell server application (sshd) by scanning traffic coming from any-
where on the external network and destined for your home network on port
22 (the sshd port). The content search is a long series of binary zeros (18
sets of two, to be exact). How can a pattern of zeros be unique? A pattern of
zeros is frequently found in attack code and is often a give-away that some-
one is doing something you don’t like.
Mixing it up
You can mix and match the style of content searching without confusing
Snort. As long as the binary data you want to search for has the bookends of
the pipe characters, that block of text can be intermingled with other, plain
ASCII text. What follows is a good example from the back-door.rules file.
alert tcp $EXTERNAL_NET any -> $HOME_NET 12345:12346 (msg:”BACKDOOR netbus get-
info”; flow:to_server,established; content:”GetInfo|0d|”; refer-
ence:arachnids,403; classtype:misc-activity; sid:110; rev:3;)
Notice how the content search string is constructed: GetInfo|0d|. This
string tells Snort’s pattern matching subsystem to watch for the text phrase
GetInfo with a carriage return at the end. Pretty nifty, eh? Inserting hex into
a plain text string is useful for representing characters that can’t be repre-
sented by plain text, such as a carriage return. You can drift between text and
binary content all within the same search string.
The “depth” option
It would be nice if malicious content always occurred at the beginning or end
of a packet. Unfortunately, malicious content can occur almost anywhere in a
packet. The depth option specifies how many bytes into a packet the Snort
processor should look before moving on to the next rule.
The main reason for using the depth option is to restrict the search to the
most likely places where a match is found, without wasting valuable proces-
sor resources to search the entire packet. For example, if you want to find the
HTTP protocol version as part of a Web site communication, look in the first
few hundred bytes. Because a packet may be as large as 1,500 bytes (less the
header overhead), it makes a lot of sense to give Snort a break, especially if
what it must look through are millions upon millions of packets.
The following rule from the web-misc.rules file reveals that you need only
15 bytes to catch the sadmind worm. Hence, the content GET x http/1.0 is
always encountered at the very beginning of the packet.
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:”WEB-MISC sadmind worm access”; flow:to_server,established;
content:”GET x HTTP/1.0”; offset:0; depth:15; classtype:attempted-
recon; reference:url,www.cert.org/advisories/CA-2001-11.html;
sid:1375; rev:5;)
The “nocase” option
The nocase option, which appears in more than a third of the rules that ship
with Snort, basically says to ignore the case of the characters submitted for
searching. Because the nocase directive takes no arguments, it’s normally
just used with a terminating semicolon. The following example from the
info.rules file finds the text LOGIN FAILED or LoGIn FaIlEd on a telnet
session port.
alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:”INFO TELNET Bad Login”; con-
tent: “Login failed”; nocase; flow:from_server,established;
classtype:bad-unknown; sid:492; rev:6;)
The “offset” option
Another tool that gives us a more precise scope on where in the packet to
look is the offset option. Offset works by skipping over the number of bytes
supplied to the right of the colon. So, offset:90 skips the first 90 bytes of
the packet and then begins searching for the string given as part of the con-
tent keyword. Offset and depth work nicely together to make the search area
of a packet limited to a window that is bracketed by the two. Basically, if you
know where to look and what to look for, you can use these two options to
help Snort get a fast grip on where to spend its time.
The Uniform Resource Identifier (URI) option
You can use the uricontent option to conduct a similar type of content
searching. Its purpose is similar to the depth and offset options: to reduce
the overall processing burden on Snort as it watches for more attacks to
effectively do its job.
The uricontent option works much like the content one, except it restricts
its searching to only URIs in the payload of the packet. URIs (Uniform
Resource Identifiers) in Snort can specify other protocols than http, such as
ftp, gopher, rsync, and https.
The uricontent option only searches for the given text in URIs that is found
in the packet. If URIs aren’t present, no match occurs. URI searching is good
for catching malicious commands that are readily evident as they often
appear in the location request to a Web server. The following rule from the
web-iis.rules file shows an exploit attempt against the IIS server using
both content and uricontent analysis:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS .asa HTTP
header buffer overflow attempt”; flow:to_server,established; con-
tent:”HTTP|2F|”; nocase; uricontent:”.asa”; nocase;
content:”|3A|”; content:”|0A|”; content:”|00|”; reference:bug-
traq,4476; classtype:web-application-attack; sid:1802; rev:4;)
A couple of interesting characteristics about this rule are worth discussing:
ߜ When nocase follows a string, its effect is upon the content string
immediately prior.
ߜ The nocase option has no effect upon binary search strings. Leaving it
off of those strings just helps the overall flow of the rule.
Classification
The classification options provide an overall description of a rule, along with
other helpful information about the rule, that can be used by the Snort pro-
gram itself and a system administrator. These options include the Snort ID,
the alert message to appear in the alert log, the rule revision number, the
alert priority, the alert classification, and external references for the exploit
or vulnerability that triggered the alert.
Snort IDs
Quite a few options help organize and classify detected alerts. The Snort ID
(sid) option is unique to the Snort system and a good way to get a handle on
classifications.
The format of the Snort ID value is the same as it as other classification
options. For example, a proper usage is as follows:
sid:;
When you get the hang of building your own sets of rules, assign each custom
rule a unique sid number somewhere above the 1,000,000 mark. That way,
updates to the Snort rule base won’t accidentally collide with your custom
rule. Table 8-1 gives you a breakdown of the uses for sid ranges.
default level and rate how important or impacting a particular rule is to your
unique environment. For example, the following command assigns the rule
associated with it the highest priority: 1.
priority:1;
Classtype
The classtype option can organize rules into major groups. A few dozen differ-
ent classification types are spread over three priority levels, which are
described in Tables 8-2, 8-3 and 8-4. For inclusion in a rule, the syntax is
classtype:;
Table 8-2 Priority 1 Classifications (Critical Severity)
classtype Description
Attempted privilege escalation to an
attempted-admin
Administrator level
Attempted privilege escalation to a User level
attempted-user
Discovered executable code
shellcode-detect
Achieved successful privilege escalation to an
successful-admin
Administrator level
Achieved successful privilege escalation to a
successful-user
User level
Discovered software code of a Trojan Network
trojan-activity
Attack
Failed privilege escalation to a User level
unsuccessful-user
Identified an attack upon a Web server’s appli-
web application attack
cation software
Table 8-3 Priority 2 Classifications (Intermediate Severity)
classtype Description
Attempted denial-of-service attack
attempted-dos
Attempted information collection
attempted-recon
(reconnaissance)
Potentially bad traffic seen (malformed)
bad-unknown
Denial-of-service attack possibly underway
denial-of-service
A catch-all category
misc-attack
Detection or use of a nonstandard protocol
non-standard-protocol
Portmap decode detected
rpc-portmap-decode
Denial of service detected
successful-dos
Large-scale information collection
successful –recon-
(reconnaissance)
largescale
Limited information collection (reconnaissance)
successful –recon-
limited
Strange or unusual filename was detected
suspicious-filename-
detect
Strange username was found attempting to
suspicious-login
login
System call was detected
suspicious-call-detect
A client was abnormally using a network port
unusual-client-port-
connection
Access was made to a potentially vulnerable
web-application-
web-app
activity
Table 8-4 Priority 3 Classifications (Low Severity)
classtype Description
A “ping” packet was detected
icmp-event
Some behavior was detected that may be
misc-activity
considered a policy warning
A host or network was being scanned
network-scan
Regular usage activity was detected
non-suspicious
A protocol instruction was decoded
protocol-command-decode
A pattern of specific bytes was detected
string-detect
Unknown or unclassified traffic
unknownRevision and versions
The Snort people thought ahead and even included a way to keep a version
tracking on each individual rule. The software industry uses many version
management schemes because the field is so fluid and so dynamic that tight
change control is almost a necessity. The format of the option is
rev:<#>;
Very few rules that come with Snort (less than 10 percent) have a revision
number of only 1. Busy enterprise networks are sometimes hostile and fast-
paced environments. Sometimes, rules are quickly added during the heat of a
malicious event so that immediate visibility is provided to the security man-
agers who must monitor the attack. After some analysis and a firmer under-
standing of the events takes shape, Snort’s rules are then revised (often only
subtly) to reflect what’s known about the event.
Messaging and output
The mesg option creates a customized output message that can be included
with any logs, alerts, and data dumps processed by the detection engine. By
looking through the rules directory, you can see that the fabricators of the
rules file have added messages to almost all the entries that they include.
The following is an example of the format of the mesg directive in use:
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:”SMTP sendmail 5.5.5
exploit”; flow:to_server,established; content:”mail
from|3a20227c|”; nocase; reference:arachnids,119;
classtype:attempted-admin; sid:662; rev:4;)
See how cleverly the Snort makers had the output of this mail exploit attempt
reported as “SMTP sendmail 5.5.5 exploit”? Describing the nature of an attack
in plain English helps you in the long run (especially when you’re searching
through logs at trying to track down a breach).
External references
The second most powerful (and widely used) feature within a Snort rule is
the external reference option. You can reference Web-based resources that
provide you with tons of additional data on an attack or probe right in the
Snort logs.
A few different formats are used. Nearly all are Web site front-ends that look
up an attack based on a unique identifier. For example, using the example in
the preceding section, we find the following: reference:arachnids,119;
Thanks to this command, when Snort encounters this Sendmail attack, it pro-
vides a URL where the user can find out more about the Sendmail attack.
Table 8-5 gives a list of Snort’s external references.
Keyword URL Base
bugtraq http://www.securityfocus.com/bid/
cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
arachNIDS http://www.whitehats.com/info/IDS
McAfee http://vil.nai.com/vil/content/v_
Nessus http://cgi.nessus.org/plugins/dump.php3?id=
url http:// (a general URL that’s passed straight through)
Proper use of the external keyword takes this form:
Reference:
You can tie together any number of reference options as long as they’re sepa-
rated by a semicolon.
Advanced options and deep dark secrets
The advanced options give you a peek into the dark side: the stuff of the
geek-chic and the wizards of computer security.
Flow control
The flow control option lets you define the direction of a network stream. All
network communications have two endpoints and a direction, so Snort can
be configured to alert whenever one of many other triggers is tripped. Snort’s
internal engine must do some fancier processing for the flow control (includ-
ing some on-the-fly packet reconstruction), but it’s certainly worth the over-
head because it lets you know whether an attack actually worked or not.
Regular expressions
A regular expression (regex in computer-nerd circles) is the incredibly power-
ful voodoo of using wildcards to match substrings within other strings.
Without jumping into the deep end of this black art, a regular expression
combined with a Snort rule makes for powerful mojo!
Protocol options
Because of Snort’s primary function to act as a low-level packet trap and fil-
tering device, it can make lots of specific selections based on granular net-
work protocol components. For example, sometimes hackers use specialized
or fragmented packets to tease at the edge of networks for information about
what they may find if they break in. These probing and recon expeditions
may otherwise go unnoticed by a system administrator or a security package
not configured to watch for such errant behavior. Snort’s native IP rules
options put a huge amount of power at your fingertips.
How does Snort deal with all those rules?
Managing the files and their contents, let alone keeping a huge decision tree
running, is a fine programmatic accomplishment.
Snort keeps track of all those intricate rules (some with more than 20 differ-
ent options) with some fancy data processing internally. Without getting too
bogged down, the process of reading in a particular rule is governed by a
string parser, which cuts apart the rule into its component parts, which are
then stored into a series of linked lists.
Snort is a busy, complex, and low-level application. Every small or subtle
error that goes undetected or that causes minor annoyances can snowball
into a huge performance issue under certain circumstances. Although it
doesn’t happen often, a misplaced command or configuration option can
cause downtime or data loss.
Rule Refinements
This section is the fun part of tweaking specific rules to match your environ-
ment. We recommend a regular strategy of nosing through your Snort output.
As time passes, the composition of your network changes, and the minefield
of vulnerabilities expands.
Trimming the fat
Likely the first refinement that any IDS guru recommends, almost to the point
of being a broken record, is to reduce your false positives by stripping the
dead wood from your rules files.
We recommend that you sit down with a map of your network and a list of
your network connected assets (operating systems and exposed services are
the most critical) and build a table of your computer resources that can be
attacked. From there you comment out those rules that just don’t matter. If
you have ten Windows NT servers running MS Project Server and nothing
else, there’s little need for a thousand Linux/Unix rules.
Commenting out unneeded rules is a simple matter: Just edit the file contain-
ing the rule and place a “#” before the first character of the rule type (gener-
ally “alert”).
Chapter 9 includes more tuning methods that reduce false positives and the
reasons why removing the extra noise keeps your Snort a-snorting.
Making adjustments
Small changes to the rules files of your setup can keep your Snort installation
running at peak efficiency. By refining the rules that you are already running
with Snort, you generate better reports, waste less time reviewing them, and
react faster.
Before editing any Snort rule file, it’s highly recommended that you do the
following:
ߜ Always make a backup of that rule file.
ߜ Make sure that you use a plain text editor that doesn’t add any funky for-
matting or characters when you save the file. The vi program in Linux
and Notepad in Windows are good examples.
Start by finding a rule that can use some tweaking. Maybe this DNS rule was
misclassed:
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:bad-unknown;
sid:253; rev:2;)
Out of the box, it’s classified as a “bad-unknown” alert. Maybe it should be
reclassified as a reconnaissance or information probe, consistent with an
“attempted-recon” tag. To change the rule, just edit the dns.rules (the file
that contains the rule we’re modifying) and change it to something like
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:attempted-recon;
sid:253; rev:3;)
We bumped up the revision number to 3 so that another person can see that
something’s changed.
If you plan on making lots of changes to the base rules that come with Snort,
keep a local backup copy of the original version outside of the directory that
Snort uses to manage its configuration. If you upgrade Snort without keeping
copies of all your custom tweaking, you may accidentally overwrite the
whole lot with one punch of the enter key!
Building a rule from whole cloth
In some cases, a new rule is needed. Situations that might require a new rule
include:
ߜ Some sort of odd behavior on the network has been noticed: Maybe an
abnormal amount of data is transferred on the network after hours, or a
particular server is rebooting for no apparent reason. An investigation
begins to determine what these oddities mean, and based on captured
network data, you can create a rule that matches the odd event.
ߜ A new attack hits the Internet. There are no existing Snort rules that
match the attack, so you decide to create a rule on your own.
For almost all configurations, the standard set of rules (if regularly updated)
can be just what the doctor ordered. The need to build a whole rule from
scratch isn’t an everyday occurrence.
Here’s a real-world situation that we can use as an example. While on-site at a
customer’s facility, we heard that its network was acting irrationally and that
the customer needed our help in isolating the cause of it. After an hour of
tracking back a huge amount of network bandwidth coming from two work-
station computers, we found that they were infected with some sort of virus.
We diagnosed a virus by running a packet sniffer and capturing all of those
workstations’ network communications.
All of that techno-sleuthing work we did can be best summarized into a
packet capture, or at least a fair approximation of one. What follows is a snip-
pet of what we were looking at:
15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376
0x0000 4500 0194 bec2 0000 6d11 d406 d963 055d E.......m....c.]
0x0010 d8ab 0224 1069 059a 0180 6b52 0401 0101 ...$.i....kR....
0x0020 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0030 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0040 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0050 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0060 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0070 0101 0101 0101 0101 0101 0101 01dc c9b0 ................
0x0080 42eb 0e01 0101 0101 0101 70ae 4201 70ae B.........p.B.p.
0x0090 4290 9090 9090 9090 9068 dcc9 b042 b801 B........h...B..
0x00a0 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1...P..5....P
0x00b0 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 ..Qh.dllhel32hke
0x00c0 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe
0x00d0 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf.llQh32.dhws2
0x00e0 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f.etQhsockf.toQ
0x00f0 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend....B.E.P..
0x0100 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E.P.E.P..P....
0x0110 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=U..Qt.....
0x0120 42ff 16ff d031 c951 5150 81f1 0301 049b B....1.QQP......
0x0130 81f1 0101 0101 518d 45cc 508b 45c0 50ff ......Q.E.P.E.P.
0x0140 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j...P.E.P.E
0x0150 c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 .P........ 192.168.4.81.1434: udp 376
Table 8-6 identifies the meaning of each of the preceding line’s component
elements.
Table 8-6 Components of Packet Trace
Description Value
Time packet was sent 15.30:05.000913
Source address 10.3.232.38
Description Value
Source port 1522
Destination address 192.168.4.81
Destination port 1434
Protocol UDP
Packet size (bytes) 376
All that’s needed from Table 8-6 are the protocol and the destination port.
The source IP address, source port, and destination IP address show up dif-
ferently when coming from and going to different systems. Remember, we’re
looking for new instances of this worm, not the infected systems we already
know about. Coupled with the signature that was scissored from that big
block of packet data, that’s the complete makings of a fledgling Snort rule. All
the pieces fit together like this:
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:”New MSSQL Worm A-
Multiplyin’”; content:”|c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45|”;
sid:1000001; rev:1;)
The preceding example highlights the following best-practices in creating a
Snort rule:
ߜ We followed the path of the good Snort administrator and made the
Snort ID equal to 1,000,000.
ߜ The revision is marked as 1, meaning that this attempt was our first at
drafting a rule to achieve the wanted results.
After testing, if our signature isn’t right or other elements need tweaking, we
can make the changes and increase the rev number to reflect the changes.

British man charged with hacking attacks

2011-09-26T09:07:00.000-07:00

A British man was charged Wednesday with mounting denial of service attacks on three websites, Scotland Yard announced.

Ryan Cleary, 19, was charged with attacking the websites of Britain's Serious Organised Crime Agency, British Phonographic Agency and International Federation of the Phonographic Industry.

He is due to appear in court Thursday, police said.

The alleged attacks all took place between October and June, police said.

The computer hacking group LulzSec denied Tuesday that Cleary was a significant member of the group.

SIA Approved Contractors in ITsecurity in UK

2011-09-26T08:54:00.000-07:00

May we introduce you to Network Securities UK, the premier guarding company in the UK.

We are an SIA approved security company offering security services throughout the UK from our operational centre in Leeds, West Yorkshire.

Why use Network Securities?

Our clients are personally account managed.
We meet your security needs with a one to one point of contact.
The highest possible levels of service at guarding and management levels.
We are an SIA approved contractor.
All our officers are SIA registered.
We have achieved SAFE contractor approved status.
Our headquarters have an excellent geographical location with improved motorway links.
We provide national coverage.
Our offices are manned 24/7 - 365 days of the year, a service unique to Network Securities UK.

SIA Approved Contractors

We insist that all our security officers hold valid SIA licences and we are proud to have been awarded SIA Approved Contractor Status as a security company. We strenuously recommend to any business or individual looking for security services to always engage SIA approved contractors as this SIA award confers the highest levels of trust, reliability and professionalism; something that Network Securities UK provides consistently whether in Leeds, Yorkshire or the wider UK.

Not every security company or provider of security services are SIA approved contractors. Since the founding of our company in Leeds and during our years of growth throughout Yorkshire we have encountered unsatisfactory security companies who do not have SIA approved contractor status and who are not able to offer security services to the consistently high standards of Network Securities UK. We believe that our commitment to reliable, professional security services is the reason why we are SIA Approved Contractors and the reason why we have successfully grown throughout Leeds, Yorkshire and the UK as a whole.

eScan ISS from MicroWorld

2011-09-24T23:21:00.000-07:00

4/2008
Virus has always been a daily problem for the end users. System is on
vulnerable state as soon as they are turned on. Which means, when they do file share
with other computer’s or over the Internet, they tend to be even more vulnerable to the viruses on loose in the Internet. This being the case, users who depend on information technology and
computer system for many different purposes would like to have a toolkit that takes of all
their headache to trace and find viruses within a system. More than finding one, it is best to quarantine and log the entire process of virus scans. Quick Start Installation is very simple as they are very similar to the Windows based installing software. It is a
point-and-click installation and the software will do everything else for you. Figure 1, shows the admin panel window of the eScan toolkit. It has very simple and elegant features for all kinds of users to use the tool. It can work on scheduled way and
always has different Active protection levels. The users can choose the drive to scan from
the On Demand window and click the “Scan”button. Once the scan is performed, a list of
malwares will be logged and displayed at the same time in order for the users to be aware
of the viruses spotted on their system. Figure 2, shows the scanning window that opens when
the user starts the scan. eScan is updated on a regular fashion and it makes it very easy for users
to do an auto-update check, where the software does everything for the users.
Advantages
It is quick and easy for installation, performing scan, running updates and choosing the various
modes of the software to run on. The manual is well structure for users who get stuck at some
point of time, when using this software. The logs store every granular detail of the scan, which
helps even the beginner level users to easily understand the virus-infected file. It updates very
frequently too. Disadvantage In general terms, a anti-virus products will always have its limitations. We can only have signatures for a known Malware, known to the security
researchers of an organization designing such products. Hence, anti-virus products cannot
identify certain viruses for which it does not have the signature. This is a major disadvantage for
any anti-virus software. Other than that, I did not see any other disadvantages running this
product. by Anushree Reddy, AOL Inc.

WHEN HACKERS ARE HACKED

2011-09-24T23:19:00.000-07:00

In the past few months there have been many discussions about hackers being
hacked back through the tools they use. The trend is steady and increasing.
More and more tools advertised in the most notorious hackers and security professionals
mailing lists and websites hide keyloggers or even rootkits.Penetration testing tools and brute forcers seem the most infected. While at the beginning this appeared as the attempt
of hackers to hack other hackers, some rumors and some (reverse engineering)
findings uncovered that the authorities may be behind this infection. With this new tactic
and new anti hacking-tools laws enforced in some European countries, tracking back
hacking tools consumers through rootkits can be the ultimate proof of crime.

ATM MACHINES EASILY HACKED, DO YOU NEED MONEY?

2011-09-24T23:05:00.000-07:00

When the SQL Slammer worm shut down over 10,000 ATM's belonging to Bank of
America there was a big surprise in the security industry. Nobody would have
suspected that such important machines were being powered by Windows PC's connected to the Internet.
Now, once again, researchers have demonstrated the possibility of stealing
the sensitive information that card holders entered into ATM's by hacking them with a
Windows 0 day exploit. Martin Macmillan, business development director with ATM
security specialist Level Four Software,
said that Banks have preferred to use common operating systems, like Windows,
to give intelligence to ATM's thus exposing them to the same risks of a home PC.
Keeping them secure translates into regular software updates and patching.
But further security problems due to poor design implementations in which only the
PIN is encrypted while card numbers and expiration dates are sent in the clear. In the
end the number of ATM's, counting all of those small machines not under the direct
control of the Banks, makes it very difficult for any large scale solution to work and
work in a timely fashion, to prevent the 0 day attacks. – another tough one!

Packet Fence 3.0.0

2011-09-24T11:17:00.003-07:00

PacketFence is a network access control (NAC) system. It is actively maintained and has been deployed in numerous large-scale institutions. It can be used to effectively secure networks, from small to very large heterogeneous networks. PacketFence provides NAC-oriented features such as registration of new network devices, detection of abnormal network activities including from remote snort sensors, isolation of problematic devices, remediation through a captive portal, and registration-based and scheduled vulnerability scans.

Changes: This is a major release focused on several new features. It has a redesigned captive portal, complete guest management including self-registration of devices by email activation or SMS, and pre-registered guest creation by administrators. It has a new feature to secure network access on unmanageable (consumer) devices (so-called inline enforcement). Bandwidth tracking with RADIUS accounting, RHEL / CentOS 6 support, and several usability improvements are in as well. Several things that annoyed the developers but that involved breaking changes have been fixed.

Packet Fence 3.0.0

2011-09-24T11:17:00.001-07:00

Nightwing 0.7.8

2011-09-24T11:16:00.001-07:00

Nightwing allows the creation of quickly deployed wireless networks without the need to make complicated configurations. With the implementation of a Mesh technology called B.A.T.M.A.N, Nightwing allows the extension of wireless networks with a simple way of adding devices that works with minimal human intervention. It has public and private connection interfaces, and the ability to filter content using OpenDNS. It is designed with security in mind, and has low hardware requirements.

Changes: This release allows you to make the Private AP optional, as well as the configuration for this new feature in nw_conf and the Web Admin Interface. Marking in the Traffic Shaping script has changed. Special characters are allowed in passwords in the Web Admin Interface. The layout of the Web Admin interface has changed. You can reboot uhttpd thru the Web Admin interface. The page is refreshed in some browsers after the config is applied. Wireless mode selection has been added to the config page.

Red Hat Security Advisory 2011-1326-01

2011-09-24T11:13:00.000-07:00

Red Hat Security Advisory 2011-1326-01 - Pango is a library used for the layout and rendering of internationalized text. A buffer overflow flaw was found in HarfBuzz, an OpenType text shaping engine used in Pango. If a user loaded a specially-crafted font file with an application that uses Pango, it could cause the application to crash or, possibly, execute arbitrary code with the privileges of the user running the application. Users of pango are advised to upgrade to these updated packages, which contain a backported patch to resolve this issue. After installing this update, you must restart your system or restart the X server for the update to take effect.

John The Ripper 1.7.8 Jumbo 7 release

2011-09-24T11:11:00.000-07:00

John the Ripper is a fast password cracker, currently available for many flavors of Unix, Windows, DOS, BeOS, and OpenVMS. Its primary purpose is to detect weak Unix passwords. It supports several crypt(3) password hash types commonly found on Unix systems, as well as Windows LM hashes. On top of this, many other hash types are added with contributed patches, and some are added in John the Ripper Pro.

Changes: Support for cracking of encrypted PKZIP archives, Mac OS X 10.7 salted SHA-512 hashes, and DES-based tripcodes has been added. Optional OpenMP parallelization has been added for salted SHA-1 hashes of Mac OS X 10.4-10.6. DIGEST-MD5 cracker has been revised to be usable without requiring source code customizations. Experimental support for dynamically loaded plugins has been added. ".include" directive support and duplicate rule suppression have been added for john.conf. Support for additional character encodings and related features has been added. Numerous other enhancements have been made.

Firewall Concepts

2011-09-24T10:57:00.000-07:00

Firewall Concepts

e="font-weight: bold; color: rgb(255, 0, 0);">
With all the possible security threats roaming around the Internet today, a security firewall should be considered a mandatory necessity for any computer systems connected to the Internet. A firewall is a networking device which is used to separate private networks from external access by providing a certain level of security rules and controls.

A simple firewall can be configured to block all access to certain networks, workstations and communication ports. A more complex firewall is capable of inspecting each individual packet that attempts to pass through it and ensures that they are correctly formatted and appropriate to the services provided for (or by) the internal network, this is called a packet filtering firewall.

This chapter will explain some of the concepts for iptables and packet forwarding which can be used to secure your private network. The example configurations provided in each section are only designed to provide an introduction into each of those specific sections, while an example firewall script has been included which will provide simple but effective security for your networked system.

Many of the newer broadband modems provide built-in firewall features that allow for stateful packet inspection and detailed network address translations, which are capable of providing a high security level for your internal network.

Packet Forwarding

Packet forwarding is a simple concept where the server allows data packets to pass from one network to another. As with the diagram below, packets from the private network are allowed to be forwarded through the server and out to the ISP and vice versa.

/-----------------------\
/-----------------\ | Server (Routing) | /-----------------\
| Private Network |------| eth1 : 192.168.1.1 | | ISP Connection |
| 192.168.1.0/24 | |-----------------------| | REMOTE IP ADDR |
\-----------------/ | eth0 : 123.123.123.2 |------| 123.123.123.1 |
\-----------------------/ \-----------------/

There are a few initial considerations. First, the server must have networks or gateways defined in its routing table so it can make an informed decision where the packet needs to be passed to. Second, the server must have packet forwarding enabled. Thirdly, if the routed packets came from an RFC1918 private subnet, they must be translated into globally routed IP addresses (NAT covered later) before they will be accepted out on the Internet.

Packet forwarding can be enabled either manually as required by the superuser, or automatically when the system starts the networking service. To manually enable or disable packet forwarding, use the respective commands listed below.

[bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# echo 0 > /proc/sys/net/ipv4/ip_forward

To enable automatic packet forwarding for whenever the network service is active, make the following changes in your /etc/sysctl.conf file.

[bash]# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

It is common practice for users to have manual control over packet forwarding, and to active or disable the function within their firewall control scripts. However setting packet forwarding to start automatically will be more suitable for a dedicated server.

Packet Filtering

Packet filtering is also a reasonably simple concept (true), however it can be very daunting for new users that don't fully understand how it works, so let's cover the basics first and build it up.

In packet forwarding the kernel is either allowed to move packets between different subnets or is not, and if it is, the decisions are made from the kernel's routing table. In packet filtering an application called iptables (www.netfilter.org) stores a list of programmed rules which are individually tested against every packet that either tries to enter, pass through, or exit any of the system's network devices. Each rule is used to test the packet in a sequential order and if the packet matches any of the rules it is either accepted or rejected depending on the global policy and rule definitions. iptables is your firewall application and is one of the networking frameworks for your Linux kernel.

iptables essentially has this name because it stores the rulesets into a group of three tables which each provide different capabilities depending on the rules and the order they are applied. We will only examine the filter and nat tables here, the mangle table is used for specialised packet alteration which is beyond our scope. The following table displays the filter iptables and the three built-in chains.

Table Name	Chain Name	Chain Details
filter	INPUT	For any packet coming into the system
	FORWARD	For any packet that is being routed through the system
	OUTPUT	For any packet that is leaving the system

To list the filter table and its rules you can use the following command.

[bash]# iptables -t filter -nvL

The filter table is the default table when working with iptables, so there is no need to add '-t filter' at the command prompt.

[bash]# iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

You should see an output similar to above, if not then stop the iptables service and output the table again. From the listing you can see the three built in chains, and their default policies are all set to ACCEPT, which means the firewall is inactive.

[bash]# /etc/init.d/iptables stop

The output from the top listing does not provide much information, so let's populate the table with some of our own rules. Type the following commands at the prompt then output a listing of the table again.

01- [bash]# iptables -P INPUT DROP
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT DROP
04- [bash]# iptables -A INPUT -i lo -j ACCEPT
05- [bash]# iptables -A OUTPUT -o lo -j ACCEPT
06- [bash]# iptables -A INPUT -i ppp0 -p tcp --sport 80 -j ACCEPT
07- [bash]# iptables -A OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT
08- [bash]# iptables -A INPUT -i eth1 -s 192.168.1.0/24 -p tcp --dport 3128 -j ACCEPT
09- [bash]# iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -p tcp --sport 3128 -j ACCEPT

[bash]# iptables -nvL

01-

04-
06-
08-

02-

03-

05-
07-
09-

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 ACCEPT tcp -- eth1 * 192.168.1.0/24 0.0.0.0/0 tcp dpt:3128

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * eth1 0.0.0.0/0 192.168.1.0/24 tcp spt:3128

The nine commands which you typed above have been numbered along with their output so they can be easily identified in the second table.

Lines 01-03: The first three commands set the default (-P) policy on all the chains to DROP everything, unless suitable rules inside the chain will ACCEPT them. This is the most secure method of filtering as any packet that is now to pass through any of the chains, must have a specific rule written for it.

Lines 04-05: These two commands have (-A) appended two ACCEPT rules. The OUTPUT rule (05) allows any packet to (-o) leave via the loopback device and the INPUT rule (04) allows packets to re-enter (-i) via the loopback.

Because the chains are using a default DROP policy, they restrict the server from accessing any of its own services running on the local host, like DNS. A basic rule like this allows the server to access all loopback services without restriction.

Lines 06-07: The next two (-A) appended rules are more specific, lets look at the outbound one first. The OUTPUT rule (07) specifies that any packet going out the (-o) ppp0 interface using (-p) protocol TCP is ACCEPTed if its going to port 80. The INPUT rule (06) specifies that any packet coming in the (-i) ppp0 interface using (-p) protocol TCP is ACCEPTed if its coming from port 80.

You should be able to pick this up, it says that we are allowed to access external web servers from our own server, but there are no forward rules for the internal network to surf the Internet. We should also allow our internal network the ability to access external web servers too shouldn't we? Let's look at the next rules then.

Lines 08-09: The last INPUT rule (08) which has been (-A) appended to the chain allows any packets from the (-s) source network of 192.168.1.0/24 if they enter through the (-i) eth1 device and if they are the TCP (-p) protocol and are going to the (--dport) destination port of 3128. The matching OUTPUT rule (09) has been (-A) appended to the chain and allows any packets that are going out (-o) the eth1 interface to (-d) destination network 192.168.1.0/24 using the TCP (-p) protocol if it came from the (--sport) source port of 3128.

These two are fairly detailed rules, they say that anyone on the internal network (192.168.1.0/24) is allowed to send packets to the squid proxy server (3128) through the internal eth1 interface and the results can be returned to the workstation.

If you use a strict DROP policy like above, its important to note that you may need two rules that complement each other in order for data to flow out and back in again.

A Walk Through

To better understand the above filtering example, its best to walk the configuration through the same way a packet would be subject to the filtering table's definitions, one rule at a time. Remember, every packet of data has certain attributes, source/destination addresses, source/destination ports, the interfaces they are coming in and out and the type of protocol being used, the filtering will reject any packet whose attributes dont match any of the rules in our chains.

A person using the workstation (in the network example below) wishes to access the resources of the web server located on the Internet, can a direct connection be established? No, all the policies are set to DROP and there is no FORWARD rules defined, so it simply can not occur.

Can the proxy server access the web server on the Internet? Yes, the proxy server has the rights to access anything which is TCP based operating at port 80 out through the ppp0 link, which is to a web server. Can you see the ACCEPT rules for the packet's attributes in the complementing INPUT and OUTPUT chains?

/-----------------------\
/-----------------\ | Proxy Server (3128) | /---------------\
| Workstation |------| eth1 : 192.168.1.1 | | Web Server |
| 192.168.1.10 | | ppp0 : 123.123.123.2 |------| (TCP port 80) |
\-----------------/ | lo : 127.0.0.1 | \---------------/
\-----------------------/

The only way now for the workstation to access anything, is via the proxy server application running at port 3128, which in turn can access any web server resources on the Internet and return the requested information to the workstation. Are the required rules in the table?

How does this work without any forwarding rules? Easy, the proxy server is an application that requests resources on behalf of a client, so the request comes into the proxy from the client, and now the request goes out to the web server from the proxy, as though it was requesting the information itself. This happens at the application layer, because its the proxy application which forwards the clients original request, so forwarding at the IP layer is not required here.

Hopefully you have been able to pick up the filtering concepts mentioned above, if you have, well done. The proxy server situation was a little tricky, but was introduced to give you an understanding that particular packets and resources can still be shaped to suit your security requirements by incorporating them into your network design.

Thats a brief introduction to packet filtering, the ability to write and chain together rules that selectively accept or deny any packets that do not meet the security requirements for your network.

What happens to the filter table when you type these following commands? View the table's output after each one and see if you can recognise the effects of the rules, and which direction the packets can pass (i.e., are they going to an internal or external resource). View "man iptables" for further assistance.

[bash]# iptables -I INPUT 2 -i ppp0 -p tcp --dport ftp -j ACCEPT
[bash]# iptables -I OUTPUT 2 -o ppp0 -p tcp --sport ftp -j ACCEPT

[bash]# iptables -D INPUT -i ppp0 -p tcp --sport 80 -j ACCEPT
[bash]# iptables -D OUTPUT -o ppp0 -p tcp --dport 80 -j ACCEPT

[bash]# iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
[bash]# iptables -A OUTPUT -p icmp --icmp-type any -j ACCEPT

[bash]# iptables -I INPUT -m state --state INVALID -j LOG --log-prefix "INVALID Input: "
[bash]# iptables -I INPUT -m state --state INVALID -j DROP

[bash]# iptables -F
[bash]# /etc/init.d/iptables restart

Network Address Translation

Network Address Translation (NAT) is the ability to change a data packets destination or source IP address on-the-fly, so the packet looks like it came from (or is going to) a different address than the original (also works on port numbers).

There are many reasons why we should use NAT, here are a few:

Frees the requirement to use large amounts of 'real' IP addresses (cheaper),
Allows packets from a private (RFC1918) network to be globally routed out to the Internet,
Allows packets on the Internet to be routed into a private (RFC1918) network,
It masks the true amount of private workstations, as all external traffic appears to come from the one source,
It allows inbound traffic to be sent to different internal hosts (bastions) depending on the resources requested, and
It does not disclose any security details of the internal private network.

The iptables package also provides support for NAT and has a built-in nat table just for that purpose. Below is a listing of the default chains that are found in the nat table and an explanation of how they are applied.

Table Name	Chain Name	Chain Details
nat	PREROUTING	For altering packets as they are entering the system (before filter INPUT)
	POSTROUTING	For altering packets as they are exiting the system (after filter OUTPUT)
	OUTPUT	For altering packets before leaving the local system (before the routing table)

As the naming suggests, the PREROUTING and POSTROUTING chains are applied before or after any kernel routing decisions are made, so the packets can then be routed to match any new changes which have been made to the destination or source addresses.

To list the contents of the nat table, issue the following command at the prompt.

[bash]# iptables -t nat -nvL

Source NAT

Source NAT deals with changing the source address of any packets that pass through the NAT device, assuming they meet the criteria of the specified policies and chains. This allows workstations on a private network to send data packets through the NAT device which changes the source address in the packet's header before sending the packet onto the Internet. When the packet reaches its destination and is processed, the distant host returns the packet using the adjusted address as the new destination address, and delivers it back to the NAT device. The NAT device stores a list in memory of all the packets it adjusts, so when they are returned, the packets can be redirected to the real originator of the packets on the internal private network.

Source NAT can be written for inbound and outbound packets, but are more commonly used for outbound.

For a packet to be subject to SNAT, lets consider the following details:

The packet has meet at least one rule in all three filter chains (INPUT, FORWARD, OUTPUT),
The packet has been checked against the kernel routing table, and a decision on where to route has been made,
As the packet leaves the NAT device, the source address is changed to the NATs external IP address,
The NAT device remembers the real owner of the packet.

It all sounds rather confusing, so lets go straight to an example. Type the following rules at the command prompt and then display the contents of the filter and nat tables with the last command (typed as one line).

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -p tcp --dport 80 -j ACCEPT
05- [bash]# iptables -A FORWARD -i ppp0 -o eth1 -d 192.168.1.0/24 -p tcp --sport 80 -j ACCEPT
06- [bash]# iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j SNAT --to-source 123.123.123.2
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth1 ppp0 192.168.1.0/24 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- ppp0 eth1 0.0.0.0/0 192.168.1.0/24 tcp spt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT all -- * ppp0 192.168.1.0/24 0.0.0.0/0 to:123.123.123.2

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Lines 01-03: The first three commands have now defined the global policies for the three built-in chains for the filter table.

To keep the example a little easier to understand, we are going to accept everything that is classed as INPUT or OUTPUT, and for security we are dropping anything trying to pass through (FORWARD) the NAT unless we allow it.

Lines 04-05: The two forward rules are quite specific. Rule 04 says that any packet that comes in (-i) the eth1 interface and goes (-o) out the ppp0 device from the (-s) source network of 192.168.1.0/24 can be ACCEPTed if its going to (--dport) destination port 80; a web server. Rule 05 is the matching rule allowing the packet to return back through the NAT.

We don't have any INPUT or OUTPUT restrictions here, so we only need to write and match rules that allow packets to pass through (FORWARD) the NAT. In the diagram below, when a HTTP(80) request comes from the private network, it is allowed to pass through the NAT and continue to the web server out on the Internet. But what are the packet's attributes? Its source address is still 192.168.1.x, so when it reaches its destination, the web server does not know where it came from because its a private non-routable RFC1918 IP address, so the server will probably just drop it. No packets will ever be returned.

/-----------------------\
/-----------------\ | NAT Gateway Device | /---------------\
| Private Network |------| eth1 : 192.168.1.1 | | Web Server |
| 192.168.1.0/24 | | ppp0 : 123.123.123.2 |------| (TCP port 80) |
\-----------------/ \-----------------------/ \---------------/

Line 06: This rule is our solution to the above problem. This rule is applied after the routing decisions have been made and the packet is about to depart for the web server out on the Internet. It says, any packet that goes (-o) out the ppp0 interface from the (-s) 192.168.1.0/24 network is to have the source address rewritten as 123.123.123.2.

Now when the packet reaches the Internet web server, it can be processed normally and returned to 123.123.123.2 (the NAT device), where it will automatically be rewritten again and sent back to the original workstation on the internal private network.

Line 07: This command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

Some important points about SNAT to remember are:

SNAT is used in the POSTROUTING chain after the kernel routing decisions have been made,
Forwarding rules need to be suitable to allow packets in both directions,
The "--to-source" address should be the external IP address which will be visible on the packets return, and
SNAT should not be used for dynamic links where the IP address is likely to change (see masquerading, next).

IP Masquerading

Put simply, masquerading is a form of SNAT which should be used for all dynamic interfaces where the IP address is likely to be different each time we connect. This is perfect for our dynamic IP broadband accounts, and saves having to rewrite large SNAT rules each time we connect to the Internet. SNAT remembers connection state information (to a degree) if a static connection was to drop, however using masquerading the connection state information is reset each time the interface is (de)activated. Masquerading automates SNAT for dynamic IP connections.

Because masquerading is so easy (true) we are going to use some state tracking attributes in our rules. Type the following rules at the command prompt and display a listing of the filter and nat tables.

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
05- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
06- [bash]# iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- eth1 ppp0 192.168.1.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * ppp0 192.168.1.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Lines 01-03: The first three commands have now defined the global policies for the three built-in chains for the filter table.

To keep the example a little easier to understand, we are going to accept everything that is classed as INPUT or OUTPUT, and for security we are dropping anything trying to pass through (FORWARD) the NAT unless we explicitly allow it.

Line 04: Rule 04 deals with the connection state and says, any packet that comes in the (-i) ppp0 interface must (-m) match a certain state, and the state must ensure the packet is in response to an already RELATED or ESTABLISHED connection.

Basically only allow packets to be forwarded into the private network if the packet is in response to an already RELATED or ESTABLISH connection. This rule will not allow any NEW connections to be initiated from the external network a connection must already existed, so any packet coming inside will be in response to a current connection that could have only be initiated from the internal network.

Line 05: This is a simple rule that will forward any packets from the (-i) eth1 interface and out the (-o) ppp0 interface if they are from the (-s) 192.168.1.0/24 source network.

This is rule does not detail any connection state so it will allow all connection types, but most important is the NEW connection state that it can pass. This rule allows internal workstations to create new connections, and matches rule 4 which allow the packets to return.

Line 06: This rule does the exact same as if it were a SNAT rule, however being a MASQUERADE rule means it will use the IP address that is currently assigned to the ppp0 interface when the packet passes through the NAT device.

Any packets that now pass from the internal private network out into the Internet will have its source address rewritten as the external IP address of the NAT device.

Line 07: This command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

Remember, masquerading should always be used for dynamic IP connections.

Dangerous Masquerading Rule

Beware of this rule, it is too relaxed and does not specify which direction the packets should be masqueraded. In fact, this rule allows masquerading in BOTH directions. Always specify an (-o) out interface parameter to make the rule work in one direction only.

[bash]# iptables -t nat -A POSTROUTING -j MASQUERADE

WARNING: The above rule is dangerous, it allows masquerading in both directions.

Destination NAT

Destination NAT deals with changing the destination address of any packets before they are subjected to any routing decisions. This allows specific traffic to be rewritten so it suits a particular rule and can then be redirected depending on the global policies and destinations required.

In its most typical application, DNAT is normally used to change incoming packets that are destined for a particular service or host, and it rewrites the destination addresses so the packets can pass to a different host located inside the private network, normally a DMZ.

When DNAT occurs, the original host (which is located external of the private network) is not aware the packets have been redirected and that the returning data is from a different server. It should be transparent to the originator.

The following commands can be typed at the command prompt, and the filter and nat tables displayed using the last command.

01- [bash]# iptables -P INPUT ACCEPT
02- [bash]# iptables -P FORWARD DROP
03- [bash]# iptables -P OUTPUT ACCEPT
04- [bash]# iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
05- [bash]# iptables -A FORWARD -i ppp0 -o eth1 -p tcp --dport 80 -j ACCEPT
06- [bash]# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80
07- [bash]# echo 1 > /proc/sys/net/ipv4/ip_forward

[bash]# iptables -nvL ; iptables -t nat -nvL

01-

02-

04-
05-

03-

06-

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- eth1 ppp0 192.168.1.0/24 0.0.0.0/0
0 0 ACCEPT tcp -- ppp0 eth1 0.0.0.0/0 192.168.1.0/24 tcp dpt:80

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.1.2:80

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Lines 01-03: The first three commands have now defined the global policies for the three built-in chains for the filter table.

To keep the example a little easier to understand, we are going to accept everything that is classed as INPUT or OUTPUT, and for security we are dropping anything trying to pass through the NAT unless we allow it.

Line 04-05: The first FORWARD rule (04) allows any packets coming in the (-i) eth1 interface and out the (-o) ppp0 interface if they have come from the internal (-s) source 192.168.1.0/24 network. The second FORWARD rule (05) allows any packets coming in the (-i) ppp0 interface and out the (-o) eth1 interface that are using the TCP (-p) protocol if they are going to (--dport) destination port 80.

These two rules complement each other, the first allows outgoing packets to be forwarded from the internal network and the second rule allows incoming packets to be forwarded into the private network but only if they are going to a web server (port 80).

Is this going to work? Well lets look at the incoming packet's attributes with the following diagram. The remote host that originally sent the data requested a web page URL of "http://www.example.com" which resolved to the IP address of 123.123.123.2 and the packet was sent on its way. When it arrives at the NAT device, the destination address is still 123.123.123.2 so it must be handled by that IP address or rejected. But the web server is inside the network, what do we do?

/-----------------------\
/---------------------\ | Server (Routing) | /-----------------\
| Internal Web Server |------| eth1 : 192.168.1.1 | | Remote Computer |
| 192.168.1.2(80) | | ppp0 : 123.123.123.2 |------| (Internet Zone) |
\---------------------/ \-----------------------/ \-----------------/

This is where DNAT is able to change the destination address of the incoming packet, and put the new address in its place (192.168.1.2(80)). Because DNAT is PREROUTING, the packet is now subjected to the kernel routing table which points the new packet to the internal network. Lastly, there must exist a rule in the FORWARD chain which will allow the packet to pass through, and there is, rule 05.

Line 06: This is a PREROUTING rule in the nat table, if any packets come in through the (-i) ppp0 interface and are (-p) TCP packets going to (--dport) destination of port 80, then they are to be rewritten and sent to the host 192.168.1.2:80 instead.

Line 07: This command tells the kernel that it is allowed to forward packets between any of its network devices. These packets are still subject to the iptables rulesets.

DNAT declarations are reasonably easy because the destination header can be rewritten before the routing table is queried. Some important points to remember are:

DNAT can rewrite packets as they enter the Firewall (before routing),
If the new destination host is hacked, the Firewall host is not affected,
Do not DNAT a packet to another system that will DNAT it back (routing loops),
The "--to-destination" address does not have to be on the internal network, and
DNAT can also be used internally to protect vital systems from nasty employees.

Example Firewall Script

The following is an example firewall script which uses all of the concepts covered already in this chapter. It should therefore be relatively easy to understand, implement and maintain.

The firewall script is designed to separate and secure the private network (eth1) from the Internet traffic (ppp0), while providing some flexibility for the internal network which is being masqueraded.

[bash]# vi /root/firewall.sh

#!/bin/sh
#
# Example Firewall Script

###############################################################
### Define interfaces here
EXT_DEV=ppp0
INT_DEV=eth1
INT_NET=192.168.1.0/24

### Loading firewall modules
modprobe ip_conntrack
modprobe ip_conntrack_ftp

###############################################################
### Enable Packet Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

### Remove all previous rules, and delete any user defined chains
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

### Set the default policies to drop
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

### Loopback device OK
iptables -A INPUT -i lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

### Allow all ICMP Traffic (optional) - IN, OUT and THROUGH.
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type any -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type any -j ACCEPT

### Allow all Internal traffic to Server
iptables -A INPUT -i $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT
iptables -A OUTPUT -o $INT_DEV -s $INT_NET -d $INT_NET -j ACCEPT

###############################################################
### OUTBOUND Rule: Allow ALL packets out the external device
iptables -A OUTPUT -o $EXT_DEV -j ACCEPT
iptables -A FORWARD -i $INT_DEV -o $EXT_DEV -j ACCEPT

###############################################################
### MASQUERADING: All packets from the internal network will
### appear as if they had originated from the firewall.
iptables -t nat -A POSTROUTING -o $EXT_DEV -s $INT_NET -j MASQUERADE

###############################################################
### INBOUND Rule: Allow ALL EXT packets if a connection already exists (See "NEW" Inbound Rules)
iptables -A INPUT -i $EXT_DEV -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $EXT_DEV -m state --state RELATED,ESTABLISHED -j ACCEPT

#
### INBOUND Rules: Allow ONLY NEW packets on these ports.
#

# New INBOUND Connection: FTP (with TLS)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 20 -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 21 -j ACCEPT

# New INBOUND Connection: Secure Shell
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 22 -j ACCEPT

# New INBOUND Connection: SMTP and SMTPS (over TLS/SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 25 -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 465 -j ACCEPT

# New INBOUND Connection: HTTP (Plain and SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 80 -j ACCEPT
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 443 -j ACCEPT

# New INBOUND Connection: LDAPS Server (over SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 636 -j ACCEPT

# New INBOUND Connection: IMAPS Email Clients (over SSL)
iptables -A INPUT -i $EXT_DEV -m state --state NEW -m tcp -p tcp --syn --dport 993 -j ACCEPT

###
# Squid Transparent Proxy: Enable rule for transparent proxy redirection
# Redirect all WWW (port 80) OUTBOUNT packets to the Squid Server on port 3128
#iptables -t nat -A PREROUTING -i $INT_DEV -s $INT_NET -p tcp --dport 80 -j REDIRECT --to-port 3128

#
### INBOUND DNAT (redirection) Rules: Allow ONLY NEW packets on these ports and redirect to internal services.
#

### INBOUND Rule: Redirect ALL packets to the INTERNAL workstation - HTTP
#iptables -t nat -A PREROUTING -i $EXT_DEV -p tcp --dport 80 -j DNAT --to-destination wkstn1.example.com:80
#iptables -A FORWARD -i $EXT_DEV -o $INT_DEV -p tcp --dport 80 -j ACCEPT

### INBOUND Rule: Redirect ALL packets to the INTERNAL workstation - HTTPS
#iptables -t nat -A PREROUTING -i $EXT_DEV -p tcp --dport 443 -j DNAT --to-destination wkstn1.example.com:443
#iptables -A FORWARD -i $EXT_DEV -o $INT_DEV -p tcp --dport 443 -j ACCEPT

After the firewall script has been executed and the new firewall rules are active, the iptable settings can be saved so they are automatically implemented when the firewall is next started.

[bash]# sh /root/firewall.sh
[bash]# /etc/init.d/iptables save

You should now restart the iptables service and see if the tables and chains are the same.

[bash]# /etc/init.d/iptables restart
[bash]# iptables -nvL ; iptables -t nat -nvL

If you intend to use the initscripts to automatically start the iptables service, then any firewall modules that are needed will have to be manually added to the init script.

[bash]# vi /etc/init.d/iptables

IPTABLES_MODULES="ip_conntrack ip_conntrack_ftp"

You can check to see if the modules loaded automatically by listing all of modules currently being used by the kernel.

[bash]# lsmod