NGIPS

Snort introduced ips and it was open source, the engine. Later on sourcefire company used that engine
and created a new device called source fire 3d system, but it wasn’t open source. Later on cisco acquired
sourcefire.

There were 3 products under sourcefire: ngips, fmc, ftd. FMC were earlier know as defence center with
version 5.3.0, this version was given by sourcefire, and it was know as sourcefire defense system, source
fire ngip and source fire ftd. The terms has been changed because company has been acquired by cisco.
Till 5.4 cisco called it as firesight and then onwards it calls it as firepower (refer above table). So the new
terms are firepower ngips: with version 6.x, and same with other devices. Before version 6.x, we used
firesight before ngips, ftd and fmc. FMC is used to manage ngips and ftd. Have to integrate ngips and ftd
wit fmc in order to manage it.

Fmc also have different terms with version: version 5.3.0.x we used to call it as defense center and it
was owned by sourcefire. The version 5.3.0.x is owned by sourcefire. CCIE security has version 6.x for all
the devices.

Panel of NGIPS:
Management int: we assign ip address for remote access then we can do the management. We can take
access via https, telnet or ssh. We cannot take direct access to ngips, we integrate ngips with fmc. FMC
communicates with ngips via tcp protocol. We take https access of ngips with fmc. The console access
can be taken via ssh, telnet is not available. Three services are enable in ngips: https, https, and ping.

Management port is use to manage ngips.

Sensing interfaces: there are 8 interfaces. We cannot configure ip addresses. Only use to receiving and
transmitting traffic. We can configure it in different modes: ips mode, ids mode. Ips mode is known as
inline mode and ids mode is known as promiscuous mode or tap mode or passive mode.

How it works in ids mode:

M0/0, f0/0 and e0/1 belongs to one vlan and subnet, which is inside of the network. PC at .200 is use to
access ngips. At the outside segment. G0/0, e0/0, and g0/0 of r2 is on vlan 102. We use SPAN and RSPAN
in this scenario. When the packet is generated on g0/0 of r2, the copy of packet goes to ips g0/0 on vlan
102. This is ids mode because we are getting only the copy of packet. The packet received on sensing
interface is matched with signature database, but not by default, we have to configure it. By default ,
the interface is not connected with signature database, we have to manually configure it. In signature db
we have multiple categories like social networking, video streaming etc. under each category there will a
signature. The packet content is checked for malware with the help of signatures. If the ids finds any
malicious activity, but in ids mode we cannot take any action, we can only use it for analyzing purpose.
Using for generating alerts and reports. For ids we need only one interface.

SPAN: if I have a single switch, and on single sw one of the int is connected to pc and and another int to
wireshark.

RSPAN:
On switch1:

Sw1>source int f0/1

Destination vlan 55 and have to indicate that 555 is rspan vlan.

Have to configure vtp so that vlan 555 should be replicated on all the switches. The packet is copied
from int f0/1 to vlan 555. That vlan is present on all the switches. On switch 3

Sw3> source vlan 555 and destination is int f0/1.

Inline/ Ips mode:

In this mode we have to two deployments: interface pairing and vlan pairing.

Interface pairing: we need two different sensing interface.

We have deployed NGIPS in inside part of ASA with two sensing interfaces. The traffic coming in one
interface should go out from other interface and vice-versa. In this case we have to create interface
pairing. We have to pair e1 and e2 of ngips.

Assume a switch

When r1 will try to reach ASA. Switch will broadcast, asa will reply back , and second time the packet
from r1 will directly go to asa. In this case the packet will directly go to asa not to the ngips, as all the
ports are in same vlan. So we create 2 vlans. R1 port and e1 should be in one vlan and ASA port and e2
should be in another vlan, but r1 and asa should be in same subnet, with this kind of scenario the traffic
will pass through ngips.

Problem: the mac address of asa g0/0 interface will be available at e1 because the reply from ASA will
come from e1, as we paired e1 and e2. The interface of ngips works like switch interfaces, without mac
and ip addresses.

Inline vlan pair interface: The single interface of ips can be devided int two subinterfaces. The one int
will be in vlan 22 and other will be in vlan 2. The traffic in this case will flow like.
In inline vlan pair we can deploy 8 ips, but with inline interface we can deploy 4 ips. With ids we can
deploy 8.

We use port tcp 8305 for integration purpose. Integration of ngips with fmc. If the port number is
changed then the integration wont work.
The virtual means software and hardware are available for NGIPS. The hardware versions are FP 7000
and FP 8000. We handle multiple NGIPS with the help of FMC. Only firepower devices can be managed
thru FMC or FDM( firepower device manager). Till 6.2.2 version FDM was not available, only present
with the hardware, comes with operating system. From 6.2.3 version FDM was available with hardware
and software or virtual.

FMC and FDM are not cloud based. Cisco CDO (cisco defense orchestrator) is a cloud based service used
to integrate all the firepower devices, can access devices from anywhere. You need to check weather it
is supported in the devices or not. CDO is for firewall only.

FMC MODELS:

TALOS is used to provide updates on the devices.

Why we call it NGIPS (next generation): because it has a functionality of filtering the all the application
or threats passing thru the application. Application visibility feature. Traditional IPS does not have much
visibility on layer 7, and was not able to do decryption, do not have AMP means no visibility for
advanced malware protection (prevention from zero-day attacks or unknown attacks). AMP is a cloud-
based service or a physical device.

On the new NGIPS we can do the app and URL filtering. App can be filtered based on ports or services.
Threat filtering is also available in NGIPS. NGIPS can eliminate the use of WSA.

ATTACK PHASE:

> Firewall is used in before phase to allow or deny traffic.

>During phase the contents of files has been checked and NGIPS comes in to play.

>AMP and ISE is used in after phase.

By default, when the data is received at sensing interface it will not matched against signatures
database, we have to configure it manually.

Signatures:
Firewall does packet based inspection and NGIPS do content based inspection:

Attacker can send script in the data payload of the packet to perform an attack. NGIP is able to detect
these kind of attack because it does content based inspection, and hash value generated. Hash value is
already present with the signature, and it is generated based on exploited codes.
Balanced security in firewall enables the important signatures and disables other signature. It is not
recommended to enable all the signatures as IPS won’t be able to handle load.

In the case of IDS and IPS, we need signatures. In IDS, we just enable signature to generate alerts and in
IPS we define action(allow/drop) with each enabled signature or we can also generate alerts. The action
is already defined with the signature, we don not have to manually tune it.

Types of signature: system defined, and user defined:

Drop: packet is not forwarded

Reset: connection is getting resettled. Prompting for connection again and again. In case, if we have a
tftp server or any server from which we want to download the file. Whenever we are downloading a
good file it will be allowed, but if we are downloading bad file the connection will be resetted. We can
re-initiate the connection.

Block: if we are giving wrong username of password for 3 times, we will get blocked for certain time.

Shun: suspending the access.

LAB:

On exsi server open:

On FMC:
Revert fmc to fresh snapshot: Fresh_Machine

Username: admin pass:Admin123

On ASA: clear configure all

G0/0: inside; g0/1:outside, and management for network adapter 1

Change network adaptor 2: Inline_out; network adaptor 3:outside

Sh flash: to check if you have ASDM or whether you have pre-installed asdm in the admin pc.

To give http access of asa to admin pc:

On Inside router:
Network adaptor 2: inline_in

On test pc: (windows 7)

ip address: 192.1.20.12/24
gateway: 192.1.20.10
network adaptor 1: outside
ping 192.1.20.10 should be able to ping.

On ADMIN PC:
Ping 150.1.7.20
Go to web(firefox) :https://150.1.7.20 username:admin password: Admin123 (gui access of FMC)(initially
it takes time to login)
Network adaptor 1: mgmt.
Open asdm and take an access of ASA. (username:admin ; password:cisco)

On NGIPS: (NGIPS_morning)(revert snapshot to Fresh_machine)

Username:admin; password:Admin123
Integrating NGIPS with FMC:

Revert both NGIPS and FMC with fresh machine. Login to cli mode in ngips and fmc with
username:admin and password:Admin123.
On NGIPS you must accept the agreement by hitting enter and giving new password.

Initial configuration on NGIPS:

Press enter two times to configure the NGIPS for inline mode.
Network adaptor 1: E1 and network adaptor 2: E2. Make sure it is connected and power on.

Initial configuration on FMC:

From admin pc check the connectivity by pinging: fmc,ngips and asa.

Taking access of FMC from admin pc: open firefox and: https://150.1.7.20/ username:admin
password:Admin123

After getting http access of fmc:

Accept the agreement. >apply.
You have to put the FMC in evaluation mode so that you can use it for 90 days: system>license>smart
license> put it in evaluation mode.

You first have to add FMC in NGIPS thru cli mode:

cisco is the secret key used for

integration purpose, with the p address of fmc.

From fmc cli ping ngips:

On fmc gui: devices> device management> add > add device:
Creating paket filterning policies in NGIPS via FMC:

By default, when you configure the NGIPS in inline mode. Interface e1 and e2 work like a bridge
interfaces and are paired, which will allow all the traffic. The default action block all traffic will not allow
any traffic between e1 and e2. The intrusion prevention action will allow all the traffic and there wont
be any restriction.

After registration go to edit section of NGIPS and check interface and inline sets sections. As we
configured block all traffic as the base policy, the implicit action will be deny. In order to allow traffic to
pass thru NGIPS, we have to configure policy or edit block all traffic policy.so

On fmc gui> policies> access control> edit block all traffic policy> rules> add rule> then add and save.
Yo have created the above policy in fmc, so now you have to deploy this policy in ngips thru fmc> deploy
(on the right upside conner)> select ngips> deploy. *now you will be able to ping from inside router to
asa. You can ping from inside router to asa but not from asa to inside router. You have to create
separate policy for that.

On fmc gui> policies> access control> edit block all traffic policy> rules> add rule>
Name: asa_to_in
Network tab: add available networks:

Then add appropriate source and destination network on the same tab. >add>save
Adding signature database inside packet filtering rules:

By default, the traffic passing thru sensing interfaces of ngips is not matched with signature database,
we have to enable it. Content filtering is not happening. So if there is something malicious in the data
section of packet, it is not checked by the firewall. The NGIPS is just doing packet filtering based on the
policies we created above. To activitace signature database:

On fmc gui> policies> access control>intrusion> create policy>

You cannot activate all the signatures at a time, so cisco gives base policy, in which some signatures are
activated based on the rules you selected

Select balanced security and connectivity and then select create and edit policy> to see what inside
balanced security and connectivity policy>
Now you have to import this intrusion prevention policy inside block all traffic policy
Go to fmc gui> policies> access control> access control> edit block all traffic> select policy inside to
outside> edit> inspection tab> select the intrusion policy we have created above>>>save

Creating file policy and integrating it with the block all traffic rules:

If we don’t want any work file to go from inside to outside of my company.

Fmc gui> policies> access control> malware and file> new file policy> Name: file_malware> save
Add rule under file_malware policy> >>> save.
To integrate it with block all traffic policy> policies>access control> select rule> edit> inspection tab> file
policy> select the file policy you created>>>>save

When you integrate signature policy and file policy inside block all traffic rule. It highlights the type of
policy you have integrated with it:
EIGRP:

Create a topology as we created before.

Deploying windows pc on outside: ping from test pc to asa outside interface.
Test the connectivity from admin pc to fmc and ngips using ping.

TASK1: configure eigrp on r1 and ASA. On NGIPS we applied block all traffic as a base policy. Remove the
rule which is inside block all traffic. We only want to allow eigrp traffic in order to form eigrp
neighborship.

From admin pc take gui access of fmc.

EIGRP configuration:

Configure on R1 also.
We are able to form neighbor ship due to previous rule inside block all traffic. So login to fmc and delete
the previous rules, we have to create specific rules inside block all traffic to allow only eigrp.

Go to policies: access control> access control and delete both rules. Now you will only have an implicit
deny inside block all traffic base policy. The eigrp neighborship will be down after deleting the rules.

We wont be able to create rules without a base policy. With a base policy intrusion prevention, it allows
all the traffic from inside to outside, and outside to inside. In intrusion prevention we have implicit apply
and in block all traffic policy we have implicit deny. Over the implicit deny or implicit allow, we have to
create rules in order to allow or deny traffic.

We wont be able to ping from r1 to asa or asa to r1 due to block all base policy. To allow traffic between
zones we have to create allow rule inside block all traffic policy.

To allow eigrp traffic:

We have to allow the traffic between R1 and asa, so from r1 internal to asa external, and vice-versa.
Do s hip route in asa and r1, there will be no eigrp routes.

On ngips we have to create objects fro asa, r1 and eigrp multicast

On fmc: objects> add network> save
To create rule inside block all traffic:
From R1 to multicast: source: r1 destination: multicast
From ASA to multicast: source: asa destination: multicast. Edit same rule above:
On the zone section: the source zone: external and destination zone: internal.

We need a unicast communication between r1 to asa and asa to r1, to form neighborship: edit the same
rule above.
Enable ports:
Select eigrp 88 on selected destination> add> save

Save and deploy the above rule.

Now on R1 and ASA:

On r1:

On ASA: sh route
VPN: SSL Clientless with NGIPS:

Test pc wants to get an access of ssl gateway, and want to get web access of R1. We need to create a
rule in

The test pc will send a request with sip: 192.1.20.5 and dip: 192.1.20.10. when the packet reaches
outside int we get a portal page which ask for username and password. After entering correct username
and password, the next page contains link of server. After clicking on a link, we get web access of the
server (R1). After this, the sip: 10.11.11.10 and dip:10.11.11.1. the asa works as a proxy.

In reply, the sip: 10.11.11.1 and dip: 10.11.11.10, goes from r1 to asa. Asa will find that it is a reply
packet and changes sip:192.1.20.10 and dip:192.1.20.5.

Making asa as a ssl gateway for ssl clientless deployment:

Take gui access of asa from admin pc: open cisco asdm: ip addr: 150.1.7.25

Wizard> vpn> ssl clientless:

Bookmark name: server1 > manage>
From test pc:
On the next page: http://10.11.11.1
Username: admin password cisco, but you wont get access to the server because ngips blocking traffic
between asa to r1.

So from fmc you have to add a rule in ngips inside block all traffic:
Name: clientless
Zone: source zone: external; destination zone: internal.
Network: source ip: asa internal int ip add and destn ip: r1 int ip address>>>>>>save>deploy.

If the http is running on 8080 on R1:

On r1: http server 8080
Edit the above rule:
Add the above object port in the destination ports.

From tect pc: http://10.11.11.1:8080

NGIPS On FTD

configuring Ngips on ftd

ftd is a combination of 3 different functions, it has ASA functionatility, ngips and amp. It is one of the
firewall, next generation.

Topology:

Task: From indise to outside, the ftd should do content filtering and packet filtering. We have to
configure signatures for content filtering. We have to define policy and on top of that policy we have to
apply ngips policy for content filtering.

FTD: revert it back to fresh_maching

We need:

FTD settings:
On FTD:
Username:admin
Password: Admin123
New password: Cisc0123
On Admin
pc: ping 150.1.7.10(ftd) and fmc
Take a gui access of fmc: username: admin pass: Cisc0123

Integrate ftd with fmc:

On ftd:

On fmc: devices: device management> add

Configure ip address on ftd via fmc:

Policies: block all traffic> add rule> inside to outside

Create nat rule using outside interface on ftd via fmc.

On ftd: apply ngips rule on top of rule inside_outside

Policy>access control>intrusion> create policy>

Create and edit>

The changes we made does not effect the base policy i.e the balanced security and connectivity policy >
commit changes

Policies> access control policy> edit the rule> inspection> intrusion policy> IPS_policy

SAVE>>>>

The intrusion policy icon get highlighted> deploy> apply