How an IDS Works

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 communi­cations 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 secu­rity 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 mon­itoring 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

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

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.