One year ago, we announced our new vision. That is, we believe that SecOps and NetOps provide value for each other, and that value should be accessible from a single place. In pursuit of that vision, today we are releasing our biggest update ever for Plixer Scrutinizer, as well as two brand-new products.Read more
2019 marks Plixer’s 20th year providing network analytics solutions to IT teams all over the world. From the beginning, we have strived (and continue to strive) to listen closely to your needs—the needs of the professionals who keep their organizations safe and who enable their colleagues to do their best work.Read more
According to a recent New York Times’ article, there have been cyberattacks on critical infrastructure Saudia Arabia recently. While these attacks were not elaborated on in full detail (at least not in the article), it is important to understand the importance of protecting critical infrastructure from such attacks. In this article, I’d like to help you understand what critical infrastructure is, how it’s being targeted, and how you we can protect critical infrastructure from future attacks.
Correlating NetFlow with RADIUS Usernames to improve context security awareness is something we have done for several vendors including Cisco ISE, Microsoft Network Policy Server, Forescouts CounterACT and others. Even with all of these supported, we still get approached with yet another RADIUS system that the customer wants us to pull usernames from and of course they want them correlated with the IP addresses found in the NetFlow and IPFIX we collect.
The good news is that we can do it. The other good news is that it’s relatively easy to do but, it does require some work. The caveat is that it will have to be assessed on a case by case basis. Most of the time, free solutions like FreeRADIUS and OpenRADIUS and commercial solutions like Cisco Prime will log the data to a file which is a big help.
In the logs we have reviewed, we’ve noticed that most are in a unique format. Some are one line in quoted CSV, others are multiple lines. And others like Cisco Prime don’t have all the details we need unless the log is set to trace mode. The kind of log we prefer to work with is called the “accounting log”. Which needs the following data in order for us to add username support more broadly:
- The client’s IP Address, FRAMED-IP-ADDRESS: Typically, the IP address of the dial-in host is not communicated to the RADIUS server until after successful user authentication. Communicating the device IP address to the server in the RADIUS access request allows other applications to take advantage of that information.
- User-Name: This is the username making the request regardless of whether the authentication is pass or fail. If we want to narrow it down, we could only export a flow if authentication passes via the Account-Response event which should be in the log.
- The Log must contain both the request and response requests
How it will Work
We use software that provides a modified tail mode which will watch an accounting log. It provides the intelligence to understand variations in the log format (E.g. single vs. multiline). It then extracts the data out. This process has to be done on a case by case basis in order to add support for a customer’s unique RADIUS solution.
Questions we get Asked
Q: Can Scrutinizer integrate with our RADIUS server?
A: Most likely. Can we have a copy of your RADIUS accounting log?
Q: Can Scrutinizer support the syslogs our RADIUS server can send?
A: Most likely. Can we get a sample of these syslogs?
Q: Our solutions sends data as Microsoft eventlogs. Can Scrutinizer support it?
A: Yes, our current release recognizes those eventlogs.
If you don’t need all of the technical detail, the bottom line is if you are ready to start correlating NetFlow with RADIUS usernames, we can help. Reach out to our team and be ready to share some sample data if we are being asked to support something we haven’t seen before.
It’s pretty safe to say that most users are well aware that companies like Google, Facebook, LinkedIn and hundreds of others are harvesting data out of their customer’s end user devices. What many aren’t aware of is that you don’t even need to be visiting their web sites or actively using their services for them to be constantly streaming data from your Internet connected device. Read more
If your company has a couple of SIEMS or maybe more than one NetFlow collector, you could probably benefit from a UDP Packet Forwarding system. Here’s the reason: many syslog and flow exporting devices can only export to one or two devices but, when you have hundreds of exporters that need to be updated to send to a second device, it can be a tedious error prone process even with automated scripts. Not to mention, some hardware can only send syslogs or flows to one location.
A UDP packet forward appliance sits in front of a SIEM or the legacy flow collector. In some cases, it assumes the IP address of the SIEM or flow collector and the SIEM is given a new IP address. When the appliance acting as the UDP forwarder receives the syslog and flow packets it will forward them on by modifying the destination IP address but, leaving the source IP address unchanged. This means the SIEM and legacy flow collector believe they are receiving the UDP packets directly from the source. A UDP forwarder can also multiply the UDP datagrams and forward a single UDP stream to multiple destinations as explained in the video below.
A UDP forwarding appliance provides several benefits when it is placed locally to the SIEM and flow collection systems.
- Reduces the amount of traffic on the network, especially over the WAN
- Reduces the load on routers and switches as they only have to send UDP messages to one location
- Lessens the configuration work load when hundreds or thousands of routers suddenly need to send NetFlow, sFlow, IPFIX or syslogs to a different IP address
- Eases the burden trying to reconfigure hardware from different vendors and helps reduce the likelihood of mistakes
- Provides management station redundancy by sending logs to multiple destinations simultaneously
- Allows both network and security administrators to receive the same log messages while maintaining separate systems.
There are several solutions on the market that act as a UDP director for forwarding UDP packets.
However, the best commercial solutions provide the following additional features:
- Detect when the destination hosts are offline and stop forwarding traffic
- Maintain counters that allow admins to identify top UDP datagram producers
- Allow the configuration of policies that will except UDP from entire subnets and send them to the correct destinations
- Provide fault tolerance and redundancy in case of a failure
If you need to duplicate udp datagrams try the flow replicator. It is ideal for UDP Packet Forwarding.
Despite continued improvements in malware prevention, the success rate of infections still out paces the industries best detection methods. This is true even though signature matching picks up on many types of viruses however, it seems the nastiest contagions still penetrate our defenses. What is long overdue is the practice of better behavior monitoring and today i want to focus on user authentication monitoring.
One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the flow of our network traffic. This is a huge improvement over the traditional method of parsing row after row of big data in a structured table format. As the IoT becomes a reality and traffic volume continues to grow at a consistent rate, we need a way of visualizing this traffic. While we’re provided many graph types that help to convey information through colors, size or position, Plixer is excited to announce the inclusion of its latest graph type, the Sankey Flow Graph!
Our malware detection team plays particularly close attention to DNS traffic because a lot of serious exfiltration occurs as the result of DNS abuse. Since most traffic to the DNS can’t be blocked without potentially crippling Internet activity, we watch for behaviors that are outside the pattern of normal activities.
Until the introduction of flow technologies like NetFlow and the standard called IPFIX, companies relied largely on two technologies. The first was SNMP which allowed customers to trend different performance metrics for long periods of time. Metrics included interface utilization, interface errors, CPU, memory and much more. The problem with SNMP however, is that it couldn’t provide details on who and what was causing the traffic, making it nearly useless for isolating network performance problems and investigating security issues. An extension to SNMP called RMON was incorporated into SNMP but, it failed for several reasons.