Traffic Profiling

twebster at blackhillscorp.com twebster at blackhillscorp.com
Fri Feb 2 12:51:39 EST 2007


"Philipp E. Letschert" <phil at uni-koblenz.de> wrote on 02/02/2007 05:06:24 
AM:

> On Thu, Feb 01, 2007 at 11:29:15AM -0700, twebster at blackhillscorp.com 
wrote:
> > I am currently in the process of an internal firewall implementation. 
I 
> > will be implementing firewalls on all of our internal server networks. 
 I 
> > find the most difficult part of this project is simple "data 
management". 
> > How do I easily create server/port documentation so that I can 
correctly 
> > write firewall rules for each and every server.   I need to know 
> > source/destination ip address and destination port/protocol for every 
> > server.  Since we do not currently have one central repository 
documenting 
> > every server, I am going to need to perform network reconnaissance and 

> > traffic analysis on each network.
> > 
> > To begin this process, I intend to use our current Argus archive to 
> > profile traffic to/from our server network.  I need to develop a 
method to 
> > query Argus for each individual IP address that is currently in use 
and 
> > document the port/protocol utilization for each address. 
> > 
> > Now, we are using Argus 3.0 and I have written several useful queries 
that 
> > give me the information I need, e.g. saddr, daddr, dport, bytes.  The 
> > problem I face, is how do I make this "easier".  Do I need to script 
and 
> > automate some of these queries?  Should I export this data into a 
database 
> > for other types of queries? 
> 
> You will need some additional scripting to generate a helpful result on 
the
> port and destination usage of individual addresses. A database might
> be helpful,
> but is not neccessarily needed.
> 
> > 1.  Knowing that others have used Argus to profile networks, what 
methods 
> > work?  Did you develop any scripts to automate the process?
> 
> I guess most users have developed some scripts for working with their 
data,
> but these are most-likely for very specific purposes. I'm afraid you 
have to
> create on your own. But this is an interesting topic for me, 
unfortunately
> I dont have a ready to use script yet...


I have had little luck searching and browsing the internet for my specific 
needs, I believe you are correct, most people are creating their own 
solution.  I find this an interesting topic as well and have always been 
curious how "large" data centers and such are able to document their 
systems and more importantly, keep the documents current.


> 
> > 2.  Are there current methods for importing Argus results into a 
database? 
> 
> None, that I know of, I'm thinking on database support for the ArgusEye 
GUI,
> but this is somewhere in the future...
> 
> > 3. Also, is xml an option, does raxml still exist for Argus 3.
> 
> XML is not very useful for large data sets, this is probably the reason
> why raxml dropped from 3.x?


My knowledge of XML is limited, I just thought it might be an option for 
easy import into a database.  Thanks for the update.

> 
> > 4.  Any additional suggestions how to go about managing the 
documentation 
> > and organization of this data?
> 
> One important suggestion:
> 
> Automatically generating firewall rules from existing traffic is always 
a
> *bad* idea. If your purpose is getting things working, just set your 
rules
> on allow all. If your purpose is security there is no other way, as 
evaluating
> each host (or maybe ranges of hosts with same usage e.g. workstations)
> manually. From the recorded traffic you can then check if your ruleswork 
(e.g.
> no traffic occurs that is not allowed) but not the other way round.
> 
> But of course an automatically generated list can help you in evaluating
> if and *why* certain traffic is needed for a specific host.


Yes, automatically generated firewall rules would be a disaster but my 
plan was to use network profiling via Argus, NMAP, and TCPDump to create 
all of the allow rules with an explicit permit and then watch ACL counters 
and custom captures to validate any ips/ports that have been missed. Then, 
when the explicit permit is no longer being hit, change it to deny. 

For other people interested, I have found the following SANS document 
quite useful: Firewall Analysis and Operation Modes available in the SANS 
Reading Room 

http://www.sans.org/reading_room/whitepapers/firewalls/1659.php?portal=5cda226dee2c95bcf238fc6f4266c67a


> 
> 
> Regards, Philipp

thanks for the input,
tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20070202/6424cad0/attachment.html>


More information about the argus mailing list