If the ARP data is being falsified, visitors to the site could be directed to an alternate clone server, hosting pages with content the same as the original server but also including malicious code. If this is the case then the actual webserver has not been compromised, but users are still being exposed to the malicious code through the cloned server.
For example:
Say the webserver of the victim site has a public IP of (1.1.1.1), and a MAC address of (11:11:11:11:11:11). Its home page is (index.html).
The victim site's ISP decides to perform an ARP attack. They set up a server which hosts a clone of the victim site. This server has a MAC address of (22:22:22:22:22:22). However, they modify (index.html) to include malicious code.
The ISP sets up their managed switch so that instead of mapping (1.1.1.1) to (11:11:11:11:11:11), which would be correct, they map (1.1.1.1) to (22:22:22:22:22:22). Now, when users try to visit (1.1.1.1), they will visit the cloned server instead of the original server, and be exposed to the malicious code on the modified (index.html), even though the original server has not been compromised.
In short the requirement is for a secure method to make sure that once a log is written it can never be deleted or changed.
Although it is possible to prevent logs from being modified (using write-once media) or undetectably tampered with (using crypto, possibly with a TPM module for the ultra-paranoid), any log can be 'deleted' by physically destroying the device/media on which it is stored.
Last week, I attended a presentation at IBM's Australian Development Lab in West Perth, where a lot of the z/OS-related code is maintained and developed.
From what we were told, IBM z/OS mainframes are the *most* reliable platform to host software services (but of course, they'd say that).
The following is from memory, as best as I can remember it, and may not be 100% accurate:
The 'z' in 'z/OS' stands for 'zero downtime'. z System mainframes are engineered for 99.999% availability, or less than 3 minutes of downtime a year (we were actually quoted 'less than 5 minutes', but (1 - 99.999%) * 365.25 * 12 * 60 = 2.63). Apparently, they quite easily meet this requirement - we were told that it is not uncommon for systems to remain online for 10 years or more without failing.
Up to 32 z System mainframes can be clustered in a 'sysplex'. Each mainframe is divided into several LPARs (Logical Partitions), each which can host several VMs. If an application fails, the automated recovery service will attempt to restart it, either on the same VM, a different VM, a different LPAR or a different mainframe in the sysplex, as appropriate in the situation. It is also possible to host a redundant sysplex in a different site, which mirrors data and which the primary sysplex can failover to in the case of failure.
IBM mainframes are used in many major corporations around the world, particularly those where the cost of downtime is very high (think thousands of dollars a second).
Slashdot Mirror
If the ARP data is being falsified, visitors to the site could be directed to an alternate clone server, hosting pages with content the same as the original server but also including malicious code. If this is the case then the actual webserver has not been compromised, but users are still being exposed to the malicious code through the cloned server.
For example:
Say the webserver of the victim site has a public IP of (1.1.1.1), and a MAC address of (11:11:11:11:11:11). Its home page is (index.html).
The victim site's ISP decides to perform an ARP attack. They set up a server which hosts a clone of the victim site. This server has a MAC address of (22:22:22:22:22:22). However, they modify (index.html) to include malicious code.
The ISP sets up their managed switch so that instead of mapping (1.1.1.1) to (11:11:11:11:11:11), which would be correct, they map (1.1.1.1) to (22:22:22:22:22:22). Now, when users try to visit (1.1.1.1), they will visit the cloned server instead of the original server, and be exposed to the malicious code on the modified (index.html), even though the original server has not been compromised.
.. a new meaning to the term 'viral video'.
Although it is possible to prevent logs from being modified (using write-once media) or undetectably tampered with (using crypto, possibly with a TPM module for the ultra-paranoid), any log can be 'deleted' by physically destroying the device/media on which it is stored.
Edit: Error in my calc - there's 24 hours a day, not 12.
(1 - 99.999%) * 365.25 * 24 * 60 = 5.23
Last week, I attended a presentation at IBM's Australian Development Lab in West Perth, where a lot of the z/OS-related code is maintained and developed.
From what we were told, IBM z/OS mainframes are the *most* reliable platform to host software services (but of course, they'd say that).
The following is from memory, as best as I can remember it, and may not be 100% accurate:
The 'z' in 'z/OS' stands for 'zero downtime'. z System mainframes are engineered for 99.999% availability, or less than 3 minutes of downtime a year (we were actually quoted 'less than 5 minutes', but (1 - 99.999%) * 365.25 * 12 * 60 = 2.63). Apparently, they quite easily meet this requirement - we were told that it is not uncommon for systems to remain online for 10 years or more without failing.
Up to 32 z System mainframes can be clustered in a 'sysplex'. Each mainframe is divided into several LPARs (Logical Partitions), each which can host several VMs. If an application fails, the automated recovery service will attempt to restart it, either on the same VM, a different VM, a different LPAR or a different mainframe in the sysplex, as appropriate in the situation. It is also possible to host a redundant sysplex in a different site, which mirrors data and which the primary sysplex can failover to in the case of failure.
IBM mainframes are used in many major corporations around the world, particularly those where the cost of downtime is very high (think thousands of dollars a second).