Argus-info Digest, Vol 42, Issue 1
Carter Bullard
carter at qosient.com
Thu Feb 5 13:29:08 EST 2009
Hey CS (et al),
Well, the concept of database support is a little of a head scratcher,
in that, what do you need to do to support databases?
Inserting, querying, making the querying faster and then deletion
is about it. So, we should have some discussion as to what we
would want the database stuff to do for us.
What I have is basically 2 programs:
rasqlinsert() - a program that can create and drop databases
and/or tables, and it can insert, update
or delete rows
rasql() - which is ra, but it reads its data from the
database.
The database schema is basically a database and tables that have
attributes that are from the set of printable fields in argus data.
You specify the attributes and whether there are keys or not, and you
can optionally specify that the complete binary argus record be
included in the database row.
You specify the key fields using racluster() syntax, "-m srcid saddr
daddr"
and you can also have ascii representations of any field from the record
exposed as an attribute in the table.
An example of the program syntax would be:
rasqlinsert -r file -P database:table -m srcid saddr daddr -s
+pkts +bytes +rec
This will read the file and create a database (if needed) and create the
table (dropping an old one if it exists) with the schema of:
srcid saddr daddr pkts bytes argusBinaryRecord
with the key 'srcid saddr daddr'.
rasqlinsert() will act as a racluster(), guaranteeing that all records
are
combined so that there is only one entry for the key, if you specify a
key, and if you don't, rasqlinsert() will simply append rows to the end
of the table, with an auto-incrementing key.
I've also made it such that if you have a database:table that you want
to update,
you add the keyword "-M nodrop" and rasqlinsert() will use the database
table as a backing store.
rasql() will attach to the database, and read all the entries in a
table,
grabbing the binary blob that is a default part of the db schema, and
prints the record, just as if it were an argus data stream.
You can use any ra() option for filtering, printing, etc....
rasql() also supports an option "-M sql='query string'".
rasql() will take the string and append it to a SQL query of
"select from 'table' where ", so you can provide you're own
selection critera for finding data in the database.
Basically that is where I am, any thoughts?
Carter
On Feb 5, 2009, at 11:03 AM, CS Lee wrote:
> hi Carter,
>
> I grab your control plane presentation from here -
>
> https://tools.netsa.cert.org/wiki/display/tt/FloCon+2009
>
> I'm definitely a user, can't guarantee to be customer unless my boss
> says yes ;]
>
> The mysql support is definitely a long wait ;]
>
> On Thu, Feb 5, 2009 at 11:51 PM, Carter Bullard <carter at qosient.com>
> wrote:
> Thanks, I don't think I gave them slides notes, .... didn't know if it
> was intelligible without some form of narrative.
>
> So I have a bunch of mysql database support for argus almost ready
> for public consumption, would you be a potential customer/user?
>
> I use it primarily to hold real-time "ratop" like state so multiple
> people/programs can work off of the data at the same time, but
> some people have had good luck using it to hold flow data and
> to keep track of say all the IP addresses they've seen since the
> beginning, in real-time.
>
> Carter
>
>
> On Feb 4, 2009, at 9:11 PM, CS Lee wrote:
>
>> hi Carter,
>>
>> Thanks. Things are all good, btw, I read your presentation in
>> Flocon2009, that's really cool stuff.
>>
>> On Thu, Feb 5, 2009 at 3:21 AM, Carter Bullard <carter at qosient.com>
>> wrote:
>> Hmmmm,
>> I have them in the development directory, here. Let me see what's
>> up.
>> If we can fix the ongoing v2 -> v3 conversion problem soon, I'll
>> release
>> another round of client programs, and it will definitely have them in
>> there.
>>
>> How are things?
>>
>> Carter
>>
>> On Feb 4, 2009, at 1:22 PM, CS Lee wrote:
>>
>>> hi carter,
>>>
>>> i can't find both rauserdata() and raservice() in argus 3.0
>>> distribution which I downloaded from
>>>
>>> ftp://qosient.com/dev/argus-3.0/
>>>
>>> Thanks!
>>>
>>>
>>> On Tue, Feb 3, 2009 at 11:46 PM, <argus-info-request at lists.andrew.cmu.edu
>>> > wrote:
>>> Send Argus-info mailing list submissions to
>>> argus-info at lists.andrew.cmu.edu
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>>> or, via email, send a message with subject or body 'help' to
>>> argus-info-request at lists.andrew.cmu.edu
>>>
>>> You can reach the person managing the list at
>>> argus-info-owner at lists.andrew.cmu.edu
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Argus-info digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. ArgusGenerateRecord: packet size type not defined
>>> (Michael Grinnell)
>>> 2. argus usage (Oguz Yarimtepe)
>>> 3. Re: argus usage (Stewart Gray)
>>> 4. Re: ArgusGenerateRecord: packet size type not defined
>>> (Peter Van Epp)
>>> 5. Re: argus usage (Peter Van Epp)
>>> 6. Re: argus usage (Oguz Yarimtepe)
>>> 7. Re: ArgusGenerateRecord: packet size type not defined
>>> (Carter Bullard)
>>> 8. argus user data buffer analysis (Carter Bullard)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Mon, 02 Feb 2009 13:39:44 -0500
>>> From: Michael Grinnell <grinnell at american.edu>
>>> Subject: [ARGUS] ArgusGenerateRecord: packet size type not defined
>>> To: argus-info <argus-info at lists.andrew.cmu.edu>
>>> Message-ID: <49873DF0.6090305 at american.edu>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> Hi,
>>>
>>> Periodically Argus dies on my test system with the error
>>> "ArgusGenerateRecord: packet size type not defined." The time
>>> between
>>> these errors varies, sometimes it's only a minute or two after argus
>>> starts, other times it can be > 15 minutes. I've tried running a
>>> simultaneous tcpdump, then running the resulting capture file
>>> through
>>> argus, but I can't replicate the error. I also don't see any
>>> glaring
>>> errors in the capture file around the time it dies. This happens
>>> with
>>> argus 3.0.0 and with argus 3.0.1 beta2. The system is running
>>> CentOS
>>> 5.2 and is listening on a dedicated interface (NC7782, bnx2
>>> driver) to a
>>> span port off of a Cisco switch. I have also updated to the
>>> newest bnx2
>>> drivers, but it still recurs. I'm trying to scare up another NIC
>>> to try
>>> as well.
>>>
>>> Thoughts?
>>>
>>> --
>>> Michael Grinnell
>>> Information Security Engineer
>>> The American University
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Mon, 02 Feb 2009 22:50:20 +0200
>>> From: Oguz Yarimtepe <comp.ogz at gmail.com>
>>> Subject: [ARGUS] argus usage
>>> To: argus-info at lists.andrew.cmu.edu
>>> Message-ID: <1233607820.7050.12.camel at gezenti>
>>> Content-Type: text/plain
>>>
>>> Hi,
>>>
>>> I want some information about argus capabilities. I tried argus a
>>> bit
>>> and read the wiki. I want to learn whether it is possible to get
>>> application level information from a flow record by using argus,
>>> like
>>> HTTP, HTTPS, IMAP, POP, SMTP, FTP ...
>>> As i understood from its usage it is possible to get these
>>> information
>>> indirectly by analyzing the argus output but maybe there is a way
>>> that
>>> argus serves that i don't know.
>>>
>>> Thanx.
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Tue, 3 Feb 2009 10:26:06 +1300
>>> From: "Stewart Gray" <Stewart.Gray at safecom.co.nz>
>>> Subject: Re: [ARGUS] argus usage
>>> To: <argus-info at lists.andrew.cmu.edu>
>>> Message-ID:
>>> <4C08B31BFF3B5D42BCAC255ADDD6EE5EA8769D at tasbe116.advancedsolutions.co.nz
>>> >
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi Oguz,
>>>
>>> Argus supports the Berkeley packet filter (as other apps like
>>> tcpdump
>>> and ngrep do) so you're able to lock queries down to port numbers,
>>> specific hosts etc. Knowing the port number an application runs on
>>> means
>>> it fairly easy to pull out transactions for a particular protocol.
>>> Keep
>>> in mind it doesn't operate at layer 7, flow information for a
>>> protocol
>>> such as HTTP will be very similar to SMTP. If you're after more in-
>>> depth
>>> analysis of a transaction, i.e. what happened during an http
>>> connection
>>> (GET, POST, HEAD etc) you're probably best to be taking full packet
>>> captures alongside argus so you can run them through another tool
>>> such
>>> as wireshark.
>>>
>>> Have a look at this wiki page for some common usages -
>>> http://nsmwiki.org/index.php?title=Argus.
>>>
>>> Cheers,
>>>
>>> Stewart
>>>
>>> -----Original Message-----
>>> From: argus-info-bounces+stewart.gray=safecom.co.nz at lists.andrew.cmu.edu
>>> [mailto:argus-info-bounces+stewart.gray=safecom.co.nz at lists.andrew.cmu.e
>>> du] On Behalf Of Oguz Yarimtepe
>>> Sent: Tuesday, 3 February 2009 9:50 a.m.
>>> To: argus-info at lists.andrew.cmu.edu
>>> Subject: [ARGUS] argus usage
>>>
>>> Hi,
>>>
>>> I want some information about argus capabilities. I tried argus a
>>> bit
>>> and read the wiki. I want to learn whether it is possible to get
>>> application level information from a flow record by using argus,
>>> like
>>> HTTP, HTTPS, IMAP, POP, SMTP, FTP ...
>>> As i understood from its usage it is possible to get these
>>> information
>>> indirectly by analyzing the argus output but maybe there is a way
>>> that
>>> argus serves that i don't know.
>>>
>>> Thanx.
>>>
>>> #####################################################################################
>>> Important: This electronic message and attachments (if any) are
>>> confidential
>>> and may be legally privileged. If you are not the intended
>>> recipient do not
>>> copy, disclose or use the contents in any way. Please let us know
>>> by return
>>> e-mail immediately and then destroy this message.
>>> #####################################################################################
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Mon, 2 Feb 2009 20:51:05 -0800
>>> From: Peter Van Epp <vanepp at sfu.ca>
>>> Subject: Re: [ARGUS] ArgusGenerateRecord: packet size type not
>>> defined
>>> To: argus-info at lists.andrew.cmu.edu
>>> Message-ID: <20090203045105.GA26496 at sfu.ca>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> On Mon, Feb 02, 2009 at 01:39:44PM -0500, Michael Grinnell wrote:
>>> > Hi,
>>> >
>>> > Periodically Argus dies on my test system with the error
>>> > "ArgusGenerateRecord: packet size type not defined." The time
>>> between
>>> > these errors varies, sometimes it's only a minute or two after
>>> argus
>>> > starts, other times it can be > 15 minutes. I've tried running a
>>> > simultaneous tcpdump, then running the resulting capture file
>>> through
>>> > argus, but I can't replicate the error. I also don't see any
>>> glaring
>>> > errors in the capture file around the time it dies. This
>>> happens with
>>> > argus 3.0.0 and with argus 3.0.1 beta2. The system is running
>>> CentOS
>>> > 5.2 and is listening on a dedicated interface (NC7782, bnx2
>>> driver) to a
>>> > span port off of a Cisco switch. I have also updated to the
>>> newest bnx2
>>> > drivers, but it still recurs. I'm trying to scare up another
>>> NIC to try
>>> > as well.
>>> >
>>> > Thoughts?
>>> >
>>> > --
>>> > Michael Grinnell
>>> > Information Security Engineer
>>> > The American University
>>>
>>> Setting
>>>
>>> ARGUS_PACKET_CAPTURE_FILE="/var/log/argus/packet.out"
>>>
>>> in an argus.rc file will capture the input packets from pcap in to
>>> the
>>> specified file. If you can get lucky and get a failure before you
>>> run out of
>>> disk space one of the last packets in the file should tell us what
>>> argus isn't
>>> liking. On a busy link this file will get large fast but if it
>>> sometimes
>>> fails quickly you may be lucky (you are also likely to see packet
>>> loss due to
>>> the disk I/O on the sensor but hopefully the fault will still
>>> occur).
>>> It looks like the argus record is malformed (it is
>>> complaining that it
>>> doesn't recognize the type in argus/ArgusModeler.c at line 2904 in
>>> the
>>> argus-3.0.1.beta.2 code). A dump of the offending packet should
>>> tell Carter
>>> why (or if the incoming packet is corrupted which is also possible).
>>>
>>> Peter Van Epp
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Mon, 2 Feb 2009 21:06:59 -0800
>>> From: Peter Van Epp <vanepp at sfu.ca>
>>> Subject: Re: [ARGUS] argus usage
>>> To: argus-info at lists.andrew.cmu.edu
>>> Message-ID: <20090203050659.GA8930 at sfu.ca>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> On Mon, Feb 02, 2009 at 10:50:20PM +0200, Oguz Yarimtepe wrote:
>>> > Hi,
>>> >
>>> > I want some information about argus capabilities. I tried argus
>>> a bit
>>> > and read the wiki. I want to learn whether it is possible to get
>>> > application level information from a flow record by using argus,
>>> like
>>> > HTTP, HTTPS, IMAP, POP, SMTP, FTP ...
>>> > As i understood from its usage it is possible to get these
>>> information
>>> > indirectly by analyzing the argus output but maybe there is a
>>> way that
>>> > argus serves that i don't know.
>>> >
>>> > Thanx.
>>> >
>>>
>>> Depends on what you need. If you enable user data capture
>>> (the -U
>>> option on the argus) it will capture up to the first 512 bytes of
>>> the user
>>> data of the flow. That may or may not give you enough information
>>> about the
>>> flow to do what you want. Note that on a fast link best results
>>> are going to
>>> occur using a DAG card as the data capture adds a fairly heavy
>>> load to the
>>> server. To display the data with ra (for instance) you need to use
>>> the -s
>>> command to add suser and duser to the output (as in
>>>
>>> ra -r argus_file -n -s +suser:512 -s +duser:512
>>>
>>> which will tack the user data on the end of the line. This of
>>> course raises a
>>> number of sticky privacy issues that you need to have considered
>>> and gotten
>>> approved by appropriate management of the link you are tapping
>>> (which may or
>>> may not be you :-)).
>>>
>>> Peter Van Epp
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Tue, 3 Feb 2009 07:59:33 +0200
>>> From: Oguz Yarimtepe <comp.ogz at gmail.com>
>>> Subject: Re: [ARGUS] argus usage
>>> To: argus-info at lists.andrew.cmu.edu
>>> Message-ID:
>>> <20831c740902022159q176610e5nb954f5d96e211d13 at mail.gmail.com>
>>> Content-Type: text/plain; charset="iso-8859-9"
>>>
>>> >
>>> > Depends on what you need. If you enable user data
>>> capture (the -U
>>> > option on the argus) it will capture up to the first 512 bytes
>>> of the user
>>> > data of the flow. That may or may not give you enough
>>> information about the
>>> > flow to do what you want. Note that on a fast link best results
>>> are going
>>> > to
>>> > occur using a DAG card as the data capture adds a fairly heavy
>>> load to the
>>> > server. To display the data with ra (for instance) you need to
>>> use the -s
>>> > command to add suser and duser to the output (as in
>>> >
>>> > ra -r argus_file -n -s +suser:512 -s +duser:512
>>> >
>>> > which will tack the user data on the end of the line. This of
>>> course raises
>>> > a
>>> > number of sticky privacy issues that you need to have considered
>>> and gotten
>>> > approved by appropriate management of the link you are tapping
>>> (which may
>>> > or
>>> > may not be you :-)).
>>> >
>>> > Peter Van Epp
>>>
>>>
>>> What i am willing to do is to characterize the network traffic by
>>> using
>>> some characteristics derived from flow information. My final
>>> decision about
>>> a flow record will be whether the flow belongs to a chat session,
>>> a mail
>>> transfer, a FTP connection, a web browsing, ...
>>>
>>> I had discovered Bro which has identifiers related with high level
>>> protocols. The protocol family that it supports is not as much as
>>> Argus does
>>> so i was planning to go on with Argus.
>>>
>>>
>>> --
>>> O?uz Yar?mtepe
>>> www.loopbacking.info
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20090203/2e9c8a9c/attachment-0001.html
>>>
>>> ------------------------------
>>>
>>> Message: 7
>>> Date: Tue, 3 Feb 2009 10:07:03 -0500
>>> From: Carter Bullard <carter at qosient.com>
>>> Subject: Re: [ARGUS] ArgusGenerateRecord: packet size type not
>>> defined
>>> To: Michael Grinnell <grinnell at american.edu>
>>> Cc: argus-info <argus-info at lists.andrew.cmu.edu>
>>> Message-ID: <D2F59B8C-3239-475E-AE5C-4DCE7C819151 at qosient.com>
>>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>>
>>> Hey Michael,
>>> Wow, pretty obvious bug in the flow's packet size reporting feature.
>>> Try this patch, and we'll see if it doesn't work for you.
>>>
>>> Carter
>>>
>>> ==== //depot/argus/argus/argus/ArgusModeler.c#62 - /home/carter/
>>> argus/
>>> argus/argus/ArgusModeler.c ====
>>> 2872c2872
>>> < if (psize->src.psizemax > 0)
>>> ---
>>> > if (psize->dst.psizemax > 0)
>>>
>>>
>>> On Feb 2, 2009, at 1:39 PM, Michael Grinnell wrote:
>>>
>>> > Hi,
>>> >
>>> > Periodically Argus dies on my test system with the error
>>> > "ArgusGenerateRecord: packet size type not defined." The time
>>> > between these errors varies, sometimes it's only a minute or two
>>> > after argus starts, other times it can be > 15 minutes. I've
>>> tried
>>> > running a simultaneous tcpdump, then running the resulting capture
>>> > file through argus, but I can't replicate the error. I also don't
>>> > see any glaring errors in the capture file around the time it
>>> dies.
>>> > This happens with argus 3.0.0 and with argus 3.0.1 beta2. The
>>> > system is running CentOS 5.2 and is listening on a dedicated
>>> > interface (NC7782, bnx2 driver) to a span port off of a Cisco
>>> > switch. I have also updated to the newest bnx2 drivers, but it
>>> > still recurs. I'm trying to scare up another NIC to try as well.
>>> >
>>> > Thoughts?
>>> >
>>> > --
>>> > Michael Grinnell
>>> > Information Security Engineer
>>> > The American University
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 8
>>> Date: Tue, 3 Feb 2009 10:46:45 -0500
>>> From: Carter Bullard <carter at qosient.com>
>>> Subject: [ARGUS] argus user data buffer analysis
>>> To: Oguz Yarimtepe <comp.ogz at gmail.com>
>>> Cc: argus-info at lists.andrew.cmu.edu
>>> Message-ID: <8FDB29B8-7B9A-401B-8466-B38557690D00 at qosient.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hey Oguz,
>>> We have undocumented programs in the argus-3.0.0 distribution
>>> that do something similar to what you are interested in, I think.
>>> These are undocumented because its a bit complex, and I haven't
>>> had a chance to describe them yet.
>>>
>>> If you are interested in helping to make these types of programs
>>> useful, I'll be more than happy to describe how they work, and
>>> share my experiences and help to make them better.
>>>
>>> The undocumented program rauserdata() will analyze the user
>>> data portion of argus records, and generate a signature pattern
>>> configuration for the protocols it encounters in the data set.
>>> The algorithm is very simple, and pretty powerful, in that it makes
>>> no assumptions about the user data. But, you have to be careful
>>> with the data that you give the engine. Below is a little
>>> background.
>>>
>>> I have found that for the set of protocols you listed, the
>>> first 32 bytes of data is all that is needed to reliably identify
>>> the
>>> protocol type. This is because, each of your protocols have
>>> unique greeting identifiers, and for the ones you listed, the
>>> identifiers are all in ascii.
>>>
>>> Because argus provides multiple status reports for long lived
>>> flows, not all argus records for a given flow will contain the
>>> "first N byte" signatures that you are seeking.
>>>
>>> Using racluster() on your 'primitive' argus data will usually
>>> provide
>>> you with the "first N bytes" of user data, so that your search for
>>> tokens and patterns can be reliable.
>>>
>>> Try this out for a while to see if you get anything useful:
>>>
>>> racluster -r /a/days/worth/of/data/of/interest/* -w /tmp/
>>> day.cache
>>>
>>> rauserdata -r /tmp/day.cache | less
>>>
>>> You should get an output that is arraigned by 'protocol/port' and
>>> you should see a set of source and destination user data buffers
>>> that have the "greatest likelyhood" patterns for that "proto/port"
>>> pair.
>>>
>>> ra() prints the user data buffer with an ASCII encoding by
>>> default, and
>>> so you should see some patterns in the buffers it outputs.
>>> if you see a '.', that is generally a non printable character.
>>>
>>> The ides is to build up configuration files of signatures using
>>> rauserdata(),
>>> and the program raservices(), will take the rauserdata() output as
>>> a configuration file, and label flows with the tags that identify
>>> the
>>> protocol.
>>>
>>> Give it a try, and I'd love to see/hear your comments.
>>>
>>> Carter
>>>
>>> On Feb 3, 2009, at 12:59 AM, Oguz Yarimtepe wrote:
>>>
>>> >
>>> >
>>> > Depends on what you need. If you enable user data capture
>>> > (the -U
>>> > option on the argus) it will capture up to the first 512 bytes of
>>> > the user
>>> > data of the flow. That may or may not give you enough information
>>> > about the
>>> > flow to do what you want. Note that on a fast link best results
>>> are
>>> > going to
>>> > occur using a DAG card as the data capture adds a fairly heavy
>>> load
>>> > to the
>>> > server. To display the data with ra (for instance) you need to use
>>> > the -s
>>> > command to add suser and duser to the output (as in
>>> >
>>> > ra -r argus_file -n -s +suser:512 -s +duser:512
>>> >
>>> > which will tack the user data on the end of the line. This of
>>> course
>>> > raises a
>>> > number of sticky privacy issues that you need to have considered
>>> and
>>> > gotten
>>> > approved by appropriate management of the link you are tapping
>>> > (which may or
>>> > may not be you :-)).
>>> >
>>> > Peter Van Epp
>>> >
>>> > What i am willing to do is to characterize the network traffic by
>>> > using some characteristics derived from flow information. My final
>>> > decision about a flow record will be whether the flow belongs to a
>>> > chat session, a mail transfer, a FTP connection, a web
>>> browsing, ...
>>> >
>>> > I had discovered Bro which has identifiers related with high level
>>> > protocols. The protocol family that it supports is not as much as
>>> > Argus does so i was planning to go on with Argus.
>>> >
>>> >
>>> > --
>>> > O?uz Yar?mtepe
>>> > www.loopbacking.info
>>>
>>> Carter Bullard
>>> CEO/President
>>> QoSient, LLC
>>> 150 E 57th Street Suite 12D
>>> New York, New York 10022
>>>
>>> +1 212 588-9133 Phone
>>> +1 212 588-9134 Fax
>>>
>>>
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20090203/3f7a6300/attachment.html
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Argus-info mailing list
>>> Argus-info at lists.andrew.cmu.edu
>>> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>>>
>>>
>>> End of Argus-info Digest, Vol 42, Issue 1
>>> *****************************************
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> CS Lee<geek00L[at]gmail.com>
>>>
>>> http://geek00l.blogspot.com
>>> http://defcraft.net
>>
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E 57th Street Suite 12D
>> New York, New York 10022
>>
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>>
>>
>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> CS Lee<geek00L[at]gmail.com>
>>
>> http://geek00l.blogspot.com
>> http://defcraft.net
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>
>
>
>
> --
> Best Regards,
>
> CS Lee<geek00L[at]gmail.com>
>
> http://geek00l.blogspot.com
> http://defcraft.net
Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090205/9e6258cb/attachment.html>
More information about the argus
mailing list