Or is this the first actual case because they suspected before there were actual bugs in the system but never found them?
This was the first computer bug, but not the first engineering bug. A "bug" has always been a problem, whether blamed on demons or by errors on the part of the engineer. So what they're saying is that, although we've used the term "bug" for some time, this is the first time it's actually a physical insect.
However, for AOL and Earthlink to blacklist you based on false 'From:' entries is just stupid
Amen. The way I'd configure it:
Get a virus scanner, set to auto-update
Scan all incoming emails
When a server passes a certain threshold of incoming, virus-laden emails, block it
When a netblock passes a certain threshold of blocked hosts, block the netblock. This should block the ISP's mail server if their customers are sending out directly due to the virus.
After a specific amount of time, but hosts and netblocks into a greylist. When you're on the greylist, one offence gets you back into the blacklist.
After a specific amount of time on the greylist, remove them from the blocks entirely
Preferably one who knows how to read the headers in a bounce message. This
includes the "Received" lines in the original message, which should show that
none of them came from your domain. A little bit of due process before
shutting you down wouldn't hurt, either.
Re:This is why ISPs are changing their SMTP rules?
on
P2P Spam?
·
· Score: 1
No. The ISPs block outgoing SMTP except from their servers. The only place you can send to is the ISP or to any other SMTP server that may exist on your subnet.
plus maybe 30 automated msgs saying _I'd_ sent out such nastiness/bloat.
I was getting that, too. I think it generates the return address the same way it sends the to: address. They both come from the user's address book. Because of this, other people get the warnings, not the person who's actually infected. This allows the virus to go undetected longer.
Yes, and the netadmins should have known about it. According to the article, only some of them did. And, since they knew about it, they should have firewalled it. Your contractors probably don't need RPC access to your machines. Determine what they require, and limit accordingly.
A big flashing red light, a siren or two, or something similar would also do this.
The problem with this approach is that monitors have to pass a threshold to trigger them, requiring re-active responses. With a graphical display, you can see that something is odd (but not odd enough to trigger the alarms), so you have time for a pro-active response.
I do agree with you about the level of GUI requirement, though. Heck, even a couple of ASCII bars gives the information you need.
Yes, that's what happened. However, why did the contractor have a non-firewalled connection? From the SecurityFocus article:
"This is in essence a backdoor from the Internet to the Corporate internal network that was not monitored by Corporate personnel," reads the April NRC filing by FirstEnergy's Dale Wuokko. "
[S]ome people in Corporate's Network Services department were aware of this T1 connection and some were not."
(emphasis mine) Why were the network services people not informed of this potential (and eventually actual) security breach?
I did read the article. It was an indirect internet exposure.
The contractor was exposed to the internet. The plant was exposed to the contractor via a non-firewalled T1 line. The safety network was exposed (presumably) to the plant's office. Three layers of indirection, but still internet exposure.
An infected laptop on the network is an indirect internet connection.
The infection came in on a non-firewalled T1 line to a contractor's office. Very few people knew about the existance of this line.
Why should the office network be connected to the secure network? If necessary, allow a limited connection (a single machine, connected to both networks, does not pass packets through, but compiles information to display), or have a completely separate, locked-down workstation where the statistics can be seen.
I have to disagree with you here. You need a graphical display of the measurements, otherwise it's just so many numbers. If you are watching a screen filled with numbers, it's easy to miss the distinction between, say, 10 and 70; depending on the meaning of these numbers, it could mean the difference between life and death.
With a graphic, you can quickly see that something isn't right. Normally, all the bars are low, but now they're filling the screen. Something's wrong. This is the same way analog gauges work - when the needle points right (or left, depending on the system), you need to fix something.
Urk...NO! Do not use a system that is untested and unlicensed for nuclear facilities. Use a fail-safe, real-time operating system, such as QNX, which is certifiable for these systems.
Then why was the safety monitoring system exposed to the office network? In this case, the worm came in on a non-firewalled T-1 line from a contractor's network, and through there to the internet.
I would have suspected that there would be multiple layers of protection in front of critical systems like that. Even more, I would expect that safety regulations require these layers of protection. Of course, that would hurt the bottom line, so we can't have that happening:(
That brings up a good question. Doesn't software need to be certified before it can be used in nuclear applications? In fact, isn't one of the (many) disclaimers on most software (including Windows) "don't use this in a nuclear facility"?
Slashdot Mirror
The average investor only sees one side of this story. We need more coverage of our side.
Sorry to reply to myself, but here's a link to the history of the term 'bug'.
Right after Usenet, *BSD, Stephen King, etc.
Then how will legitimate mail arrive?
How will this help? The bouncing servers will look up the new MX record, and send to the new address.
BTW, this is generally known as a Joe Job.
No. The ISPs block outgoing SMTP except from their servers. The only place you can send to is the ISP or to any other SMTP server that may exist on your subnet.
Minimum access - basic security
Thanks for clearing that up. Too bad the media tends not to report the full truth, because it isn't sensational enough.
I do agree with you about the level of GUI requirement, though. Heck, even a couple of ASCII bars gives the information you need.
The contractor was exposed to the internet. The plant was exposed to the contractor via a non-firewalled T1 line. The safety network was exposed (presumably) to the plant's office. Three layers of indirection, but still internet exposure.
Two points:
- An infected laptop on the network is an indirect internet connection.
- The infection came in on a non-firewalled T1 line to a contractor's office. Very few people knew about the existance of this line.
Why should the office network be connected to the secure network? If necessary, allow a limited connection (a single machine, connected to both networks, does not pass packets through, but compiles information to display), or have a completely separate, locked-down workstation where the statistics can be seen.Read the article - it was an unfirewalled back door to a contractor, that nobody knew about.
With a graphic, you can quickly see that something isn't right. Normally, all the bars are low, but now they're filling the screen. Something's wrong. This is the same way analog gauges work - when the needle points right (or left, depending on the system), you need to fix something.
I would have suspected that there would be multiple layers of protection in front of critical systems like that. Even more, I would expect that safety regulations require these layers of protection. Of course, that would hurt the bottom line, so we can't have that happening :(
That brings up a good question. Doesn't software need to be certified before it can be used in nuclear applications? In fact, isn't one of the (many) disclaimers on most software (including Windows) "don't use this in a nuclear facility"?
...should be fired. Why was the safety monitoring system on a nuclear power plant exposed, even indirectly, to the internet?