Fred Flintstone, we'd like to help...
Some of you are going to read this and think that I'm making a joke about trying to contact the stone age... Unfortunately no.
We have an ISC reader who has submitted some great logs, asking for analysis, unsure of what is really going on, who calls (him|her)self 'Fred Flintstone'. Which is fine. We don't mind anonymity. However, when Fred doesn't leave an email address, and asks us to contact him with any help we can provide, we can't do it.
So, that being said. Fred, if you are out there... email us and provide us your email, we'll promise we'll not tell Mr. Slate.
----------------
Joel Esler
jesler{at}isc.sans.org
We have an ISC reader who has submitted some great logs, asking for analysis, unsure of what is really going on, who calls (him|her)self 'Fred Flintstone'. Which is fine. We don't mind anonymity. However, when Fred doesn't leave an email address, and asks us to contact him with any help we can provide, we can't do it.
So, that being said. Fred, if you are out there... email us and provide us your email, we'll promise we'll not tell Mr. Slate.
Update
Thank you Fred for writing in and giving us your email address so that we can respond.----------------
Joel Esler
jesler{at}isc.sans.org
Keywords:
0 comment(s)
Cogent having problems... RESOLVED
We have received a report of the Cogent Data Center in Herndon, VA having connectivity problems. It appears to be localized. No need to innundate them with phone calls, I am sure they are working on it.
One of our readers, Colin, called into the data center: "I called their support staff and got through to a guy who described the situation as a network problem 'affecting all traffic in their data center'."
More on this situation if more develops...
Update #2
It seems like the Cogent outage was just some scheduled maintenance that they were performing on some of their fiber links. The problem has been resolved.
----------------
Joel Esler
jesler{at}isc.sans.org
One of our readers, Colin, called into the data center: "I called their support staff and got through to a guy who described the situation as a network problem 'affecting all traffic in their data center'."
More on this situation if more develops...
Update #1
It appears that sometime on Wednesday that the problems were more widespread, as they had some latency problems up in New York as well, as reported by another reader. However it appears that the problems had been resolved as of Thursday. No report yet on if the problem at the Herndon, Virginia office has been resolved.Update #2
It seems like the Cogent outage was just some scheduled maintenance that they were performing on some of their fiber links. The problem has been resolved.----------------
Joel Esler
jesler{at}isc.sans.org
Keywords:
0 comment(s)
CA eTrust Antivirus [was] flagging lsass.e x e
Reader Alan writes in to tell us that apparently "an overnight signature update to the VET engine (30.3.3054) on CA eTrust Antivirus has begun to flag the LSASS.E X E service of Windows 2003 server as being infected with Win32/Lassrv.B."
"Some Win2k3 servers have been failing and unable to re-boot, since the service (exe) was removed by the virus software.
CA has released an update to VET (30.3.3056) that seems to have corrected the problem, but in some cases the damage has already been done."
It seems that CA accidentally flagged Lsass.e x e as a bad file. Reminiscent of the McAfee .xls debacle of not too long ago.
Updates:
----------------
Joel Esler
jesler{at}isc.sans.org
0 comment(s)
"Some Win2k3 servers have been failing and unable to re-boot, since the service (exe) was removed by the virus software.
CA has released an update to VET (30.3.3056) that seems to have corrected the problem, but in some cases the damage has already been done."
It seems that CA accidentally flagged Lsass.e x e as a bad file. Reminiscent of the McAfee .xls debacle of not too long ago.
Updates:
- Mark Wade from CA wrote in with the link to the information CA is having publicly for this on their support site.
- One of our regular readers pointed us to the technet blog on SBS for more recovery information.
----------------
Joel Esler
jesler{at}isc.sans.org
MS06-040 Worm[s]
For the past several days, the Handlers here at ISC have received all kinds of emails about the recent increase in scanning on port 139, as noted by fellow handler Lorna, the other day, yes there was definitely something going on, but we haven't seen any c0de.
Well, guess what. One of loyal readers out there on the 'Information SuperHighway', Alex Pettinger, wrote and and gave us some netstat and fport outputs from one of his machines that seemed to be affected by the worm, (as well as a nice copy of it). It appears, in typical antivirus fashion to be named several things: McAfee is calling it "W32/SDbot.worm!MS06-040", Sophos is calling it, "W32/Vanebot-A", and Symantec is calling it, "W32.Randex.GEL". (Yes, it's been out for a couple days)
Let's take a look at this bad boy shall we? How does it spread.. well, it uses: MS04-007, MS05-017, MS05-039, and of course, our favorite bug of the moment, MS06-040.
This one should be relatively easy to catch, look for machines pounding away over port 139 (from reader submissions it's about 150 machines in just a few seconds, so it should be noisy), look for connections via IRC to "forum.ednet.es" over port 4915. (Until the next variant changes it, and we know it will). It has the ability to do a bunch of things including spreading to network shares..
Prevention, as always, (and it should have been done for years now), block 139 and 445 at the router/firewall. Netbios traffic shouldn't be allowed to exit or enter your network from egress points anyway.
Update your antivirus. At least daily.
Patch. You know the deal by now.
Now, since cleaning botnets, is.. pretty much impossible, prevention is the key. If you DO get hit with a botnet infection running throughout your network, my general recommendation is.. rebuild the box. Now, I know that sounds drastic to some of you, but it gets rid of the worm, gets rid of the botnet, and plus you have a brand new box! So, maintain those images, keep your antivirus up to date, patch your boxes, and make sure your IDS/IPS is up to date.
Cory, one of our ever vigilant readers, notified us that the link to 06-040 was incorrect. Thanks Cory. It has been fixed.
Patch those machines, update that antivirus, make sure your firewall is blocking as much as possible, and make sure your IDS/IPS that is on your network is running the latest ruleset.
Update #3
Eric tells us:
"Some of [the worms] attack 445/tcp while others attack 139/tcp. One thing that we have noticed is that some of these variants do slow scans of the B-Class network that they infect as opposed to the more traditional massive, or what I like to call "puke scans", of the B class range. This has made then more difficult to detect and we've had to engineer a some new detection methods."
Have a good weekend everyone!
0 comment(s)
Well, guess what. One of loyal readers out there on the 'Information SuperHighway', Alex Pettinger, wrote and and gave us some netstat and fport outputs from one of his machines that seemed to be affected by the worm, (as well as a nice copy of it). It appears, in typical antivirus fashion to be named several things: McAfee is calling it "W32/SDbot.worm!MS06-040", Sophos is calling it, "W32/Vanebot-A", and Symantec is calling it, "W32.Randex.GEL". (Yes, it's been out for a couple days)
Let's take a look at this bad boy shall we? How does it spread.. well, it uses: MS04-007, MS05-017, MS05-039, and of course, our favorite bug of the moment, MS06-040.
This one should be relatively easy to catch, look for machines pounding away over port 139 (from reader submissions it's about 150 machines in just a few seconds, so it should be noisy), look for connections via IRC to "forum.ednet.es" over port 4915. (Until the next variant changes it, and we know it will). It has the ability to do a bunch of things including spreading to network shares..
Prevention, as always, (and it should have been done for years now), block 139 and 445 at the router/firewall. Netbios traffic shouldn't be allowed to exit or enter your network from egress points anyway.
Update your antivirus. At least daily.
Patch. You know the deal by now.
Now, since cleaning botnets, is.. pretty much impossible, prevention is the key. If you DO get hit with a botnet infection running throughout your network, my general recommendation is.. rebuild the box. Now, I know that sounds drastic to some of you, but it gets rid of the worm, gets rid of the botnet, and plus you have a brand new box! So, maintain those images, keep your antivirus up to date, patch your boxes, and make sure your IDS/IPS is up to date.
Cory, one of our ever vigilant readers, notified us that the link to 06-040 was incorrect. Thanks Cory. It has been fixed.
Update #2
Since I wrote this article I've read many reports on Symantec and other sites that talk about worms and exploits using MS06-040 in their code, so, we're not going to list them all here, but be aware, they are out there! Most of the worm/c0de that I have seen have their machines connecting back to a botnet on IRC somewhere. Apparently that's the thing to do for hackers now-a-days, integrate code into worm, attach botnet c0de, and away you go compromising machines.Patch those machines, update that antivirus, make sure your firewall is blocking as much as possible, and make sure your IDS/IPS that is on your network is running the latest ruleset.
Update #3
Eric tells us:"Some of [the worms] attack 445/tcp while others attack 139/tcp. One thing that we have noticed is that some of these variants do slow scans of the B-Class network that they infect as opposed to the more traditional massive, or what I like to call "puke scans", of the B class range. This has made then more difficult to detect and we've had to engineer a some new detection methods."
Final Update
We've been following this most recent outcropping of scanning. We'd like to thank all the people that submitted c0de to us, worms, firewall logs, packets, etc.. Thank you. It's what we needed. So that being said, I'm going to close out the story for us unless something new crops up. These worms have been out for awhile now, and hopefully we've given enough light on them. The general patch, update, and block stuff applies. There are ways to catch and prevent the worm with your Snort box if you are running the VRT ruleset with the most updated netbios.rules file, so make sure your ruleset is up-to-date.Have a good weekend everyone!
Tip of the Day: Audit
As the last in the series of tips of the day, I chose the subject Audit.
Audits might sound scary as they verify your work, but they really should not. They can be a great tool into doing the right thing and catching (and correcting) errors before they escalate and become a problem. As a matter of fact, you can audit your own work. Or do it in a team. We all know we cannot find errors in stuff we wrote ourselves while it's obvious if somebody else wrote it.
Typically this starts with regulatory and legal requirements, but it can check compliance with standards as well.
As soon as you know what to look for, you can automate it in less time than you do it manually once.
So that leaves?
--
Swa Frantzen -- Section 66
Audits might sound scary as they verify your work, but they really should not. They can be a great tool into doing the right thing and catching (and correcting) errors before they escalate and become a problem. As a matter of fact, you can audit your own work. Or do it in a team. We all know we cannot find errors in stuff we wrote ourselves while it's obvious if somebody else wrote it.
Audit yourself/co-worker
You can do various audits yourself of your work:- Are backups actually able to be read?
- Can we actually restore a backup from a system if we loose all the harddisks or are we missing information?
- Are the dates/sizes of system files on all our computers still the same (poor man HIDS, but it can also detect failed patches etc.)
- Do logs from all our systems actually end up in our central log repository?
- Did managment acknowledge all incident reports you gave them? Where there changes implemented due to the incidents?
- Do we have blocklists? Do we update them regularly? Did we check if they are still relevant?
- Exposed scripts (such as e.g. cgi-bin perl scritps)? Who reviewed them for security? Where they changed afterwards?
- Is everything you do documented, can co-workers understand it and take over your tasks?
- ...
Internal Audits
Internal audits can go further:- Are all our users in our user database(s) still rightfully there? Does the list match with what e.g. HR has as list of employees/contractors? Are the other users interactively used? Are they regularly re-confirmed as needed users? Do we have users that never log in?
- Can we actually start a Disaster Recovery without touching the existing equipment and information?
- Do people inside the company know where to find security policies? Do they know key content of the policies? When were they last reminded of the password policy? Are all our policies easy to read? Are all our policies short enough to be read in under 5 minutes?
- Is equipement we rely on for being warned about problems (availability, IDS, logs, ...) actually tested regularly? How are we sure?
- Are policies overruled? Why? By who? How often? Was it investigated? Did the policy change afterwards to fix the problem?
- Where are incidents logged? What were the conclusions? Do people know incidents that were not logged?
- If you need to find more cool audit ideas, check ISO27001 (or ISO17799) it has a bunch of ideas that you can test to see if you have it or not. Without a policy or guideline to get it, this isn't a real audit check as in must have, but it's always good to look for some extra credit to go beyond the minimum what is implied by the policies.
- Is the inventory complete? Are network diagrams up to date?
- Is every thing labeled? Do machines with possibly confusing port have labels added to identify the ports? Are cables labeled on both ends with both sides of that they connect?
- Are logbooks used and filled out? Or are they filled out just before the audit?
- ...
External Audits
Well external audits generally should check the same stuff as the Internal audits do, but be independent. Sill they are valuable as they can give you the ultimate magic bullet: management support.Typically this starts with regulatory and legal requirements, but it can check compliance with standards as well.
- Can grant a seal of approval.
- These audits can also audit those persons that are very hard to audit as an employee: the big chief: does (s)he feel the policies do not apply to him/herself?
- ...
- First of all: logs are huge. You do not want them to schrink in size.
- Computers are pretty good at finding things in large amounts of data - if you can tell them what to look for.
- The "what to look for" however is lacking in the "review logs" assignment
As soon as you know what to look for, you can automate it in less time than you do it manually once.
So that leaves?
- Create logs, the more the better, they might be the only trace you have of an incident.
- Do NOT review it manually, it is pointless.
- Automatically look through them
- for known problems (you learn them from past incidents).
- for never seen before entries using e.g. Marcus Ranum's nbs (never before seen) script/db so when something absolutely new occurred you get a chance to consider it interesting enough to treat as an incident or not.
- Keep them for the right amount of time
- Look through them for evidence and further understanding once you have an incident to deal with.
--
Swa Frantzen -- Section 66
Keywords: ToD
0 comment(s)
Out Share! Now it's up to you.
Well August is done.
We had a bunch of Tip of the Day diary entries. It was fun. And looking back on the responses so far our readers liked it. But let's go back to the beginning, and read the goal of it all once again. In one sentence:
So no, this is not the end of the tips. However it's up to you now. We will collect your tips and post them on slower days to share with all other readers.
We have an overview of all "Tips of the Day" published in August. Enjoy!
To submit your tips to success, use the contact page.
We had a bunch of Tip of the Day diary entries. It was fun. And looking back on the responses so far our readers liked it. But let's go back to the beginning, and read the goal of it all once again. In one sentence:
It's a race, to win you must share.
So no, this is not the end of the tips. However it's up to you now. We will collect your tips and post them on slower days to share with all other readers.
We have an overview of all "Tips of the Day" published in August. Enjoy!
To submit your tips to success, use the contact page.
Keywords: ToD
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments