A while ago we were hit by an amplification/reflection DDoS attack against our public-facing network. I was familiar with NTP and DNS based reflection DDoS attacks, but this one employed the Simple Service Discovery Protocol (SSDP) to flood our tubes, a name name I’ve heard before and saw in packet traces randomly, but hardly knew anything about to be honest.
SSDP is a UDP-based protocol for service discovery and UPnP functionality with an HTTP-like syntax. It’s deployed by modern operating systems and embedded systems like home routers, where it is sometimes enabled even on their external interfaces, which makes this kind of attack possible.
The Shadowserver Foundation has a nice website with lots of information and statistics of public SSDP-enabled devices: While the number of open or vulnerable DNS and NTP is going down steadily, there are currently around 14 million IPs around the world that respond to SSDP requests, and the number is only declining very slowly:
Due to this we can expect that SSDP will be abused for DDoS attacks more often in the future.
Continuing from my previous post, here’s another quick and dirty perl script I used some time ago to provide a basic analysis of Check Point firewall logfiles in terms of rule usage.
It kind of lost the the bit of usefulness it had with the rule base hit counter that was introduced in R75.40, but maybe someone can still make use of this horrible code. Or some better examples like this to begin with.
The script here also includes info on implicit rules, address spoofing, whacky ICMP packets or basically any stuff that isn’t logged with an actual rule name.
Again this script will obviously only be able to gather statistics of firewall rules you’ve actually set to logging.
Here’s a simple perl script I wrote some time ago in order to analyze Check Point firewall logs for dropped connections, outputting a simple statistic by drops per source-IP. It also displays the number of accepted connections per source-IP.
You first need to convert the Check Point binary logs to text logfiles via fwm logexport like:
fwm logexport -n -p -i $FWDIR/log/2013-07-28_000000.log -o /var/tmp/2013-07-28.txt
Always use the -n switch btw or you can grab quite a few snickers waiting for DNS reverse resolutions in large logfiles. If you’re running this directly on a check point SPLAT or Gaia node, make sure you have enough space on the destination volume since the exported text logs can be quite large (use /var/tmp instead of /tmp)
Of course this script will only be able to gather statistics of firewall rules you’ve actually set to logging.
Last week, Check Point released the first major update to the Gaia-introducing R75.40 version. The release of R75.45 mainly brings enhancements and fixes for the new Gaia platform:
R75.45 Release Notes
R75.45 Resolved Issues
R75.45 Known Limitations
R75.45 includes this R75.40 hotfix.
Among the new features provided, support for 6in4 tunneling, policy-based routing appear to be the most intriguing (at least to me).
The long list of fixes addresses important issues such as long policy install time, kernel memory leaks or IPS not exiting bypass mode again after returning to normal CPU utilization.
Only direct upgrades from R75.40 are supported, no earlier versions.
I haven’t tried this new release yet, but given the list of fixes and potential first prematureness of the still young Gaia platform, I’ll check it out rather sooner than later.
We have a couple of 802.11q VLAN interfaces on our Check Point Firewalls for a number of small public DMZ networks, providing full layer 2 isolation for usually only one or two related servers in those networks. Using a /29 subnet for each VLAN means minus broadcast and network address, we can assign 6 (public) IP addresses in those networks. We also need an IP for the virtual ClusterXL interface to be used as a gateway by the servers. Up until recently, we also used 2 more IPs of each subnet for the members VLAN interfaces, so they can communicate via Check Points Cluster Control Protocol or CCP. This left us with merely 3 public IPv4 addresses per /29 subnet for actual servers inside those VLANs.
Configuring Cluster Addresses on Different Subnets
Wasting IPs like this on interfaces transparent for your actual services is not really practical in times of scarce IPv4 address space though. So what we did was getting rid of using IP addresses of the public subnet for the VLAN interfaces of each cluster member during our upgrade to R75.40 and Gaia on new systems. This configuration is fully supported (actually since long ago) as per ClusterXL Admin Guide:
Only one routable IP address is required in a ClusterXL cluster, for the virtual cluster interface that faces the Internet. All cluster member physical IP addresses can be non-routable.Configuring different subnets for the cluster IP addresses and the member addresses is useful in order to:
– Enable a multi-machine cluster to replace a single-machine gateway in a pre-configured network, without the need to allocate new addresses to the cluster members.
– Allow organizations to use only one routable address for the ClusterXL Gateway Cluster. This saves routable addresses.