Re: DOS attack details in
That only makes sense. After all, who has the easiest access and the most knowledge of the systems? Regards, Richard Schuh But information security warns us that insiders are more of a threat than= outsiders. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
Re: DOS attack details in
We have seen these from time to time. When we get them, they come in one of two flavors. Either someone pounding SNMP to try to use us as an open relay or more frequently in an attempt to DOS or hack us via FTP. To help minimize (not eliminate) the impact, we have EXITs in place for both SMTP and FTP. For SNMP, an forwarding causes the EXIT to issue a NETSTAT BLOCK for the IP address. In the case of FTP, our EXIT checks for an attempt to use an ID of ADMINxxx (and a collection of others). When that occurs, again ... NETSTAT BLOCK offending IP address. And of course when the DOS is purely DOS, and the only signal is a notification from TCPIP, we manually do a NETSTAT BLOCK for xxx.xxx.* Of course, the last example catches an entire network, but only once have we inadvertently stop a legitimate site from being to reach us. The result doesn't alway truly stop the offender, but it minimizes the impact on TCPIP and of course, our security console activity. On Thu, 31 Jul 2008 08:27:43 -0500, Mike Walter [EMAIL PROTECTED] wrote: Back on July 15, we experienced our first known Denial of Service attack (more likely a problem server). I reported it to our Internet Security group including: From the nearly anonymous/invisible TCPIPMESSAGE file in TCPMAINT's reader: ---snip DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 DTCUTI002E A denial-of-service attack has been detected ---snip--- Nearly invisible? They show up in my reader and have since I moved into VM Systems. Far from being anonymous/invisible, they are rather overly frequent. Since I have 20 (?) of those readers, I long ago arranged to forward SOME of these messages to my email address. The rest just go in a log file. Like you, we found the DOS came from our Information Security folk's server. (At least they didn't try to hide it -- there is an email address attached.) So far we haven't ever gotten a nastygram from these folks telling us we are insecure, but I have seen such emails addressed to others. Presumably that means VM does the right thing. Like others our VM systems are behind a firewall. But information security warns us that insiders are more of a threat than outsiders. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com Regards, Tony Noto Software Development Manager Velocity Software, Inc 650/964-8867 http://www.velocitysoftware.com
Re: DOS attack details in
We had this DOS attack and tracked it back to a MAC computer on the network. It was doing some sort of broadcast network thing. I can supply the details if it's important to anyone. Not being a network wizard, I tend to forget the details. Jim Hughes 603-271-5586 Its kind of fun to do the impossible. (Walt Disney) =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of Mike Walter =Sent: Thursday, July 31, 2008 9:28 AM =To: IBMVM@LISTSERV.UARK.EDU =Subject: DOS attack details in = =Back on July 15, we experienced our first known Denial of Service attack =(more likely a problem server). =I reported it to our Internet Security group including: = =From the nearly anonymous/invisible TCPIPMESSAGE file in =TCPMAINT's reader: =---snip =DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 =DTCUTI002E A denial-of-service attack has been detected =---snip--- = =Issued after the nearly anonymous/invisible TCPIPMESSAGE file in =TCPMAINT's reader was accidentally discovered: =---snip--- =netstat dos =VM TCP/IP Netstat Level 510 = =Maximum Number of Half Open Connections: 512 = =Denial of service attacks: = Attacks Elapsed =Attack =Attack IP Address Detected Time =Duration = --- - - =- =Smurf-IC 10.64.103.250 1 2:27:08 =0:00:00 =Ready; T=0.02/0.02 18:13:13 =---snip--- = =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 TCPIPMESSAGE 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. = =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. = =Mike Walter =Hewitt Associates =Any opinions expressed herein are mine alone and do not necessarily =represent the opinions or policies of Hewitt Associates. = = = = =The information contained in this e-mail and any accompanying documents =may contain information that is confidential or otherwise protected from =disclosure. If you are not the intended recipient of this message, or if =this message has been addressed to you in error, please immediately alert =the sender by reply e-mail and then delete this message, including any =attachments. Any dissemination, distribution or other use of the contents =of this message by anyone other than the intended recipient is strictly =prohibited. All messages sent to and from this e-mail address may be =monitored as permitted by applicable law and regulations to ensure =compliance with our internal policies and to protect our business. E-mails =are not secure and cannot be guaranteed to be error free as they can be =intercepted, amended, lost or destroyed, or contain viruses. You are =deemed to have accepted these risks if you communicate with us by e-mail.
Re: DOS attack details in
Thanks, Jim, The source of this one-time attack is less important than getting clear documentation about _who/what_ is doing the attack _when_ it happens. I have no problem writing automation to gather the details no matter how many hoops I have to jump through - until I have to jump through what I then deem as too many, at which point I'll whine about needing to improve the diagnostic process flow! :-)~ But getting the details when they are available (we have the luxury of IPLing each Sunday night - and DO), and getting them to the right people nearer to the attack time: now IMHO, that's a worthy goal. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Hughes, Jim [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/31/2008 09:05 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DOS attack details in We had this DOS attack and tracked it back to a MAC computer on the network. It was doing some sort of broadcast network thing. I can supply the details if it's important to anyone. Not being a network wizard, I tend to forget the details. Jim Hughes 603-271-5586 Its kind of fun to do the impossible. (Walt Disney) =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of Mike Walter =Sent: Thursday, July 31, 2008 9:28 AM =To: IBMVM@LISTSERV.UARK.EDU =Subject: DOS attack details in = =Back on July 15, we experienced our first known Denial of Service attack =(more likely a problem server). =I reported it to our Internet Security group including: = =From the nearly anonymous/invisible TCPIPMESSAGE file in =TCPMAINT's reader: =---snip =DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 =DTCUTI002E A denial-of-service attack has been detected =---snip--- = =Issued after the nearly anonymous/invisible TCPIPMESSAGE file in =TCPMAINT's reader was accidentally discovered: =---snip--- =netstat dos =VM TCP/IP Netstat Level 510 = =Maximum Number of Half Open Connections: 512 = =Denial of service attacks: = Attacks Elapsed =Attack =Attack IP Address Detected Time =Duration = --- - - =- =Smurf-IC 10.64.103.250 1 2:27:08 =0:00:00 =Ready; T=0.02/0.02 18:13:13 =---snip--- = =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 TCPIPMESSAGE 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. = =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. = =Mike Walter =Hewitt Associates =Any opinions expressed herein are mine alone and do not necessarily =represent the opinions or policies of Hewitt Associates. = = = = =The information contained in this e-mail and any accompanying documents =may contain information that is confidential or otherwise protected from =disclosure. If you are not the intended recipient of this message, or if =this message has been addressed to you in error, please immediately alert =the sender by reply e-mail and then delete this message, including any =attachments. Any dissemination, distribution or other use of the contents =of this message by anyone other than the intended recipient is strictly =prohibited. All messages sent to and from this e-mail address may be =monitored as permitted by applicable law and regulations to ensure =compliance with our internal policies and to protect our business. E-mails =are not secure and cannot be guaranteed to be error free as they can be =intercepted, amended, lost or destroyed, or contain viruses. You are =deemed to have accepted these risks if you communicate with us by e-mail. The information contained in this e-mail and any accompanying documents may contain information
Re: DOS attack details in
Dunno, I'm not an IP (or networking) Wizard, either. Not sure what else might be able to be gathered, but at least TCPIP knows what port was being attacked. Great minds will think of more. Perhaps information for that IP address obtained from NETSTAT CONN? Wizards will think of more. Anything else it could provide could be useful in tracking down the offending attacker, and preparing them for a public hanging. ;-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Hughes, Jim [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/31/2008 09:31 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DOS attack details in I used the IP address to track down the offending MAC system. What other information would be available? Just curious. Jim Hughes 603-271-5586 Its kind of fun to do the impossible. (Walt Disney) =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of Mike Walter =Sent: Thursday, July 31, 2008 10:25 AM =To: IBMVM@LISTSERV.UARK.EDU =Subject: Re: DOS attack details in = =Thanks, Jim, = =The source of this one-time attack is less important than getting clear =documentation about _who/what_ is doing the attack _when_ it happens. =I have no problem writing automation to gather the details no matter how =many hoops I have to jump through - until I have to jump through what I =then deem as too many, at which point I'll whine about needing to =improve the diagnostic process flow! :-)~ = =But getting the details when they are available (we have the luxury of =IPLing each Sunday night - and DO), and getting them to the right people =nearer to the attack time: now IMHO, that's a worthy goal. = =Mike Walter =Hewitt Associates =Any opinions expressed herein are mine alone and do not necessarily =represent the opinions or policies of Hewitt Associates. = = = =Hughes, Jim [EMAIL PROTECTED] = =Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU =07/31/2008 09:05 AM =Please respond to =The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU = = = =To =IBMVM@LISTSERV.UARK.EDU =cc = =Subject =Re: DOS attack details in = = = = = = =We had this DOS attack and tracked it back to a MAC computer on the =network. It was doing some sort of broadcast network thing. I can supply =the details if it's important to anyone. Not being a network wizard, I =tend to forget the details. = = =Jim Hughes =603-271-5586 =Its kind of fun to do the impossible. (Walt Disney) = ==-Original Message- ==From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] =On ==Behalf Of Mike Walter ==Sent: Thursday, July 31, 2008 9:28 AM ==To: IBMVM@LISTSERV.UARK.EDU ==Subject: DOS attack details in == ==Back on July 15, we experienced our first known Denial of Service =attack ==(more likely a problem server). ==I reported it to our Internet Security group including: == ==From the nearly anonymous/invisible TCPIPMESSAGE file in ==TCPMAINT's reader: ==---snip ==DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 ==DTCUTI002E A denial-of-service attack has been detected ==---snip--- == ==Issued after the nearly anonymous/invisible TCPIPMESSAGE =file in ==TCPMAINT's reader was accidentally discovered: ==---snip--- ==netstat dos ==VM TCP/IP Netstat Level 510 == ==Maximum Number of Half Open Connections: 512 == ==Denial of service attacks: == Attacks Elapsed ==Attack ==Attack IP Address Detected Time ==Duration == --- - - ==- ==Smurf-IC 10.64.103.250 1 2:27:08 ==0:00:00 ==Ready; T=0.02/0.02 18:13:13 ==---snip--- == ==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 TCPIPMESSAGE 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. == ==BTW, the current release of VM:Operator loops (or otherwise fails
Re: DOS attack details in
The port and IP address sending the request should be in the monitor records. There would some inforamation useful there. Mike Walter wrote: Back on July 15, we experienced our first known Denial of Service attack (more likely a problem server). I reported it to our Internet Security group including: From the nearly anonymous/invisible TCPIPMESSAGE file in TCPMAINT's reader: ---snip DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 DTCUTI002E A denial-of-service attack has been detected ---snip--- Issued after the nearly anonymous/invisible TCPIPMESSAGE file in TCPMAINT's reader was accidentally discovered: ---snip--- netstat dos VM TCP/IP Netstat Level 510 Maximum Number of Half Open Connections: 512 Denial of service attacks: Attacks Elapsed Attack Attack IP Address Detected Time Duration --- - - - Smurf-IC 10.64.103.250 1 2:27:08 0:00:00 Ready; T=0.02/0.02 18:13:13 ---snip--- 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 TCPIPMESSAGE 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. 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. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: DOS attack details in
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 TCPIPMESSAGE 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
Re: DOS attack details in
Mike Walter wrote: Dunno, I'm not an IP (or networking) Wizard, either. Not sure what else might be able to be gathered, but at least TCPIP knows what port was being attacked. Great minds will think of more. Perhaps information for that IP address obtained from NETSTAT CONN? Wizards will think of more. Anything else it could provide could be useful in tracking down the offending attacker, and preparing them for a public hanging. ;-) There's about a usdebtillion books about this sort of thing, e.g. http://oreilly.com/catalog/9780596003234/index.html Welcome to the Unix world. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: DOS attack details in
Mike, Smurf attacks are malformed ICMP echo packets. They aren't directed to a particular port. You've got all the information there is :-) Regards, Miguel Delapaz z/VM TCP/IP Development The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 07/31/2008 07:40:23 AM: [image removed] Re: DOS attack details in Mike Walter to: IBMVM 07/31/2008 07:42 AM Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Please respond to The IBM z/VM Operating System Dunno, I'm not an IP (or networking) Wizard, either. Not sure what else might be able to be gathered, but at least TCPIP knows what port was being attacked. Great minds will think of more. Perhaps information for that IP address obtained from NETSTAT CONN? Wizards will think of more. Anything else it could provide could be useful in tracking down the offending attacker, and preparing them for a public hanging. ;-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Hughes, Jim [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/31/2008 09:31 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DOS attack details in I used the IP address to track down the offending MAC system. What other information would be available? Just curious. Jim Hughes 603-271-5586 Its kind of fun to do the impossible. (Walt Disney) =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of Mike Walter =Sent: Thursday, July 31, 2008 10:25 AM =To: IBMVM@LISTSERV.UARK.EDU =Subject: Re: DOS attack details in = =Thanks, Jim, = =The source of this one-time attack is less important than getting clear =documentation about _who/what_ is doing the attack _when_ it happens. =I have no problem writing automation to gather the details no matter how =many hoops I have to jump through - until I have to jump through what I =then deem as too many, at which point I'll whine about needing to =improve the diagnostic process flow! :-)~ = =But getting the details when they are available (we have the luxury of =IPLing each Sunday night - and DO), and getting them to the right people =nearer to the attack time: now IMHO, that's a worthy goal. = =Mike Walter =Hewitt Associates =Any opinions expressed herein are mine alone and do not necessarily =represent the opinions or policies of Hewitt Associates. = = = =Hughes, Jim [EMAIL PROTECTED] = =Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU =07/31/2008 09:05 AM =Please respond to =The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU = = = =To =IBMVM@LISTSERV.UARK.EDU =cc = =Subject =Re: DOS attack details in = = = = = = =We had this DOS attack and tracked it back to a MAC computer on the =network. It was doing some sort of broadcast network thing. I can supply =the details if it's important to anyone. Not being a network wizard, I =tend to forget the details. = = =Jim Hughes =603-271-5586 =Its kind of fun to do the impossible. (Walt Disney) = ==-Original Message- ==From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] =On ==Behalf Of Mike Walter ==Sent: Thursday, July 31, 2008 9:28 AM ==To: IBMVM@LISTSERV.UARK.EDU ==Subject: DOS attack details in == ==Back on July 15, we experienced our first known Denial of Service =attack ==(more likely a problem server). ==I reported it to our Internet Security group including: == ==From the nearly anonymous/invisible TCPIPMESSAGE file in ==TCPMAINT's reader: ==---snip ==DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 ==DTCUTI002E A denial-of-service attack has been detected ==---snip--- == ==Issued after the nearly anonymous/invisible TCPIPMESSAGE =file in ==TCPMAINT's reader was accidentally discovered: ==---snip--- ==netstat dos ==VM TCP/IP Netstat Level 510 == ==Maximum Number of Half Open Connections: 512 == ==Denial of service attacks: == Attacks Elapsed ==Attack ==Attack IP Address Detected Time ==Duration == --- - - ==- ==Smurf-IC 10.64.103.250 1 2:27:08 ==0:00:00 ==Ready; T=0.02/0.02 18:13:13 ==---snip--- == ==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
Re: DOS attack details in
We had a DOS attack a couple of years ago and duly reported it to our Info Sec group. We got no response. When it happened again one month later, we tracked it down to a server owned by Info. Sec. We blocked its IP address and have had no problem since. It seems that those folks have an automated monthly probe of every IP address on our intranet. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Thursday, July 31, 2008 6:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: DOS attack details in Back on July 15, we experienced our first known Denial of Service attack (more likely a problem server). I reported it to our Internet Security group including: From the nearly anonymous/invisible TCPIPMESSAGE file in TCPMAINT's reader: ---snip DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 DTCUTI002E A denial-of-service attack has been detected ---snip--- Issued after the nearly anonymous/invisible TCPIP MESSAGE file in TCPMAINT's reader was accidentally discovered: ---snip--- netstat dos VM TCP/IP Netstat Level 510 Maximum Number of Half Open Connections: 512 Denial of service attacks: Attacks Elapsed Attack Attack IP Address Detected Time Duration --- - - - Smurf-IC 10.64.103.250 1 2:27:08 0:00:00 Ready; T=0.02/0.02 18:13:13 ---snip--- 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 TCPIPMESSAGE 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. 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. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: DOS attack details in
Thanks, guys! Helpful information. I'll have to print it and put it in the TCPIP Msgs and Codes manual right by the message: DTCIPU086I A denial-of-service attack has been detected Your words of wisdom go well beyond that found in the Messages and Codes in the manual (but at least it's not a self-descriptive message). Welcome to the Unix world, indeed! :-( And Alan, by NOTIFY could you actually have meant INFORM? Perhaps you were just attempting to NOTIFY me to *look up* INFORM? ;-) The doc in the manual for INFORM is rather lackluster, stating: Use the INFORM statement to define a list of users (called the INFORM list) who are to be sent messages in case of serious run-time conditions. It does not indicate what a message might be, but it turns out that it is not only a message, but also a NETDATA format file sent to their reader.. OPERATOR here cares little for reader files, while messages are useful. But does processing the OBEYFILE command qualify as a one of the serious run-time conditions? I ask that carefully, since processing the OBEYFILE command can rather seriously affect the run-time environment. But is it really an *error*?: FILE: TCPIPMESSAGE A1 Hewitt Associates PAGE 1 DTCUTI002E OBEYFILE issued successfully by TCPMAINT. File INFORM TCPIP located on TCPMAINT 0191 dated 07/31/08 10:41 Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Miguel Delapaz [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/31/2008 10:17 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DOS attack details in Mike, Smurf attacks are malformed ICMP echo packets. They aren't directed to a particular port. You've got all the information there is :-) Regards, Miguel Delapaz z/VM TCP/IP Development The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 07/31/2008 07:40:23 AM: [image removed] Re: DOS attack details in Mike Walter to: IBMVM 07/31/2008 07:42 AM Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Please respond to The IBM z/VM Operating System Dunno, I'm not an IP (or networking) Wizard, either. Not sure what else might be able to be gathered, but at least TCPIP knows what port was being attacked. Great minds will think of more. Perhaps information for that IP address obtained from NETSTAT CONN? Wizards will think of more. Anything else it could provide could be useful in tracking down the offending attacker, and preparing them for a public hanging. ;-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Hughes, Jim [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/31/2008 09:31 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DOS attack details in I used the IP address to track down the offending MAC system. What other information would be available? Just curious. Jim Hughes 603-271-5586 Its kind of fun to do the impossible. (Walt Disney) =-Original Message- =From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On =Behalf Of Mike Walter =Sent: Thursday, July 31, 2008 10:25 AM =To: IBMVM@LISTSERV.UARK.EDU =Subject: Re: DOS attack details in = =Thanks, Jim, = =The source of this one-time attack is less important than getting clear =documentation about _who/what_ is doing the attack _when_ it happens. =I have no problem writing automation to gather the details no matter how =many hoops I have to jump through - until I have to jump through what I =then deem as too many, at which point I'll whine about needing to =improve the diagnostic process flow! :-)~ = =But getting the details when they are available (we have the luxury of =IPLing each Sunday night - and DO), and getting them to the right people =nearer to the attack time: now IMHO, that's a worthy goal. = =Mike Walter =Hewitt Associates =Any opinions expressed herein are mine alone and do not necessarily =represent the opinions or policies of Hewitt Associates. = = = =Hughes, Jim [EMAIL PROTECTED] = =Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU =07/31/2008 09:05 AM =Please respond to =The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU = = = =To =IBMVM@LISTSERV.UARK.EDU =cc = =Subject =Re: DOS attack details in = = = = = = =We had this DOS attack and tracked it back to a MAC computer on the =network. It was doing some sort of broadcast network thing. I can supply =the details if it's important to anyone. Not being
Re: DOS attack details in
Hello Everyone, You may see more because to comply with PCI (Payment Card Industry) Security Standards you are required to have all Internet Facing IP addresses scanned for vulnerabilities. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, July 31, 2008 11:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DOS attack details in We had a DOS attack a couple of years ago and duly reported it to our Info Sec group. We got no response. When it happened again one month later, we tracked it down to a server owned by Info. Sec. We blocked its IP address and have had no problem since. It seems that those folks have an automated monthly probe of every IP address on our intranet. Regards, Richard Schuh
Re: DOS attack details in
At 01:18 PM 7/31/2008 -0400, Edward M. Martin wrote: You may see more because to comply with PCI (Payment Card Industry) Security Standards you are required to have all Internet Facing IP addresses scanned for vulnerabilities. The key line there may be, Internet Facing; how many companies put their key systems behind NAT'ting firewalls? My last client runs all their internal systems on the 10. network (non-routable, so not Internet facing), and my systems before that were behind two levels of (non-NAT'ting) firewall. Oh, wait, sorry, I'm trying to use Earth Logic with security policies, for which Chuckie will surely mock me.
Re: DOS attack details in
Nick Laflamme wrote: The key line there may be, Internet Facing; how many companies put their key systems behind NAT'ting firewalls? Easiest really pretty secure solution: put an OpenBSD firewall between your Big Iron and the Net. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: DOS attack details in
You did notice the word intranet, not internet, in my post, did you not? VM is definitely behind a firewall that makes us invisible to the outside world. Furthermore, the network that we are on is isolated from our production network. It may well be that there is some zeal in interpreting the rules established for the public networks. In our case, zeal is good. I would rather they overdo security than underdo it. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jack Woehr Sent: Thursday, July 31, 2008 10:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DOS attack details in Nick Laflamme wrote: The key line there may be, Internet Facing; how many companies put their key systems behind NAT'ting firewalls? Easiest really pretty secure solution: put an OpenBSD firewall between your Big Iron and the Net. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: DOS attack details in
You did notice the word intranet, not internet, in my post, did you not? VM is definitely behind a firewall that makes us invisible to the outside world. Furthermore, the network that we are on is isolated from our production network. It may well be that there is some zeal in interpreting the rules established for the public networks. In our case, zeal is good. I would rather they overdo security than underdo it. Richard, I think that is a really good point and I totally agree. When it comes to my VM and VSE systems, I want to be absolutely certain that they are isolated from the rest of the network. There isn't really such a thing as too much security in this context. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DOS attack details in
On Thursday, 07/31/2008 at 01:18 EDT, Mike Walter [EMAIL PROTECTED] wrote: And Alan, by NOTIFY could you actually have meant INFORM? Perhaps you were just attempting to NOTIFY me to *look up* INFORM? ;-) Yes, I meant INFORM. NOTIFY is the internal function used to send information to the INFORM list. :-) But does processing the OBEYFILE command qualify as a one of the serious run-time conditions? I ask that carefully, since processing the OBEYFILE command can rather seriously affect the run-time environment. But is it really an *error*?: FILE: TCPIPMESSAGE A1 Hewitt Associates PAGE 1 DTCUTI002E OBEYFILE issued successfully by TCPMAINT. File INFORM TCPIP located on TCPMAINT 0191 dated 07/31/08 10:41 No, it is not an error. It is a potentially serious run-time condition, however, as it is the only record that someone has dynamically changed the TCP/IP configuration. If you had TRACE SECURITY you would get even more detail. If TCP/IP messages were more, uh, disciplined (yeah. disciplined.), then I might raise an eyebrow at the severity code. At this point, it might do more harm than good to change it. yawn Alan Altmark z/VM Development IBM Endicott
Re: DOS attack details in
On Thu, 31 Jul 2008 08:27:43 -0500, Mike Walter [EMAIL PROTECTED] wrote: Back on July 15, we experienced our first known Denial of Service attac k (more likely a problem server). I reported it to our Internet Security group including: From the nearly anonymous/invisible TCPIPMESSAGE file in TCPMAINT's reader: ---snip DTCUTI001E Serious problem encountered: 15:38:55 07/15/08 DTCUTI002E A denial-of-service attack has been detected ---snip--- Nearly invisible? They show up in my reader and have since I moved into V M Systems. Far from being anonymous/invisible, they are rather overly frequent. Since I have 20 (?) of those readers, I long ago arranged to forward SOME of these messages to my email address. The rest just go in a log file. Like you, we found the DOS came from our Information Security folk's serv er. (At least they didn't try to hide it -- there is an email address attached.) So far we haven't ever gotten a nastygram from these folks telling us we are insecure, but I have seen such emails addressed to others. Presumably that means VM does the right thing. Like others our VM systems are behind a firewall. But information security warns us that insiders are more of a threat than outsiders. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
