Re: UDP port 1434 [7:61891]
Chuck, If I'm the Ken you're talking about and I actually said that, then I must really need a nap. :-) We're a university, where Microsoft rules. :-( I'd like to tell you how many MS-SQL servers we have, but I don't have a clue. There are probably some running in the dorms. We have entire labs where this stuff is installed so they can teach it. I'd like to tell you how many machines have the MSDE installed, but again I don't have a clue. Did I mention dorms? Changing the way the campus conducts network business is a difficult task. I'm doing a lot of educating - to the campus technicians. By this time next year, I hope to say we have 75% of the campus firewalled. While that may sound easy, it may be wishful thinking. Although... this worm might really make a difference in my timeline. :-) BTW, by now, one of my access-lists has probably broken the billion mark for blocking UDP 1434. That's only internal traffic. A question I have: Is anyone learning anything from my rambling? If not, I'll happily take questions and suggestions ranging from how did you do X to why don't you take that nap. Ken The Long and Winding Road 01/27/03 09:18PM [snip] in an earlier message, Ken spoke about his own network, where there are few if any Microsoft SQL servers. Yet their internet links were saturated because of the attacks, and internal network replies. [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62013t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
sorry, Ken, I've read so much crap about saphire and 1434 the last couple of days that I forget who said what. sorry for misrepresenting you as a result of my frazzled brain. given the large installation of MS SQL devices on your campus, may we blame you and your wards for the problem? ;- Chuck -- TANSTAAFL there ain't no such thing as a free lunch Ken Diliberto wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chuck, If I'm the Ken you're talking about and I actually said that, then I must really need a nap. :-) We're a university, where Microsoft rules. :-( I'd like to tell you how many MS-SQL servers we have, but I don't have a clue. There are probably some running in the dorms. We have entire labs where this stuff is installed so they can teach it. I'd like to tell you how many machines have the MSDE installed, but again I don't have a clue. Did I mention dorms? Changing the way the campus conducts network business is a difficult task. I'm doing a lot of educating - to the campus technicians. By this time next year, I hope to say we have 75% of the campus firewalled. While that may sound easy, it may be wishful thinking. Although... this worm might really make a difference in my timeline. :-) BTW, by now, one of my access-lists has probably broken the billion mark for blocking UDP 1434. That's only internal traffic. A question I have: Is anyone learning anything from my rambling? If not, I'll happily take questions and suggestions ranging from how did you do X to why don't you take that nap. Ken The Long and Winding Road 01/27/03 09:18PM [snip] in an earlier message, Ken spoke about his own network, where there are few if any Microsoft SQL servers. Yet their internet links were saturated because of the attacks, and internal network replies. [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62065t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Well, um, yes. Although I removed us as part of the problem as soon as I noticed we were. :-) The Long and Winding Road 01/28/03 02:36PM sorry, Ken, I've read so much crap about saphire and 1434 the last couple of days that I forget who said what. sorry for misrepresenting you as a result of my frazzled brain. given the large installation of MS SQL devices on your campus, may we blame you and your wards for the problem? ;- Chuck -- TANSTAAFL there ain't no such thing as a free lunch Ken Diliberto wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chuck, If I'm the Ken you're talking about and I actually said that, then I must really need a nap. :-) We're a university, where Microsoft rules. :-( I'd like to tell you how many MS-SQL servers we have, but I don't have a clue. There are probably some running in the dorms. We have entire labs where this stuff is installed so they can teach it. I'd like to tell you how many machines have the MSDE installed, but again I don't have a clue. Did I mention dorms? Changing the way the campus conducts network business is a difficult task. I'm doing a lot of educating - to the campus technicians. By this time next year, I hope to say we have 75% of the campus firewalled. While that may sound easy, it may be wishful thinking. Although... this worm might really make a difference in my timeline. :-) BTW, by now, one of my access-lists has probably broken the billion mark for blocking UDP 1434. That's only internal traffic. A question I have: Is anyone learning anything from my rambling? If not, I'll happily take questions and suggestions ranging from how did you do X to why don't you take that nap. Ken The Long and Winding Road 01/27/03 09:18PM [snip] in an earlier message, Ken spoke about his own network, where there are few if any Microsoft SQL servers. Yet their internet links were saturated because of the attacks, and internal network replies. [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=62071t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Prisiclla Amazing wrote: what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61969t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Maybe this is a silly question considering where I work, but is it common for huge banks to connect their ATMs to their data centers over the Internet? We certainly don't do that, and wouldn't even consider doing it, so I was surprised that BofA appears to be doing just that. Then again, they probably have twenty times more ATMs than we do, so perhaps they have different issues to be considered. John Priscilla Oppenheimer 1/27/03 11:24:42 AM Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Prisiclla Amazing wrote: what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61971t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Well, that's a good point. The UDP traffic jam probably didn't spread out to the edges of the network, where the ATMs are, as I had been thinking. The ATMs probably use private, non-routable addresses (non-routable over the Internet anyway). The bottleneck was probably more in the core of BoA's network. Then again, mabye they do use some sort of VPN solution for their ATMs, but I doubt that Well, I better get back to work. The worm is becoming even more of a DoS because so many network engineers are wasting time guessing about its effects, rather than offering the services they should be! Just kidding. Priscilla John Neiberger wrote: Maybe this is a silly question considering where I work, but is it common for huge banks to connect their ATMs to their data centers over the Internet? We certainly don't do that, and wouldn't even consider doing it, so I was surprised that BofA appears to be doing just that. Then again, they probably have twenty times more ATMs than we do, so perhaps they have different issues to be considered. John Priscilla Oppenheimer 1/27/03 11:24:42 AM Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Prisiclla Amazing wrote: what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61975t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL
Re: UDP port 1434 [7:61891]
No, it is relatively unheard of. Transaction data almost always (and I say that because I cannot categorically say always) travels on dedicated circuits. A lot has been made over this for some reason, and I have not seen an official explanation from Bof Afor all I know it could have been routine work on BofA's part that knocked them out of service, like a code upgrade or somethingwe all know THAT never happens...(admittedly it's probably not the case, the timing is too coincidental, but all the facts aren't in yet, or if they are, they haven't been made available as far as I know) John Neiberger cc: Sent by:Subject: Re: UDP port 1434 [7:61891] [EMAIL PROTECTED] 01/27/2003 01:51 PM Please respond to John Neiberger Maybe this is a silly question considering where I work, but is it common for huge banks to connect their ATMs to their data centers over the Internet? We certainly don't do that, and wouldn't even consider doing it, so I was surprised that BofA appears to be doing just that. Then again, they probably have twenty times more ATMs than we do, so perhaps they have different issues to be considered. John Priscilla Oppenheimer 1/27/03 11:24:42 AM Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Prisiclla Amazing wrote: what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link t
RE: UDP port 1434 [7:61891]
One interesting assumption (underline assumption) is that BofA's service providers were partially sharing facilities between their private (ATM/FR) and public (Internet) networks. If that's the case, once the CPU on some of those shared routers/switches went to 100%, BofA's automatic teller machines are going to disappear. Paul Forbes Network Engineer Trimble -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 10:51 AM To: [EMAIL PROTECTED] Subject: Re: UDP port 1434 [7:61891] Maybe this is a silly question considering where I work, but is it common for huge banks to connect their ATMs to their data centers over the Internet? We certainly don't do that, and wouldn't even consider doing it, so I was surprised that BofA appears to be doing just that. Then again, they probably have twenty times more ATMs than we do, so perhaps they have different issues to be considered. John Priscilla Oppenheimer 1/27/03 11:24:42 AM Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61979t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
John Neiberger wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Maybe this is a silly question considering where I work, but is it common for huge banks to connect their ATMs to their data centers over the Internet? We certainly don't do that, and wouldn't even consider doing it, so I was surprised that BofA appears to be doing just that. Then again, they probably have twenty times more ATMs than we do, so perhaps they have different issues to be considered. Well, let's apply some logic and reason to what we know about the saphire work and the BOA situation. Saphire is launched from compromised Microsoft SQL servers. The attach consists of generating IP traffic using UDP port 1434. The traffic consists of the inquiries to what is described as pseudo random ip addresses, and the ICMP replies to the traffic inquiries. Knowing these things, we might guess that BOA, like many other businesses, has Microsoft SQL servers. 1) Could those servers have been compromised? sure 2) could those compromised servers have been involved in generting tons of traffic internal to BOA, even without the internet being involved? sure. 3) could routers on the internal BOA network, routers that carry IP trraffic, also be carrying other traffic such as would be carrying ATM transactions? sure. 4) recognizing that router overloads were happening everywhere as a result of saphire, is it reasonable to think that the BOA network routers could have been adversely effect, even if the internet were not involved? sure. 5) add to that what was happening on the internet. rogue SQL servers sending their attacks randomly, and some of that traffic hitting the BOA internet edge, and maybe being NAT'ed inside to add to traffic problems happening already. Look, when Nimda hit a year or so ago, some organizations just started turning things off in order to control what was happening. I seem to recall BOA did so, but to be frank, I am not certain of that. I don't think it is a good idea to jump to a lot of conclusions here. I highly doubt that even a stupid organization like Bank of America would be running their ATM's across the internet ( just kidding, pals of mine who work for BOA ) It is all too easy for corporate networks to come down in situations created by Nimda or saphire. in an earlier message, Ken spoke about his own network, where there are few if any Microsoft SQL servers. Yet their internet links were saturated because of the attacks, and internal network replies. The key to protecting networks is understanding the nature of the threat. BTW, there is a serious suggestion from someone on NANOG about denying any and all Microsoft well known ports across the internet backbone. good idea? I'm starting to think so. What I hope is that attacks based on ports 80 and / or 53 aren't developed. Thin how devastating those might be :-O John Priscilla Oppenheimer 1/27/03 11:24:42 AM Good points. How much bandwidth goes to some of the remote ATMs? Probably very little. They probably got crunched by the huge number of UDP packets. Of course, better filtering would have prevented that. But there's no need to assume that BoA runs MS-SQL or to worry that private info was compromised, etc. DoS attacks usually have very little to do with privacy compromises. Not claiming to be a security expert, so just correct me if I'm way off base! :-) Prisiclla Amazing wrote: what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL
RE: UDP port 1434 [7:61891]
Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61918t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Amen! We are not running any Windows SQL and are only running MySQL on Linux. Here is what we turned away at the front door in the past 12 hours on one 20MB connection: deny udp any any eq 1434 (205647 matches) Here is Cisco's link: http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml CERT and SANS also have info. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61922t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: UDP port 1434 [7:61891]
comments inline... Anyone have a link to a good technical document about the worm? Thanks, Priscilla Below is from bugtraq: SQL Sapphire Worm Analysis Release Date: 1/25/03 Severity: High Systems Affected: Microsoft SQL Server 2000 pre SP 2 Description: Late Friday, January 24, 2003 we became aware of a new SQL worm spreading quickly across various networks around the world. The worm is spreading using a buffer overflow to exploit a flaw in Microsoft SQL Server 2000. The SQL 2000 server flaw was discovered in July, 2002 by Next Generation Security Software Ltd. The buffer overflow exists because of the way SQL improperly handles data sent to its Microsoft SQL Monitor port. Attackers leveraging this vulnerability will be executing their code as SYSTEM, since Microsoft SQL Server 2000 runs with SYSTEM privileges. The worm works by generating pseudo-random IP addresses to try to infect with its payload. The worm payload does not contain any additional malicious content (in the form of backdoors etc.); however, because of the nature of the worm and the speed at which it attempts to re-infect systems, it can potentially create a denial-of-service attack against infected networks. We have been able to verify that multiple points of connectivity on the Internet have been bogged down since 9pm Pacific Standard Time. It should be noted that this worm is not the same as an earlier SQL worm that used the SA/nopassword SQL vulnerability as its spread vector. This is a new worm is more devastating as it is taking advantage of a software-specific flaw rather than a configuration error. We have already had many reports of smaller networks brought down due to the flood of data from the Sapphire Worm trying to re- infect new systems. Corrective Action We recommend that people immediately firewall SQL service ports at all of their gateways. The worm uses only UDP port 1434 (SQL Monitor Port) to spread itself to a new system; however, it is safe practice to filter all SQL traffic at all gateways. The following is a list of SQL server ports: ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp #Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m 1434/udp #Microsoft-SQL-Monitor Once again this worm is taking advantage of a known vulnerability that has had a patch available for many months. Microsoft has also released a recent service pack for SQL (Service Pack 3) that includes a fix for this vulnerability. Standalone patch: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-039.asp SQL 2000 Service Pack 3: http://www.microsoft.com/sql/downloads/2000/sp3.asp Previous SQL Service Pack versions are vulnerable. Technical Description The following is a quick run-down of what the worm's payload is doing after infection: 1. Retrieves the address of GetProcAddress and Loadlibrary from the IAT in sqlsort.dll. It snags the necessary library base addresses and function entry points as needed. 2. Calls gettickcount, and uses returned count as a pseudo-random seed 3. Creates a UDP socket 4. Performs a simple pseudo random number generation formula using the returned gettickcount value to generate an IP Address that will later be used as the target. 5. Send worm payload in a SQL Server Resolution Service request to the pseudo random target address, on port 1434 (UDP). 6. Return back to formula and continue generating new pseudo random addresses. push42B0C9DCh ; [RET] sqlsort.dll - jmp esp mov eax, 1010101h ; Reconstruct session, after the overflow the payload buffer ; get's corrupted during program execution but before the ; payload is executed. . xor ecx, ecx mov cl, 18h FIXUP: pusheax loopFIXUP xor eax, 5010101h pusheax mov ebp, esp pushecx push6C6C642Eh push32336C65h push6E72656Bh ; kernel32 pushecx push746E756Fh ; GetTickCount push436B6369h push54746547h mov cx, 6C6Ch pushecx push642E3233h ; ws2_32.dll push5F327377h mov cx, 7465h pushecx push6B636F73h ; socket mov cx, 6F74h pushecx push646E6573h ; sendto mov esi, 42AE1018h ; IAT from sqlsort lea eax, [ebp-2Ch] ; (ws2_32.dll) pusheax calldword ptr [esi] ; call loadlibrary pusheax
RE: UDP port 1434 [7:61891]
It deleted my post Here is the link again: http://www.eeye.com/html/Research/Flash/AL20030125.html Symon -Original Message- From: Symon Thurlow Sent: 26 January 2003 21:04 To: [EMAIL PROTECTED] Subject: RE: UDP port 1434 [7:61891] Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61925t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61928t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
We do have machines running flavors of MS-SQL on our network both in production and in classrooms/labs. These are the stats from about 8 A.M. on Saturday to 3:08 P.M. on Sunday for several of our access-lists. Keep in mind this is only from the two RSMs in one core 5500 and it's only internal traffic: deny udp any any eq 1434 (590511831 matches) deny udp any any eq 1434 (124971 matches) deny udp any any eq 1434 (43 matches) deny udp any any eq 1434 (18025943 matches) deny udp any any eq 1434 (642748443 matches) 1 RSM: Mercury-RSM4sh proc cpu CPU utilization for five seconds: 87%/64%; one minute: 84%; five minutes: 84% I put up a web page with graphs for those interested: http://www.csupomona.edu/~ken/website/sqlworm.html Almost all our backbone links are 100FX and most workstations connected at 10Mb/Half duplex. I wonder how bad it would be if they were GigE backbone links and 100TX workstation links. Amazing 01/26/03 01:20PM Amen! We are not running any Windows SQL and are only running MySQL on Linux. Here is what we turned away at the front door in the past 12 hours on one 20MB connection: deny udp any any eq 1434 (205647 matches) Here is Cisco's link: http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml CERT and SANS also have info. Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61930t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. some more detailed information may be found at http://www.techie.hopto.org/sqlworm.html Ken D's post is an interesting read as well. One means of stopping this kind of stuff is to filter at the edges everything except for those specific ports and services which are required and in use. unfortunately, due to the nature of TCP/UDP, and the lack of any hard requirements for vendors to register their port numbers, it can be difficult to identify what exactly is required in any business situation. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. there is a thread about this very topic on NANOG as well. http://www.merit.edu/mail.archives/nanog/msg06789.html titled Banc of America worth applying some logical though here. BOA's ATM network is effected by internet outages? Bright idea? or disinformation on the part of BOA? l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61932t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants l0stbyte wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... the dumb butts are allowing access to SQL from public networks. how difficult is it to filter stuff out? SQL boxes should be on private networks, no routes to public, second or third tier, etc. Y2K all over... This time in security business. Bunch of con artists claiming to be security experts. Cheers... P.S. There was a news clip that BofA networks were effected. this is scary. l0stbyte Symon Thurlow wrote: Cheers, Symon -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: 26 January 2003 20:02 To: [EMAIL PROTECTED] Subject: UDP port 1434 [7:61891] d tran wrote: You wouldn't have to fight the udp 1434 problem had you decided to scrap the shitty MS SQL server, running on crappy Windows machine and replace it MySQL (freeware) or real commercial database products like Oracle, running on Linux platform. Enjoy fighting udp1434. LOL DT I don't think that's true. He could have been a victim of other people running Windows SQL Server 2000. From what I understand about the worm, it not only repicated itself to other unpatched systems, but it send gazillions of packets to random IP addresses to port 1434. Many ISPs and companies were affected by it, not just the dumb butts who don't patch their systems. Here, we didn't seem to be affected by it, though. Maybe because I didn't check until Saturday afternoon? But no complaints came in. Are others willing to share their experiences? It could be a good learning opportunity. Anyone have a link to a good technical document about the worm? Thanks, Priscilla = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61934t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
While trying to modify the ACL's, I had to disable two trunks into that switch. I could telnet into the supervisor no problem. When I tried sess 4 or sess 7 I would get a timeout. I read reports of routers hanging under the load. This what I think happened to BofA. The routers probably couldn't handle the load of all that traffic. Maybe some hung and required manual intervention. IMHO, SQL wasn't their problem. High traffic levels was. I know I couldn't connect to my VPN and it took several tries with SSH to get into one of my Unix machines. How would I handle this type of problem in the future? Good question to which I'm not sure I have a good answer. We are replacing our core 5500's with 6500's. Our backbones from 100FX to GigE. Our Internet connection from OC-3 to GigE. Maybe the additional horsepower will help. Maybe it will hammer the servers so hard they crash and I can't do anything. In a way, I was taking a small risk with putting in firewall rules and ACLs to block this traffic. I'm working with people on campus to add firewall rules, but I may not do it without their permission. That and people are free to put anything they want on the network. If this were a corporate network and not an education network, I would convince the CIO/CTO/CEO that we need to tighten security. Here, I have to convince the technicians in each college and division that security is good. What would happen if this worm was a TCP port 80, TCP port 53 or UDP port 53 worm? Ken Amazing 01/26/03 06:15PM what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61938t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: UDP port 1434 [7:61891]
Ken Diliberto wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... While trying to modify the ACL's, I had to disable two trunks into that switch. I could telnet into the supervisor no problem. When I tried sess 4 or sess 7 I would get a timeout. I read reports of routers hanging under the load. This what I think happened to BofA. The routers probably couldn't handle the load of all that traffic. Maybe some hung and required manual intervention. IMHO, SQL wasn't their problem. High traffic levels was. I know I couldn't connect to my VPN and it took several tries with SSH to get into one of my Unix machines. How would I handle this type of problem in the future? Good question to which I'm not sure I have a good answer. We are replacing our core 5500's with 6500's. Our backbones from 100FX to GigE. Our Internet connection from OC-3 to GigE. Maybe the additional horsepower will help. Maybe it will hammer the servers so hard they crash and I can't do anything. In a way, I was taking a small risk with putting in firewall rules and ACLs to block this traffic. I'm working with people on campus to add firewall rules, but I may not do it without their permission. That and people are free to put anything they want on the network. If this were a corporate network and not an education network, I would convince the CIO/CTO/CEO that we need to tighten security. Here, I have to convince the technicians in each college and division that security is good. good points all. how quickly we forget - a year or so ago, it was code red / nimda, and the response of a lot of places was to just start shutting down servers and routers until they could get a handle on things. BOA might even have been one of those organizations that did so, but that could be my prejudice speaking. What would happen if this worm was a TCP port 80, TCP port 53 or UDP port 53 worm? no problem. just close those ports on your firewalls ;- Ken Amazing 01/26/03 06:15PM what's amazing are the assumptions that people are making--who says tht BoA servers or any BoA database were comprimised? who says they are even running MS-SQL? Read how the worm is spreading and you will understand that you dont have to be running anything that can be affected by the worm. my guess is that a company with LARGE blocks of routable addresses and probably very high speed connections to the Internet might have bigger problems with this worm which in effect becomes a denial of service attack on their edge devices even if they are filtering out udp 1494 at the edge. take a look at the post by Ken and observe what is happening to the CPU of one of his router blades. i definitely agree with your comment about the security con artist comparison the y2k consultants [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=61940t=61891 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
