color support, pcre and pf_ring issues

Mon Oct 22 17:58:34 EDT 2012

Hey Elof,
OK, so the fact that you already have an address colormap that is different from
what I've got now, indicates that we'll need to provide a configuration that will
accomodate the ability for you to configure ratop() to support your map.

OK, so to make this happen, I'm proposing that we have 16 colors that you can
use as " always " available, and where possible, you can specify the hex values
for what you want the colors to be.  

I'd like to use something like Ethan Schoonover's Solarized color maps.
This works because it has mappings to other 8 color schemes, but anything
with this level of discussion works fine for me.

   http://ethanschoonover.com/solarized

So, can we agree to support 8 accent colors:

   YELLOW, ORANGE, RED, MAGENTA, VIOLET, BLUE, CYAN and GREEN

and 8 monotone colors, to be used as background, foreground, and content tones:

   BLACK, CHARCHOL, DARK_GREY, BLUE_GREY, GREY, LIGHT_GREY,  BEIGE, WHITE

these are my suggestions, any other suggestions are welcome.

Using these standard color names, we can support an address configuration file that looks like:

#
#  Internet Address Classifications
#

0.0.0.0/8-192.167.255.255/32    Internet  ORANGE
192.168.3.0/24-223.0.0.0/8      Internet  ORANGE

#
#  Multicast Address Classifications
#

224.0.0.0-232.255.255.255       Multicast  BLUE_GREY
255.255.255.255                 Broadcast  DARK_GREY

#   
#  Local Address Classifications
#   

192.168.0.0/16    QoSient             GREEN
192.168.0.0/24    Wired               BLUE
192.168.0.67      SMTP                BLUE
192.168.1.0/24    Switzerland         BLUE
192.168.2.0/24    Wireless            BLUE
207.237.36.98     Public QoSient.com  CYAN

So, with this, we aren't supporting a standard semantic for remote, local, me, they,
but you can set the color to the ranges, and you can say what the semantics really
are??

Got to think about  the " auto " mode, but its on the feature list.

Carter

On Oct 22, 2012, at 11:45 AM, elof2 at sentor.se wrote:

> 
>> To turn color on, there is a new .rarc variable, and it takes yes and no for an answer.
>>  RA_COLOR_SUPPORT="yes"
> 
> I would request an "auto" mode for RA_COLOR_SUPPORT, so ra* commands run via cron etc will yield plain text while ra* commands run in an interactive tty yield color output.
> 
>> Some sites, based on observation domain, would probably want to use L2 ethernet addresses,
>> or source MPLS or VLAN tags to say what is local.  And I suspect some would like to have
>> an extensive list of CIDR addresses, and want to put a " color to use " in the configuration.
> 
> Yes, extensive list of CIDR addresses + a " color to use " in the configuration would be great.
> 
>> I suspect that coloring the network part, and the host part of an address different colors would
>> be interesting… but not sure if that is useful.
> 
> Nah, I don't see a scenario where this kind of coloring would be needed.
> 
>> So, if there are opinions on color, and how to use it, I'd love to hear about it before
>> I release the color version of ratop().
> 
> Personally I've been using color like this:
> * light green = IP belong to the customer and is site-local to the argus sensor (or in some times local to the person creating the report).
> 
> * green = IP belong to the customer but is remote, like a server at a remote office
> 
> * red = IP does not belong to the customer, i.e. it is external.
> 
> * purple = IP should be treated as if it were external, like the inside of a NAT:ing loadbalancer.
> 
> * cyan = excluded IP
> 
> 
> 
> Examples:
> My customer has two offices and one DC.
> 10.10.0.0/16 = Office A
> 10.20.0.0/16 = Office B
> 172.16.0.0/24 = Private DMZ at DC
> 111.111.111.0/24 = Public DMZ at DC
> 
> A GET-request to the internet from a client at Office A:
> The argus sensor is listening to traffic at Office A.
> 10.10.0.50 -> 123.123.123.123 80
> light green       red
> 
> 
> A GET-request to a server at DC, from a client at Office A:
> The argus sensor is listening to traffic at Office A.
> I haven't bothered with coloring public and private customer IPs differently.
> 10.10.0.50 -> 111.111.111.10 80   or
> light green      green
> 10.10.0.50 -> 172.16.0.10 80
> light green      green
> 
> 
> A GET-request to a server at DC, from a client on the internet:
> The argus sensor is listening to traffic at DC.
> 123.123.123.123 -> 111.111.111.10 80
>     red               green
> 
> 
> An incoming GET-request from the internet to a web-server on the private DMZ has its src IP source-NATed by the lb like this:
> Original packet: 123.123.123.123 -> 111.111.111.10 80
> After the lb:    172.16.0.1 -> 172.16.0.10 80
> 
> The argus sensor is listening to traffic at DC (inside the lb).
> 172.16.0.1 -> 172.16.0.10 80
>  purple      light green
> Even though this traffic physically come from 172.16 and go to 172.16, i.e. from and to the customer, external configuration stating that 172.16.0.1 should be treated as if it was an external host colors this flow as purple -> light green instead of light green -> light green.
> 
> 
> A customer network technician login to my customer portal. In his account profile it says he belongs to Office B. When he looks at the reports, IPs local to him (i.e. Office B) is shown in light green while Office A and DC IPs are colored in normal green.
> 
> 
> Cyan should normally not be seen, but in some cases the customer SPAN is forced to include some garbage that you really don't want to see (and that you won't filter out via bpf). I simply color this in cyan to distinguish this traffic from the green and red sides.
> 
> 
> So everything that has to do with the customer traffic use different shades of green and everything that has to do with the evil Internet use red shades throughout all reporting systems.
> 
> 
> 
> That's how I roll... :-)
> 
> /Elof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121022/1ed0541d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121022/1ed0541d/attachment.bin>