Differentiate Traffic from physical interfaces
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.
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.
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.
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.
["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
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.
Dell Customer Communication - Confidential
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.