When my new machine arrives, I'm putting the old workstation/Linux box off the switch as a honeypot. Here's the idea: Since this is a switch, I'll just hang it off directly
It will have a different IP block range from the other internal LAN machines
The router machine (running *bsd) will be changed so the input rules redirect everything except a couple of services (DNS and SMTP) to the honeypot box
Other ipfw rules will drop any packets from that box to any other internal machine (ie, don't kill my soft internal machines)
Finally, If I'm really mean, I'll deny all SYN packets to "well known TCP scanning targets" so that scanning is tougher.
The goal is to record everything going to the honeypot machine.. unpublished exploits suddenly make their way unto Bugtraq, certain file caches get exposed and looted, other compromised systems are revealed.
Plus it's nice wholesome fun for the whole family! grin
According to the article, there are about 6 known Linux viruses. At least one of these used root-exploits to run as a user. Currently, the level of expertise in these viruses isn't that high.
Secondly, the author doesn't mention FreeBSD because some things about those trees make it a lot harder -- the security levels making system files unchangeable (ie, you have to boot into single-user mode to change your kernel, and forget about loading any modules!), and furthermore, FreeBSD doesn't have a snowball's chance in hell of being a desktop operating system.
As Linux becomes a "desktop operating system", the slim levels of protection against computer viruses vanishes. There is no longer a seperate God-like admin who greps the source for system(), and doesn't install binaries. Instead, there's a harried user who has to put on the 'root' hat. For the history buff's, what operating system did Fred Cohen write the first computer virus on, and demonstrate their success? Just a hint -- it was before Windows and it wasn't VMS...
Further, because Linux now has a number of binary package-managers, with commercial software released binary only, it's relatively easy for both viruses and worms to spread. Even when you have to build your programs from source on each architecture, you can have viruses and worms (think Morris Worm, for example).
I disagree with the author on why this hasn't happened yet -- right now, Linux is "counter-culture" - people who have the skills to write viruses for it are having fun playing with the kernel. When Linux has a significant share of the public market, it will no longer be a hobbyists toy, but the product of the Redhat-Caldera-Suse (or some other combination) corporation. At that point, it will become a target instead of a toy.
Further, the solution is NOT anti-virus software in the Windows sense -- the solution is likely to be more technical, including access right lists (what do you mean, my 'ls' is trying to exec() something? Or my binary mozilla package is trying to write to some other program file? ) The operating system can and SHOULD enforce sensible limits.
What this means is that 'root' isn't going to be 'root' anymore. And that's a good thing.. I want a installation process to install certain binary files, not send my video card information (quake3) or my credit card information to some server, or add blank entries to/etc/passwd, or otherwise wreck havoc. If you've read this far, thank you for listening to me rant.
Even if you have BO on an NT box, it is non-trivial to generate the same type of packets you can trivially create with Linux or Solaris.
Furthermore, Redhat and Solaris have been very vulnerable to a number of security issues, compounded by novice system administrators.
Just like in the results of benchmarks, instead of railing against this "it could happen to any *nix") the community needs to accept that these two variants are particularly vulnerable.
It is also true that there are only versions of at least one of the flooding tools for Linux and Solaris for the above reasons.
While detection tools can help, it appears that there are many more unskilled and untrained administrators than there are ones who actively secure their machines.
This appears to be the underlying program, that large numbers of vulnerable machines are available for attackers.
From history, it seems that legislation has at best a mediocre track record, and in this case it would be tantamount to legislating intelligence on the part of system administrators (requiring an Internet Server License?)
And finally, while these first tools are primitive, it seems that one could make drastic steps in improving the efficiency and stealthiness (including commands like "kill target at some time and forward this message to other known hosts"), as well as improved attacks.
So, what can we as competent administrators do about the vast ranges of unsecured potential attackers?
A netscan-esque or UDP style blacklist of vulnerable subnets?
Active defense when these attacks occur, mindful of future attacks which might be indistinguishable from normal traffic?
My understanding of these attacks is that it is the "tribal flood" networks, as documented in Bugtraq.
Note that the protocols used to communicate with these slaves is *known*, how to detect these slaves is public knowledge, and most of them use hardcoded passwords, and *all* of them use known exploits.
With the increase in penalties for computer intrusion, there is no longer anyone to go in and lock the doors afterwards. If someone of enough maturity to understand the risk were to do so, they would easily be prosecuted for the sum of all damages
Meanwhile, a small group of mostly minors can use these systems and make national news (and the front page of some local newspapers! - How is *that* for never leaving your computer?)
This is excaberated by Redhat's marketting driven policy of "expose every daemon", Sun admins with the intelligence of sea monkeys (and the constant bugs which are found again and again).
I think that it would be MORAL, although not legal, for those priviledged to live in a "free" country, to do massive scans and penetrate systems with each new security hole. At which point, they would leave a message on console, and apply the patch, probably in an automated fashion. The presence of networks of rogue hosts on the net is damaging to everyone.
Well said, but a few years too late.:-) Originally intel (for the P2's) used 3rd parties to produce the cache chips for the cartridges, and you could open 'em up and see how fast your cache was and overclock accordingly.
However, with cache on-die you get the benefits of your process technology in making the cache, which is cheaper (relatively) and faster. Unfortunately, on-die cache is larger wafer size, which is more expensive -- if one bit of the cache tests bad, you lose the whole chip in that space, unless you can disable the L2 and sell it as the "value" product.
I see an immense difference here between two LARGE multinational companies who are competing in a very expensive space to the grassroots development of the Linux operating system
AMD is not "david", and they are pulling tricks right out of Intel's playbook (suing overclockers, for example).
When AMD releases it's chip design tools, and the vhdl-level code for the Athlon, *then* you might have reason to compare them with free-as-in-speech software.
I feel it more appropriate to think of AMD & Intel as Coke and Pepsi. You figure out the similarities.
I think that it was DELL that smacked intel good a couple months back with their power cycling tests.
DELL seems to be one of the few computer makers doing their own testing of components and the systems.
My conclusion is that unlike what theregister supposes, that DELL is not an intel front, but rather just trying to maintain a reputation for reliability.
I can speculate on why AMD won't be doing a dual chipset -- because the complexity and expense is out of proportion.
Check out Intel's errata documents, and notice how many problems only exist with multiple processors, or with the communications between processors.
Not supporting multiprocessor is CHEAP! With Intel and Celerons, we've gotten the benefits of a tested multiprocessor core at a cheap price -- don't expect AMD to make the same mistake
Even with the chipset doing most of the "work" in the AMD design, I'd be surprised if you could do SMP with your existing Athlons.
(A) hypocritical in the light of the abuse of copyright permissions on music and software, among other intellectual properties advocated in these forums
(B) nearly pointless considering the low value of most of the content posted.
I fail to see any moral or ethical reason for any individual to have all rights to what they say -- if you do not wish what you have in your head to be heard, repeated, folded, spindled and mutilated, DON'T SAY IT
While the legal side has been bought for certain blessed forms of expressions, I doubt many posters here have enough disposable income to buy the required protections for their postings.
Slashdot Mirror
Here's the idea:
Since this is a switch, I'll just hang it off directly
It will have a different IP block range from the other internal LAN machines
The router machine (running *bsd) will be changed so the input rules redirect everything except a couple of services (DNS and SMTP) to the honeypot box
Other ipfw rules will drop any packets from that box to any other internal machine (ie, don't kill my soft internal machines)
Finally, If I'm really mean, I'll deny all SYN packets to "well known TCP scanning targets" so that scanning is tougher.
The goal is to record everything going to the honeypot machine.. unpublished exploits suddenly make their way unto Bugtraq, certain file caches get exposed and looted, other compromised systems are revealed.
Plus it's nice wholesome fun for the whole family! grin
According to the article, there are about 6 known Linux viruses. At least one of these used root-exploits to run as a user. Currently, the level of expertise in these viruses isn't that high.
Secondly, the author doesn't mention FreeBSD because some things about those trees make it a lot harder -- the security levels making system files unchangeable (ie, you have to boot into single-user mode to change your kernel, and forget about loading any modules!), and furthermore, FreeBSD doesn't have a snowball's chance in hell of being a desktop operating system.
As Linux becomes a "desktop operating system", the slim levels of protection against computer viruses vanishes. There is no longer a seperate God-like admin who greps the source for system(), and doesn't install binaries. Instead, there's a harried user who has to put on the 'root' hat. For the history buff's, what operating system did Fred Cohen write the first computer virus on, and demonstrate their success? Just a hint -- it was before Windows and it wasn't VMS ...
Further, because Linux now has a number of binary package-managers, with commercial software released binary only, it's relatively easy for both viruses and worms to spread. Even when you have to build your programs from source on each architecture, you can have viruses and worms (think Morris Worm, for example).
I disagree with the author on why this hasn't happened yet -- right now, Linux is "counter-culture" - people who have the skills to write viruses for it are having fun playing with the kernel. When Linux has a significant share of the public market, it will no longer be a hobbyists toy, but the product of the Redhat-Caldera-Suse (or some other combination) corporation. At that point, it will become a target instead of a toy.
Further, the solution is NOT anti-virus software in the Windows sense -- the solution is likely to be more technical, including access right lists (what do you mean, my 'ls' is trying to exec() something? Or my binary mozilla package is trying to write to some other program file? ) The operating system can and SHOULD enforce sensible limits.
What this means is that 'root' isn't going to be 'root' anymore. And that's a good thing.. I want a installation process to install certain binary files, not send my video card information (quake3) or my credit card information to some server, or add blank entries to /etc/passwd, or otherwise wreck havoc. If you've read this far, thank you for listening to me rant.
Furthermore, Redhat and Solaris have been very vulnerable to a number of security issues, compounded by novice system administrators.
Just like in the results of benchmarks, instead of railing against this "it could happen to any *nix") the community needs to accept that these two variants are particularly vulnerable.
It is also true that there are only versions of at least one of the flooding tools for Linux and Solaris for the above reasons.
This appears to be the underlying program, that large numbers of vulnerable machines are available for attackers.
From history, it seems that legislation has at best a mediocre track record, and in this case it would be tantamount to legislating intelligence on the part of system administrators (requiring an Internet Server License?)
And finally, while these first tools are primitive, it seems that one could make drastic steps in improving the efficiency and stealthiness (including commands like "kill target at some time and forward this message to other known hosts"), as well as improved attacks.
So, what can we as competent administrators do about the vast ranges of unsecured potential attackers?
A netscan-esque or UDP style blacklist of vulnerable subnets?
Active defense when these attacks occur, mindful of future attacks which might be indistinguishable from normal traffic?
Requiring government licensing of all servers?
Note that the protocols used to communicate with these slaves is *known*, how to detect these slaves is public knowledge, and most of them use hardcoded passwords, and *all* of them use known exploits.
With the increase in penalties for computer intrusion, there is no longer anyone to go in and lock the doors afterwards. If someone of enough maturity to understand the risk were to do so, they would easily be prosecuted for the sum of all damages
Meanwhile, a small group of mostly minors can use these systems and make national news (and the front page of some local newspapers! - How is *that* for never leaving your computer?)
This is excaberated by Redhat's marketting driven policy of "expose every daemon", Sun admins with the intelligence of sea monkeys (and the constant bugs which are found again and again).
I think that it would be MORAL, although not legal, for those priviledged to live in a "free" country, to do massive scans and penetrate systems with each new security hole. At which point, they would leave a message on console, and apply the patch, probably in an automated fashion. The presence of networks of rogue hosts on the net is damaging to everyone.
Originally intel (for the P2's) used 3rd parties to produce the cache chips for the cartridges, and you could open 'em up and see how fast your cache was and overclock accordingly.
However, with cache on-die you get the benefits of your process technology in making the cache, which is cheaper (relatively) and faster. Unfortunately, on-die cache is larger wafer size, which is more expensive -- if one bit of the cache tests bad, you lose the whole chip in that space, unless you can disable the L2 and sell it as the "value" product.
I see an immense difference here between two LARGE multinational companies who are competing in a very expensive space to the grassroots development of the Linux operating system
AMD is not "david", and they are pulling tricks right out of Intel's playbook (suing overclockers, for example).
When AMD releases it's chip design tools, and the vhdl-level code for the Athlon, *then* you might have reason to compare them with free-as-in-speech software.
I feel it more appropriate to think of AMD & Intel as Coke and Pepsi. You figure out the similarities.
DELL seems to be one of the few computer makers doing their own testing of components and the systems.
My conclusion is that unlike what theregister supposes, that DELL is not an intel front, but rather just trying to maintain a reputation for reliability.
Check out Intel's errata documents, and notice how many problems only exist with multiple processors, or with the communications between processors.
Not supporting multiprocessor is CHEAP! With Intel and Celerons, we've gotten the benefits of a tested multiprocessor core at a cheap price -- don't expect AMD to make the same mistake
Even with the chipset doing most of the "work" in the AMD design, I'd be surprised if you could do SMP with your existing Athlons.
(A) hypocritical in the light of the abuse of copyright permissions on music and software, among other intellectual properties advocated in these forums
(B) nearly pointless considering the low value of most of the content posted.
I fail to see any moral or ethical reason for any individual to have all rights to what they say -- if you do not wish what you have in your head to be heard, repeated, folded, spindled and mutilated, DON'T SAY IT
While the legal side has been bought for certain blessed forms of expressions, I doubt many posters here have enough disposable income to buy the required protections for their postings.