Installing NTOP NG on CentOS 6.4

With my linux router in place between my cable modem and safe@office, I'm ready to start playing around with some network IDS/IPS/visualization tools.  The first one I want to play around with is ntop.

For the most part, I followed this link. 

NTOP has created a couple of YUM repos that store most of the binaries/etc you will need to run ntop on CentOS.  This makes it pretty easy to install.

Here is what my ntopng config looks like:

-G=/var/tmp/ntopng.gid
-i eth1
--data-dir /var/ntop
--local-networks 192.168.10.0/24,192.168.12.0/24,192.168.252.0/24

In my case, my inside interface is eth1.  Cable can be quite noisy, so I rather monitor the inside interface then the outside one.  Local networks just tells ntop what to consider local, and what not to.  Make sure the data-dir is writable by the user that ntop switches to after startup (usually nobody).

Other than that, have fun looking at the flows.  I've noticed that ntop is only taking up about 30mb of ram.  Nice!

Centos 6.3 and static routes

I recently added a centos box inline between my cable modem and my checkpoint safe@office.  One of the things that I want to be able to do is run ntop.  Unfortunately, my safe@office was setup to NAT my wireless and wired connections behind it.  According to ntop, all I had was one host.

Disabling natting on the safe@office is easy, except, but default wireless clients and wired clients connect up on different subnets.  I could probably disable DHCP on the safe@office and have everything run via the centos box...but that is a project for another day.  For right now, I need to configure some static routes so that my centos box will properly relay traffic.

Standard route commands work, and are a great way for getting a configuration up and running.

For example:

ip route add 192.168.111.0/24 via 192.168.11.2 dev eth1

In the above example, I am adding a route for the 192.168.111.0/24 network and instructing all traffic to be sent to 192.168.11.2 via eth1.  Pretty sweet.  The problem is that adding routes like this does not persist the configuration after reboot.

I tried to edit the appropriate files as found in this doc, but I found that the configuration did not persist.  I may have messed up somewhere, but I didn't get that method to work.

I decided to go dirty and add the commands directly to rc.local.

CCSK Study: Domain 9 - Incident Response

Notes

• Self-Service nature of cloud may make CSPs unwilling to corporate to the extent required during an IR
• Dynamic pooling may complicate the IR process when it comes to things like forensics
• Resource pooling may cause privacy issues (for other cloud tenants)
• Technical challenge that should be addressed primarily by the provider
• Data may cross jurisdictional boundaries which can complicate the IR process
• Tasks may be prescribed by legislation
• Tasks may be prohibited by legislation
• Need legal staff on the IR team
• Eradication and recovery steps may be sped up due to the nature of how systems are provisioned in the cloud
• Some investigations can be sped up
• VMs can be moved to local resources for analysis
• VMs can be paused to preserve memory
• Different cloud architectures pose different problems to IR teams/process
• Consider the visibility and control a customer has in each cloud scenario (IaaS,PaaS,SaaS)
• Even in IaaS there are various aspects of the infrastructure that the customer does not control
• How do you get logs/data from those sources
• IR LifeCycle (NIST Version)
• Preparation
• Most important phase (regardless of cloud or not, really)
• Make sure both the physical and logical data flows are mapped out
• Establish SLA with CSP
• points of contact
• and HOW to contact (out-of-band, etc)
• incident definitions and criteria
• CSPs support (available event data, notifications, etc)
• definitions of roles and responsibilities
• IR Testing (if allowed)
• Scope of post-mortem activities
• Agree on format of data exchange
• IODEF
• RID
• Detection and Analysis
• timely detection depends on availability of the data and the ability to correctly interpret that data
• data may come from non-transparent, provider-owned infrastructure
• Key point:  Customers must make sure they have access to the relevant data
• What information should be logged
• How are the logs stored (tamper-proof) and proven that they are consistent and complete?
• Logs should take into account the dynamic nature of the logged information
• Is the time on the servers correct?
• Are you getting logs from all components and can you put that together properly?
•  Log retention settings?
• What log format is being used?
• CSS quoted but has since been abandoned
• SLA should require CSP to provide notification of any breach detection of provider-hosted infrastructure / services
• Forensic capabilities
• Still an area under research (especially for SaaS and PaaS)
• Customers should try and pick vendors that have forensic capabilities built in
• Containment, Eradication, Recovery
• Depending on deployment scenario, some tasks (such as eradication, recovery) can be made easy
• IaaS: shutdown node, restore from snapshot, etc
• SLA should include a "lessons learned" activity after the recovery
• Recommendations
• A clear understanding of how a CSP defines events vs incidents
• CSP and customer should agree on communication channels
• Customers must understand a CSPs role/support for IR
• IaaS customers should leverage virtualization offers for forensic analysis and IR
• CSP should be included in the design phase for an IR
• Requirements
• eIRP should include the approach for detecting and handling incidents involving a CSP
• SLA must guarantee support for incident handling
• Yearly testing

Summary

I think this domain touches on some key points.  Although, as a customer, you want to utilize a CSPs resources, you must understand what impact that will have in your ability to respond to a breach.  One interesting situation would involve the policy to "disclose" that a breach has occurred.  A customer and CSP may disagree on the best way to handle this and this could cause an embarrassment for one party.  This domain stresses that the SLA should be well defined and discussed, and I think is an important step that is missed during most conversations.

Capturing data from sources in the cloud can pose another problem.  One must consider the costs of first collecting the data (processing, storage, memory) and then the cost of transmitting that data to the corporate office for analysis.  What if you are also doing Security-as-a-Service?  The more abstract you get (PaaS, SaaS) will make this task even more difficult as now you are relying on the logs the provider has given you access to.

As stated in the domain, the technical solutions to the technical problems are still up in the air.  A balance needs to be found in the cost for any given solution and the benefit received from that.