360-FAAR Firewall Analysis Audit Repair

Offline Periodic Security and Infrastructure management program.

It can read Checkpoint FW1 (in odumper format) configurations and Netscreen ScreenOS policies and compare them to logexports and syslogs (Cisco to come),

360-FAAR allows you to use both inclusive and exclusive CIDR filters, permitting you to filter large rulebases into smaller ones for virutalisation at the same time as removing unused connectivity.

Its internal binary processing and comprehensive default list permits comparison of the configurations across manufacturers.

The process performs object translation, rulebase reordering and simplification, rule moves and duplicate matching automatically. Allowing you to seamlessly move rules to where you need them.

The output of 360-FAAR is the firewalls native language: currently Checkpoint FW1 dbedit and Netscreen ScreenOS6 are supported.


  • Easy to Edit Menu Driven Text Interface
  • Capable of manipulating tens of thousands of rules, objects and groups
  • Handles infinitely deep groups
  • Capable of CIDR filtering connectivity in/out of policy rulebases.
  • Capable of merging rulebases.
  • Identifies existing connectivity in rulebases and policies
  • Automatically performs cleanup if a log file is provided.
  • Keeps DR connecitvity via any text or IP tag
  • Encryption rules can be added during policy moves to remove the “merge from” rules for traffic that would be encrypted by the time it reached the firewall on which the “merge to” policy is to be installed – sounds complicated but its not in practice – apropriate ike and esp rules should be added manually
  • Runs consistency checks on its own objects and rule definitions
  • Extendable via a simple elsif in the user interaction loop section.

./360-faar.pl <FW CONFIG TYPE> <log> <config> <nats> <FW CONFIG TYPE> <log> <config> <nats> <FW CONFIG TYPE> <log> <config> <nats>

CONFIG TYPES: – cisco soon!
od = logexported logs, object dumper format config, fwdoc format nat rules csv
ns = syslog format logs, screenos6 format config, nats are included in policy but not processed fuly yet, fwdoc format nats can be used though
cs = cisco asa syslog file, cisco ASA format config, – not ready yet

od = output an odumper/ofiller format config to file, and print the dbedit for the rulebase creation to screen
ns = outputs netscreen screenos6 objects and policies (requires a netscreen config or zone info)
cs = cisco asa format config – not ready yet

By default 360-FAAR accepts exactly 3 configs on the command line.
Make an empty file called “fake” and and use this as the file name, for log config and nats if you want to process less than 3 configs at once.
Log file headders in fw1 logexported logs are found automatically so many files can be cated together

Output odumper/ofiller format files and make them more readable (watchout for spaces in names) using the numberrules helper script
Edit these csv’s in Openoffice or Excell using any of the object or group definitions from the three loaded configs.
You can then use this file as a template to translate to many different firewalls using the ‘bldobjs’ mode

Downloadhttp://sourceforge.net/ |  mirror 

Read more in here : http://sourceforge.net/p/faar/

Computer Forensics Investigating Data & Image File [C|EH]

[EC Council / [C|EH] – Full Disclousure

Introduction to Data Acquisition and Duplication

This chapter focuses on data acquisition and data duplication. Data acquisition is the act of taking possession of or obtaining control of data and adding it to a collection of evidence. Data duplication is the act of making a copy of data already acquired to preserve the original evidence in pristine condition. The chapter starts by discussing how to determine the best data acquisition methods for a certain situation. It then discusses how to make sure crucial data is not lost during the acquisition process. The chapter then covers the importance of data duplication before moving on to descriptions of the tools investigators use for data acquisition and duplication.

Data Recovery Contingencies

Investigators must make contingency plans when data acquisition failure occurs. To preserve digital evidence, investigators must create a duplicate copy of the evidence files. In case the original data recovered is corrupted, investigators can make use of the second copy. Investigators can use forensic tools such as EnCase and SafeBack to obtain multiple copies. Typically, computer forensic investigators make at least bit-stream image copies of the digital evidence that is collected. Investigators have at their disposal more than one bit-streaming tool. They should use at least two of these tools to make copies of the digital evidence in case one tool doesn’t properly acquire the data. During the data recovery process, an investigator must remember not to make any changes to the digital evidence. Forensic activities must be performed only on the bit-stream copies of digital evidence to ensure that the original evidence is not altered or corrupted.

Read More & Download In Here [PDF Format]

Some content on this page was disabled on March 8, 2017 as a result of a DMCA takedown notice from Cengage Learning. You can learn more about the DMCA here: