CloudShark capture profiles are one of the most powerful ways to tailor your analysis view, significantly decreasing the time it takes to solve problems. Your column choices, decode rules, and decryption settings all apply towards making your job easier. In CloudShark 3.7, the new profile manager not only lets you fine-tune your own work, but revolutionizes how your team works with captures - building a curated base of expert profiles that evolves over time and helping all of your analysts and engineers.
Join Tom for a special webinar highlighting profile management in CloudShark.
In order to ensure networks are efficient, we need to monitor all traffic flowing through the wire. There are many tools to help, but they all rely on being able to read and decode network traffic. When the network traffic is encrypted, these tools provide limited value.
With the nGenius Decryption Appliance (nDA), you get full visibility into all of the traffic across your network, and the ability to send that traffic to just the tools that need to see it.
Join this NDP-TV podcast to learn what a visibility architecture and packet broker are and how they can help you optimize network data capture and analysis.
Summary:
Network visibility is an often overlooked but critically important activity for IT.
Visibility is what enables you to quickly isolate security threats and resolve performance issues; ultimately ensuring the best possible end-user experience.
A proper visibility architecture addresses the strategic end-to-end monitoring goals of the network, whether they are physical, virtual, out-of-band, or inline security visibility.
Join this podcast to learn what a visibility architecture and packet broker are and how they can help you optimize network data capture and analysis.
Here is the online video
Key Points:
A Visibility Architecture is an end-to-end infrastructure which enables physical and virtual network, application, and security visibility
The basis of a visibility architecture starts with creating a plan. Instead of just adding components as you need them at sporadic intervals (i.e. crisis points), step back and take a larger view of where you are and what you want to achieve.
A visibility architecture typically yields immediate benefits such as the following: eliminating blind spots, reducing costs while maximizing ROI, and simplifying data control
There are four keys areas of a visibility architecture:
Proper access to the data you need using taps, virtual taps, and bypass switches
Filtering capability to maximize the flow of relevant information to your monitoring tools. NPBs are enable: data aggregation, filtering, deduplication, and load balancing of Layer 2 through 4 (of the OSI model) packet data.
Application intelligence functionality allows additional filtering and analysis at the application layer, i.e. Layer 7 of the OSI stack. These capabilities give you quick access to information about your network and help to maximize the efficiency of your tools.
The final layer is made up of your security and monitoring tools. These devices are typically special purpose tools (e.g. IPS, firewall, sniffer, APM, etc.) that are designed to analyze specific data. The output from these tools is typically used by network engineers to make their decisions
Follow-up Information:
Download the whitepaper Best Practices for Network Monitoring from the Resources page on www.ixiacom.com
Download the ebook the ABCs of Network Visibility from the Resources page on www.ixiacom.com
Download the ebook the ABCs of Network Visibility – Vol. 2 from the Resources page on www.ixiacom.com
Download the ebook The Definitive Guide to Visibility Use Cases from the Resources page on www.ixiacom.com
Download the whitepaper on deduplication best practices from the Resources page on www.ixiacom.com
Author - Keith Bromley - is a senior product management and marketing professional at Ixia, a Keysight business, with over 25 years of high tech software and hardware experience. In his role, he is responsible for thought leadership, product management and marketing activities for network monitoring, network security, VoIP and unified communications (UC) for enterprise and carrier solutions. Keith is a E.E. and a dedicated technologist. Keith has many articles on www.NetworkDataPedia.com
When you consider the dreadful truth about food poisoning, you would expect a government-mandate for labeling the stuff we eat. There isn’t one. The FDA does require that baby formula have a “Use by…” date, but once you’re off the bottle, you’re on your own.
The lack of a legal requirement hasn’t kept food manufacturers from dating their products, but the systems they use, and the motives behind them, have only created confusion. If I purchase a can of tuna the day before the “Sell By” date, is it safe to eat for another day, or another month? “Best If Used By” feels like a suggestion related to quality, while “Use By” sounds like an imperative with dire and yet ambiguous consequences. Some of us fear health dangers lurk if we don’t adhere strictly to these dates. Others suspect that dates are a ploy by manufacturers to get us to feed their bottom line instead of ourselves. The FDA has only one thing to say about this – “use common sense” – which unfortunately isn’t all that common.
There is more to food than just avoiding sickness and everyone benefits when food items are consumed at their peak of flavor and nutrition. Retailers will customarily discard products by whatever date is on them, effectively putting the burden on the consumer. Those of us who throw things out once they pass that printed date might feel smugly safe from sickness, but how do you know the yogurt that doesn’t “expire” until next week didn’t sit on a loading dock at 110 deg for 5 hours before arriving at your local market?
Note: I just tested, and this still works in windows 11
I always encourage technical staff to get comfortable at the command line. This is for a lot of reasons:
More efficient than a gui
Learn about the device operation
Many times you can get information not available in the gui
A lot faster when working remotely over slow links
You can script common tasks
A great example is when teaching Wireshark, I spend time on tshark/dumpcap at the command line.
In this article I will spend some time on Microsoft’s netsh that I use regularly to modify my IPv4 settings. The reason is quite simple, if I have to make the same change multiple times, it is far more efficient to do it at the command line or in a batch file rather than navigate through 4 or 5 menus/screens.
Referencing the examples provided in the video, you can easily create a batch file that will accept input instead of statically assigning values.
Here is a summary of the commands in the video:
Display usage options and syntax
netsh /?
List of adapters
netsh interface ipv4 show interfaces
netsh interface ipv4 show config
netsh interface ipv4 show address
Show IPV4 global info
netsh interface ipv4 show global
To disable my Ethernet adapter labeled Killer
netsh int set int name=“Killer" admin=disabled
To enable my Ethernet adapter labeled Killer
netsh int set int name=“Killer" admin=enabled
Display TCP or UDP connections
netsh interface ipv4 show tcpconnections
netsh interface ipv4 show udpconnections
Set a static IP Address (10.44.10.22), Subnet Mask (255.255.255.0) and Gateway (10.44.10.1) on a specific interface (Killer) permanently (persistent)
Use “” around your interface name if it has spaces in it.netsh interface ipv4 set address name=Killer static 10.44.10.22 255.255.255.0 10.44.10.1 store=persistent
Set DNS Servers without a DNS check, the set dnsservers command supports only one server as argument
netsh interface ipv4 set dnsservers name=Killer source=static “8.8.8.8" primary
Set your adapter IPV4 and DSN back to DHCP
netsh interface ipv4 set address name=Killer source=dhcp
netsh interface ipv4 set dnsservers name=Killer source=dhcp
Enjoy
The integration of artificial intelligence (AI) into the operational frameworks of cybercriminals has accelerated at an unprecedented rate, creating a more dangerous and accessible threat landscape.
In this little write-up, I wanted to share my latest experience at a customer site.
As part of troubleshooting, I always suggest we ‘clean-up’ and refresh or validate their documentation. I can’t remember how many times this simple exercise resulted in actually ‘fixing’ the problem. I love watching the look of confusion in the customer’s face as they mutter, “that’s not supposed to be connected to that”, “this was supposed to be decommissioned a long time ago”, or the ever popular, “who plugged this in?”.
Label, label, who’s got the label
In this case, I noticed some switches had labels indicating the IP address of the switch. Great, a label, not a common site, and I was impressed. The odd thing about the label was that I noticed it wasn’t within their addressing range. I asked if they had a management VLAN with a different IP addressing scheme, to which the customer replied, “yes”. When I probed a bit deeper and queried if the address on the label was within the Management VLAN addressing, the answer was, No.” Of course the IP address on the label was not reachable, nor within the customer’s addressing ranges.
One of the technicians recognized the IP address and said that the IP range was the LAB subnet. It seems that the LAB technicians labeled everything when they were testing and configuring the switches, but the labels were never physically removed when the equipment was deployed to the production environment. Not a big deal if you work there, but very confusing for contractors like me.
Passwords
This one is becoming my favourite; as I worked towards cleaning up the computer room, I noticed this curled up label on the core switch and similar labels on other equipment. Can you guess what the labels were? Hold on to your socks, it was the telnet/enable password of the equipment. AND THEY WORKED!!!! When I asked the customer why they thought this was a good idea, they said this was done because the analysts kept forgetting the passwords, so it was easier to put them on a label. He added that since the computer room has restricted access, having the passwords written on the labels posed no security risk.
This next part is so crazy, its believable. I telnetted into the switch and this was the banner configuration;
The telnet and enable password was part of the switch banner configuration. Hmmmmmmmmmmmmm…. It seems this is common practice in the lab but someone forgot to remove that part of the switch configuration when it was put into production. Of course everyone thought someone else would review or clean up the configuration.
The moral of the story is to keep your eyes open and review configurations every so often.
