Hello all, I have retired, hopefully temporarily, from the role of maintaining the Debian argus package. As an argus user, I will remain subscribed to this list, but be advised that I no longer have a responsibility for the Debian argus package. Regards, Yotam Rubin
Hey Yotam, Thanks for all the work, and the great advice. Hope all is well, and that you have things ahead. Best Regards, Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter <at> qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com -----Original Message----- From: owner-argus-info <at> lists.andrew.cmu.edu [mailto:owner-argus-info <at> lists.andrew.cmu.edu] On Behalf Of Yotam Rubin Sent: Tuesday, October 01, 2002 1:17 PM To: argus-info <at> lists.andrew.cmu.edu Subject: The Debian argus package
On Tue, Oct 01, 2002 at 08:17:24PM +0300, Yotam Rubin wrote: > Hello all, > > I have retired, hopefully temporarily, from the role of maintaining > the Debian argus package. As an argus user, I will remain subscribed to > this list, but be advised that I no longer have a responsibility for the > Debian argus package. I'm endeavouring to undertake Debian's New Maintainer process and take over (as long as required) the maintenenance of the Debian argus package. regards Andrew
Gentle people,
I've just uploaded a new argus-clients package to the dev
directory.
ftp://ftp.qosient.com/dev/argus-2.0/argus-clients-2.0.6.beta.34.tar.gz
This should be considered a complete reworking of the argus-clients
package and has a number of very significant improvements. There
are a lot of reasons why argus-clients jumps from 2.0.2.alpha.17 to
2.0.6.beta.34, I've been working on it for quite some time, so, now
that I've been laid up on the couch after my surgery and had some
time to push it out, here it is, finally.
The new argus-clients has new programs and some key changes:
specify fields to print on the command line using "-s" option.
this supports printing out all the fields argus supports,
from bytes to tos to loss stats, jitter stats, whatever we've
got.
because of this most of all the field directives on the
command
line are gone. hopefully we can move to the style in official
release.
ranonymize - this program anonymizes argus data. it strips out
fields that are not needed, wanted, liked, and then randomizes
all the data fields, in a very controlled fashion. The
program
anonymizes the timestamps, sequence numbers, mac and IP
addresses,
port numbers. There is a detailed man page on ranonymize()'s
configuration. This is an interesting and important program
if you want to share data.
(Continue reading)Gentle people, I'd like to get some conversation going on ranonymize(). It's a very interesting tool for scrambling argus data so that the data retains enough semantics so it can still be analyzed, but anonymized enough so that the data can be shared as well. I think the goal of anonymization is to minimize discovery and traffic engineering capabilities from argus data when you share it, or even store it for long periods of time. This means that obvious identifiers, such as addresses and port numbers need to be modified, but also non-obvious values like TCP base sequence numbers, ESP spi values, and TTL's. Because the purpose of sharing argus data is generally to convey some set of semantics, like the relationship of addresses and ports that are of interest, or some aspect of time, you need some flexibility in scrambling the data. Maybe you want to demonstrate how two hosts are interacting among other traffic, so you want to translate two addresses of interest to known values and randomize the rest. Or maybe you want to preserve the concept of local vs. remote hosts, so you need to retain some aspect of the address hierarchy. Simply randomizing every 8, 16 and 32-bit objects in an argus record isn't going to be the most helpful. Ranonymize has a rich set of configuration parameters to provide anonymization with exceptions. You can tell ranonymize, "don't translate these objects", "translate this value to this value", and you tell it "use these techniques to translate these objects". These options are primarily focused on MAC and IPv4 addresses, port values, time, IP header fields, such as the ip_id, TOS and TTL, and dealing with sequence numbers in the various supported protocols.(Continue reading)
Without (yet) having looked at Carter's new tool here are some thoughts on this subject from a discussion some months ago about putting Argus up locally and being able to release the traffic traces for network researchers. Note in this case we want to keep at least destination port numbers to allow researchers to determine what kind of traffic it was and keep the time syncronization (possibly offset by a constant amount to obscure it slightly). A later look over the CAIDA web site indicates they don't have a solution either, the anomymiser they use is fairly simple and doesn't appear to address the issues raised below. A fly in the anonymous ointment. Unfortunatly I thought about the issue of anonymizing trace data on the way back to the hill. It is essentially cryptography (we want to encryt the data but not decrypt it) which is unfortunatly trivially subject to a chosen plaintext attack which will defeat the encryption (and thus the anonymity). If we postulate the following users: I (innocent victem) A (scumbag attacker) and sites AS (attacker's site) IS (innocent victem's site) P1 (porno site 1) and p2 (porno site 2) then look at the possibilities in anonymized trace data we find a problem. Assume we have anonymized both IP addresses by random translation and shifted time by a fixed amount to try and defeat traffic pattern analysis as we discussed this morning. Unfortunatly since we are on a public network, if we assume the attacker can identify the victem and determine the IP address the victem is using then our entire scheme can be defeated as follows: A pings (logging the current time on machine AS) the victem's machine IS, P1, and P2. He may need to ping in an unusual pattern to make the pattern stand out in that anonymized logfile. Now the attacker obtains the anonymized trace file for the time period described above. By sorting all the data by source and dest IP address he can pick out the ping pattern that he initiated(Continue reading)
Hey Peter, It is unclear that anonymized data must be a one-way function in all conditions in order to be useful. If, for example, all traffic in the anonymized set is local traffic, how can there be a threat to the anonymization strategy when giving data to someone outside the local net? I think there are a number of constraints that can be placed on anonymized data that can make it secure. Even cryptography works only in the presence of constraints, such as keeping the private key private. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter <at> qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com -----Original Message----- From: owner-argus-info <at> lists.andrew.cmu.edu [mailto:owner-argus-info <at> lists.andrew.cmu.edu] On Behalf Of Peter Van Epp Sent: Thursday, October 10, 2002 4:16 PM To: argus(Continue reading)
Hey Peter, I should describe how ranonymize() anonymizes IPv4 addresses so we can see what kind of problems might exist. ranonymize() provides several methods for address anonymization, I'll describe the default one to start out. IPv4 addresses are anonymized using a non-cryptographic Class based 24-bit prefix preserving sequential allocation strategy, which is not distributable. So what does this mean. All IPv4 addresses are treated as having a 24-bit netmask. Each unique 24-bit network address is translated to a reserved 24-bit netmask from the same Class, sequentially on a first come basis. So a Class A address is assigned a reserved Class A network part, a Class B address is assigned a reserved ClassB network part. These addresses are allocated sequentially, so that the first Class A address encountered in s stream will get 1.0.1, the second will get 1.0.2. Class B's start with 100.0.1, and Class C's start with 197.0.1. Multicast addresses start with 224.0.1. You can specify exceptions and specific net or complete address translations, so there is some flexibility. The 8-bit host part is allocated sequentially, starting with 1. I've included an example below. Once an address has been allocated, any occurrence of that address in any part of an argus record in the stream is translated to the new anonymized address, using a hashed lookup strategy. This approach provides a Class preserving, 24-bit prefix preserving anonymizing strategy that is pseudo-random, but not distributable.(Continue reading)
Hi, I've got a problem where on a segment that Argus is monitoring, it seems to be producing stupid results. I'm not pointing the finger at Argus, I'm suspecting the Ethernet setup at this stage, however, I need to get to the bottom of it. Is there a way that I can use tcpdump files to simulate traffic? What I'd like to try and do is capture some traffic from a few other areas on the network with tcpdump (I don't want to and can't install Argus everywhere) and then try and work out if and where I'm losing visibility of the traffic. Hope this makes sense. Andrew
On Mon, Oct 14, 2002 at 02:55:00PM +1000, Andrew Pollock wrote: > Hi, > > I've got a problem where on a segment that Argus is monitoring, it seems > to be producing stupid results. > > I'm not pointing the finger at Argus, I'm suspecting the Ethernet setup at > this stage, however, I need to get to the bottom of it. > > Is there a way that I can use tcpdump files to simulate traffic? > > What I'd like to try and do is capture some traffic from a few other areas > on the network with tcpdump (I don't want to and can't install Argus > everywhere) and then try and work out if and where I'm losing visibility > of the traffic. Helps if I read the man page *before* I ask the silly question. Andrew
RSS Feed93 | |
|---|---|
38 | |
75 | |
50 | |
113 | |
42 | |
49 | |
155 | |
63 | |
50 | |
30 | |
122 | |
22 | |
37 | |
53 | |
58 | |
91 | |
52 | |
17 | |
30 | |
15 | |
39 | |
49 | |
61 | |
66 | |
82 | |
48 | |
52 | |
27 | |
42 | |
35 | |
72 | |
78 | |
48 | |
102 | |
50 | |
23 | |
61 | |
40 | |
50 | |
26 | |
32 | |
72 | |
48 | |
55 | |
115 | |
66 | |
36 | |
92 | |
122 | |
116 | |
58 | |
26 | |
15 | |
3 | |
3 | |
24 | |
38 | |
50 | |
62 | |
6 | |
61 | |
90 | |
151 | |
121 | |
67 | |
61 | |
120 | |
107 | |
143 | |
44 | |
91 | |
68 | |
82 | |
141 | |
123 | |
69 | |
50 | |
79 | |
113 | |
114 | |
131 | |
96 | |
270 | |
4 | |
4 | |
40 | |
31 | |
24 | |
14 | |
2 | |
1 | |
8 | |
25 | |
1 | |
14 | |
5 | |
25 | |
24 | |
33 | |
12 | |
41 | |
33 | |
35 | |
48 | |
95 | |
45 | |
79 | |
87 | |
84 | |
17 | |
62 | |
14 | |
28 | |
14 | |
15 | |
38 | |
60 | |
28 | |
31 | |
48 | |
24 | |
39 | |
18 | |
29 | |
26 | |
41 | |
47 | |
18 | |
14 | |
23 | |
20 | |
92 | |
29 | |
56 | |
47 | |
33 | |
18 | |
91 | |
58 | |
49 | |
15 | |
49 | |
109 | |
52 | |
39 | |
99 | |
134 | |
123 | |
26 | |
59 | |
72 | |
143 | |
44 | |
81 | |
20 | |
12 | |
11 | |
63 | |
22 | |
8 | |
1 | |
6 | |
15 | |
3 | |
9 | |
12 | |
7 | |
16 | |
28 | |
9 |
