Differentiate Traffic from physical interfaces

[pcalamar]

I would like to know if in future releases of Netwitness, will it have the capability to differentiate traffic from different physical ethernet ports from the Netwitness application?  We would like to differentiate traffic from different ethernet ports as we will have very distinct traffic going into one common decoder and using different ethernet ports.    

[Anonymous]

Hi Paul, we'll be introducing a Next Generation Health & Wellness Beta with 11.4.  Per the attached screen capture, you'll be able to monitor throughput on individual interfaces.

[pcalamar]

Hi Michael, I like the health menu but my question is more towards having the capability in Netwitness to filter on traffic based on ethernet physical ports.  For instance, on a decoder we could have port 2 ingesting internet traffic(north/south) with  port 3 collecting inside traffic on our secure network(east/west) traffic.  Would like to be able to filter from the Netwitness application by physical port. 

Thanks,

  Paul

[JohnSnider]

Currently no, and not sure it would be possible in the future, but I'll leave that to PM to answer. However, it you specifically define your internal networks and dmz networks in the Traffic Flow Options file, you should be able to filter using the "netname" key or by using the direction key if you only want lateral traffic.

Example:

["10/8"] = "internal",

["10.1.2/24"] = "internal servers",

["10.2/16"] = "desktops",
["172.16/12"] = "private",
["192.168/16"] = "dmz",

["192.168.1/24"] = "dmz servers",

["192.168.1.55/32"] = "dmz mail server",

to look at only traffic sourced by the internal hosts, you would have a query like:    netname = 'internal src'

if you want ONLY internal lateral traffic then:   netname = 'internal src' && netname = 'internal dst' 

if you  want to see traffic from the desktops to the dmz:  netname = 'desktops src' && netname = 'dmz dst'

if you want to see ONLY inbound traffic to the DMZ servers:   netname = 'dmz dst' && direction = 'inbound'

you can create application rules on the decoder to tag this traffic into a custom key (say "custom.info") that would make the queries easier. 

so no not easily done "by interface", but if you know the network ranges for the different areas of the network, then you can filter it that way.  Note that anything that is NOT defined in the Traffic Flow Options file is considered "other" or "external", you can define down to the host with an ip and a 32 bit mask (i.e. 10.1.2.3/32), or other sections of your environment with smaller carving via netmask, always define the entire net as a catch-all, and then add more specific regions/servers if needed for clarity, note that anything not specifically defined but still in the catch-all range will just get the the generic tag you have on the top level range (so in my example if  there is a host in 10.3.0.x it would get the "internal" tag as it is not in a specific narrower range, anything in 10.2/16 would be tagged 'desktops' in the netname key.

hope that helps

[pcalamar]

Hi John, yes I am familiar with that file.  I guess we could try differentiating traffic that way.  The reason why i am a little hesitant is that we would see clients/servers on our 10 network going out to the internet and also going east/west as well.   

Thanks,

  Paul

[JohnSnider]

Dell Customer Communication - Confidential

Paul,

yes but you can differentiate that traffic by the names

netname = 'internal src' && netname = 'internal dst' would be internal lateral traffic (not outbound)

netname = 'internal src' && netname= 'other dst' would be outbound traffic from the internal network (not to dmz)

note that if you have a proxy on the internal network that is used by the internal hosts to go to the internet you need to define the IP for the proxy in the "external" part of the file (please be sure you have the latest parser and options file)

["10.1.2.3/32"] = "proxy"

for the direction keys to work right

then if you had

netname = 'internal src' && direction = 'outbound' - you would see the outbound traffic even if it's going to the proxy internally.

if something is defined in the "internal" section of the file, then traffic between those nets is "lateral" in the direction key

if something it's defined as "external" in the file, or undefined, then traffic from the defined nets TO the external/other nets is "outbound" in the direction key

reverse that, "external/other" to anything defined in the files internal section, is considered "inbound" traffic

by naming your networks appropriately you can define ANY direction/ traffic flow you want. In fact that is the way we used to do it with a feed and application rules in the old days before the parser came about.