Louwrentius

A feature on more recent HP Procurve models (18xx series, such as 1810G etc.) is called "Auto DoS". You can find it in the section "Security" and then "Advanced security".

If you enable the Auto DoS feature, traffic is blocked based on one of these conditions:

• the source port (TCP / UDP) is identical to the destination port (NTP, SYSLOG, etc)

• the source port (TCP / UDP) is 'privileged' thus in the range of 1 -1023.

This will cause all kinds of problems, but first this: "Why on earth is a Layer 2 device filtering on Layer 3?". This is just insane.

NTP does not work any more. Syslog traffic will not arive. VPN traffic may not arrive.

This issue cost me a lot of time to solve. I first blamed our Firewall, but the actual traffic arrived on the tagged trunk port on the affected switch. The traffic somehow was not sent to the switch port on which the destination device was connected.

Affected products:

HP ProCurve 1810G - J9449A ( 8 ports ) and J9450A ( 24 ports )

When a disk fails of a RAID 5 array, you are no longer protected against (another) disk failure and thus data loss. During this rebuild time, you are vulnerable. The longer it takes to rebuild your array, the longer you are vulnerable. Especially during a disk-intensive period, because the array must be reconstructed.

When one disk fails of a RAID 6 array, you are still protected against data loss because the array can take a second disk failure. So RAID 6 is almost always the better choice. Especially with large disks (1+ TB), because the rebuild time largely depends on the size of a single disk, not on the size of the entire RAID array.

However, there is one catch. The size of the RAID array matters when it becomes big, 10+ drives or more. No matter if you use hardware- or software- based RAID, the processor must read the contents of all drives simultaneously and use that information to rebuild the replaced drive. When creating a large RAID array, such as in my storage array, with 20 disks, the check and rebuild of the array becomes CPU-bound.

This is because the CPU must process 1,1 GB/s (as in gigabyte!) of data and use that data stream to rebuild that single drive. Using 1 TB drives, it checks or rebuilds the array at about 50 MB/s, which is less than half what the drives are capable of (100+ MB/s). Top shows that indeed the CPU is almost saturated (95%). Please note that a check or rebuild of my storage server takes about 5 hours currently, but that could be way shorter if the CPU was not saturated.

My array is not for professional use and fast rebuild times are not that of an issue. But if you're more serious about your setup, it may be advised to create more smaller RAID vollumes and glue them together using LVM or some similar solution.

People sometimes forget that there are also a number of UDP-based services that may pose a threat to the security of your systems. SNMP is a well-known service, notorious for being configured with a default password (or community string).

But there is another service that is often not seen as a risk. This is the syslog service. Syslog is used on virtually all UNIX-like platform for logging messages of the system to one or more log files to disk. The syslog service often listens on the network, on UDP-port 514. Please note that syslog does not perform any authentication of data that is sent to it.

So what does this mean?

An attacker can:

1. Create a denial-of-service condition (DoS) by sending large amounts of data to the syslog service, filling up disk space.

2. Once the disk is full, logs can no longer be saved, thus any attack that would leave a trail within the logs would go unnoticed.

3. by sending large amounts of specially crafted messages, an attacker can cause chaos if logs are monitored by intrusion detection systems or other systems that create alerts.

How to attack? Just use netcat:

nc -u [IP-address] 514

Once you are connected, anything you type will be logged in a log file.

How to mitigate this issue?

1. Firewall access to UDP-port 514

2. Make sure that the syslog service does not listen on the network if not required, only on localhost.