On Thursday, 07/31/2008 at 09:30 EDT, Mike Walter <[EMAIL PROTECTED]> wrote:
> So I asked our Internet Security team who might be the offending > "10.64.103.250". In turn they asked me for the port number being used for > this attack, and the mac address of the attacking machine. Unfortunately, > none of that is available after the attack (which was admirably and > automatically quashed by the z/VM TCPIP stack). > > Would it be possible to include more information in the nearly > anonymous/invisible "TCPIP MESSAGE" file in TCPMAINT's reader", > including the port being used and the MAC address, and the other > information displayed by the NETSTAT DOS command? If the attack is > discovered after the next time the stack is restarted, NETSTAT DOS doesn't > provide any information. Actually, I don't see any reason why all that > information could not be logged to the TCPIP stack console itself - as a > single point of reference should an investigation be required later. A SMURF-IC (incoming) attack is ICMP (PING). There is no port number since it is neither TCP nor UDP. It is most likely caused by a host that has its subnet configured incorrectly and has formed a target IP address that looks like a broadcast to the VM system. I don't understand the issue about the file. Every user on the NOTIFY list gets a message and a file. Why not NOTIFY a server to process the file, issue NETSTAT DOS, and then MSG your OPERATOR with something actionable? But you'll need to be careful about repeat notifications and use NETSTAT RESETDOS carefully. If you RESETDOS, then the next time the same attack is detected, another message will be sent. In the event of an acutal attack, you wouldn't want a message coming out every time a SMURF packet was detected. > BTW, the current release of VM:Operator loops (or otherwise fails to ever > respond) when the NETSTAT command is issued, so we can't even issue an > automated NETSTAT DOS command, trap the response, and try to gather useful > information during the attack. Perhaps there is a bug somewhere? NETSTAT uses VMCF messages and if VM:Operator is using them, there will be trouble. (VMCF is not sharable.) We recently fixed DIRMAINT to use IUCV instead of VMCF because of an unintended interaction with RACF's use of VMCF. (Fixing DIRMAINT was far easier than rearchitecting RACF.) Alan Altmark z/VM Development IBM Endicott
