Top Six Ways of log Event monitoring

1.     Aggregate your logs in a central location: With logs spread across dozens or even hundreds of systems, there’s no way you can manage them where they are. Event log monitoring applications can gather up all your logs in a central location, making them easy to analyze, store, and manage.

2.     Perform security checks with SIEM: Regular security reviews are great, but they are reviews. They can only catch things that have already happened. Event log monitoring with Security Information and Events Monitoring (SIEM) can detect issues in real time, allowing you to respond before bad things happen.

3.     Work with multiple formats: One of the biggest challenges with manually parsing logs is the number of different formats that are out there, from syslog to SNMP traps, to IIS W3C logs and Windows events. Event log monitoring can deal with all of these and more, so you can focus on what happened, and let the app worry about in what format it was recorded.

4.     Perform searches across logs: With multiple systems involved, if you cannot search across logs, you cannot tie events together. Event log monitoring can search across all your logs to find what is happening across multiple systems.

5.     Correlate events: Event correlation is impossible manually, but is easy for event log monitoring applications to handle, connecting the dots between security logs on domain controllers, connection logs on VPN concentrators, file access logs on servers, etc.

6.     Meet compliance requirements: With so many regulations requiring not only that you log, but that you review and respond to events in logs, event log monitoring applications can automate the tasks that will help you to meet your compliance requirements. It’s a very economical way to ensure you don’t have an exception in your audit report.

Event log monitoring makes it easy for even a single admin to manage the logs across all the servers and applications in the environment, ensuring nothing is missed and that the admin has all the information at hand to address any requirement. Event log monitoring is the right approach to proactive management.

Courtesy : The Hackers News

Flawed ethernet controller from Intel exposes you to "Packet of death" attack

The hardware qualification is a very important issue, recent vulnerabilities discovered in network appliances of various manufacturer have alerted security community once again on the necessity to validate the hardware especially for large consume product.

The last news is related to a vulnerability related to the Intel's 82574L Ethernet controller that expose equipment to risk of "packet of death." Attack.

Star2Star's chief technology officer Kristian Kielhofneridentified the cause of the problems after customers experienced random crashes. Researchers at Star2Star after the analysis of lot traffic identified the cause of the problem in the format of a packet managed by a particular VoIP manufacturer.

But as yet it is unclear how widespread the problem is or how other Intel hardware is affected.

Kielhofner, wrote: "The system and Ethernet interfaces would appear fine," "and then after a random amount of traffic the interface would report a hardware error (lost communication with PHY) and lose link. Literally the link lights on the switch and interface would go out. It was dead."

"Nothing but a power cycle would bring it back. Attempting to reload the kernel module or reboot the machine would result in a PCI scan error. The interface was dead until the machine was physically powered down and powered back on. In many cases, for our customers, this meant a truck roll."

"Problem packets had just the right Call-ID, tags, and branches to cause the '2' in the ptime to line up with 0x47f."

The problem is very insidious, Kielhofner's team was able to create packets and target them at particular systems.

"With a modified HTTP server configured to generate the data at byte value (based on headers, host, etc.) you could easily configure an HTTP 200 response to contain the packet of death - and kill client machines behind firewalls!"

Kielhofner has posted a test page that allows system admins to test to see if their devices are vulnerable, meantime his team is working with Intel to produce a fix for the bug.

Update: Intel has responded with an expanded technical explanation of the issue. Intel was made aware of this issue in September 2012 by the blogs author.

Douglas Boom from Intel said in a blog post, "Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer."

"It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller."

Whereas,Kristian Kielhofner said, "However, I still don’t believe this issue is completely isolated to this specific instance and one motherboard manufacturer. For one, I have received at least two confirmed reports from people who were able to reproduce this issue - my “packet of death” shutting down 82574L hardware from different motherboard manufacturers."

Courtesy: The Hacker News