Why would anyone ever do this? "Excessive noise"? Oh, you mean more orders? Last time I checked, more entries in the database never hurt anyone (not like every user is going to create duplicate accounts to the point where you're running out of resources, user records are tiny anyhow). Writing some 'intelligent' algorithm to detect duplicate accounts will invariably lead to marking legitimately separate user's accounts as duplicates and eliminating business.
Yes yes, it is rather stupid for it to be "My Computer" or "Computer" at all, after all, it's just a Directory of part of the computer, it isn't representative of the computer as a whole at all. It should be something like "Browse Files" to eliminate all the stupid communications problems this creates.
The problem with having just one really strong password is that in the event that someone managages to get that one password (always plan security around how things might fail, not how they should work), its strength no longer matters and you're in the same position as having just one weak password for everything.
Someone could use a mechanism to get your one password that totally bypasses its strength againt cracking/guessing. For example, and this is rather common, someone could trojan an sshd, httpd, or smtpd server by either modifying it or replacing it with a version that just grabs your password when you enter it and store it. They can then take that password and use it for all of your other accounts, and do tons of damage to you before you have a chance to change your password everywhere.
Regarding "change your password every 30 days" systems - these are useful incase someone gets your password and you don't know, they can only use it for 30 days max (avg of 15) before the password is bunk. This also helps in the event that someone gets an encrypted or hashed copy of your password, say from a UNIX's/etc/shadow; gives them less time to crack the password before it expires.
Ah, but I wasn't talking about stopping the email with profanity in it, I was talking about stopping the email with sensitive internal information that doesn't contain any profanity and has to be read by a human being with a sense for what is sensitive and what isn't before it is sent out.
The wrong paragraph regarding the status of a project or feelings about a client getting out can damage a business a lot more in the long term than a childish "fuck you" or something.
interesting story, but how would email monitoring help with this? The email would have been sent anyhow, and would have ended up in some pile of hundreds of other emails to be checked over?
Only thing that would have stopped this is if all outbound mail had to be read by a human monitor before leaving the company, which could get pretty ridiculous
I must have missed the part where it said they were forcing people to work here? With the workers being 3.1 miles off of one of the biggest media laden metropolitan areas of the world, I doubt these people are going to try and hide very much.
This is probably the oppurtunity of a life time for a lot of people to get out of their home country for a while and see the U.S. a little bit.
Except that nobody has ever heard of the Silmarillion and many people have heard of The Hobbit (it was required reading for most of my friends and I when we were in grade school), and if they haven't heard of The Hobbit then they at least know what Hobbits are.
Be glad that they aren't making a movie out of the Silmarillion, it is the last big bastion of Tolkien to remained unscathed by popularization via animation or film.
What about making a cartoon series for "Adventures of Tom Bombadil" ?;)
What about client side attacks, such as attacks against web browsers and email clients? These kind of security problems comprise a large portion of attacks against Windows based machines, and with the rising popularity of cheap routers that provide good protection to home users via firewall and NAT rules that will prevent direct attacks against daemons, client side attacks will be rising in popularity over the next few years, and cheaply available firewalls won't do anything to help.
Of course, this kind of analysis would require a more involved approach to testing O/S security, rather than just installing an O/S, throwing it on the internet and sitting back and waiting for whatever randomly happens to it to happen, which doesn't really seem to be the way honeynet likes to operate.
Keep in mind that Honeypots were originally intended to track the behavior of so called blackhats, not to analyze the security of operating systems, and they probbably aren't the best choice for the job.
Am I missing something here or does this paper totally ignore the fact that in the real world, what you can do to secure a system depends on what you want the system to do.
A secure system is great, but it is totally pointless if the server doesn't serve a function. Securing a system should always start with defining what exactly the system needs to do, so that you can know what exactly it doesn't need to do, as securing a system equates to eliminating possible security risks that aren't essential to system functionality.
For example, the paper's section on SUID/SGID binaries says that they can be dangerous, but doesn't inform the reader as to which SUID/SGID binaries are necessary to perform different tasks. This information is thus not very useful to kind of person that could potentially benefit from this paper, because the kind of person that doesn't know SUID/SGID bits can be dangerous will most likely not know which SUID/SGID bits can be safely removed.
I wouldn't say that Linux Vendors hardening their system by default has anything to do at all with Bastille Linux.
For the most part, Bastille just covers up for shortcomings in distribution desgin, which are bound to be corrected over time anyway.
In my opinion, Bastille's utility depends on how poorly the system was designed for a security standpoint to begin with, and isn't due to any extra value added features that Bastille provides.
Having said that, there will continue to be a need for hardening systems such as Bastille as long as vendors continue to ship with things that provide an additional security risk to everyone who uses the distro while only being of utility to a small portion of the people that use a distro (like isdn utilities being set to SUID as default, don't even try to tell me that most people use ISDN).
Hopefully in the future vendors will take a more role based approach to securing systems, and only things that are explicity selected as required functionality will be enabled, eliminating extra nextwork services and unnecessarily SUID/SGID binaries.
Most of the default services that run on common Linux distributions aren't specific to Linux itself, i.e. you can run apache, openssh, sendmail, etc on a BSD system just as easily as you can on a Linux system.
Granted, the underlying operating system can and does affect the exploitability of bugs that exist in these services, but the system comprimise is more of a direct result of the daemon than it is the underlying operating system.
In fact, the hardware of the system can and does have just as much or more influence over the exploitability of many daemon bugs as the operating system does, yet I see no mention of what architecture these honeypot boxes were running on in Honeypot Project's report.
Slashdot Mirror
Why would anyone ever do this? "Excessive noise"? Oh, you mean more orders? Last time I checked, more entries in the database never hurt anyone (not like every user is going to create duplicate accounts to the point where you're running out of resources, user records are tiny anyhow). Writing some 'intelligent' algorithm to detect duplicate accounts will invariably lead to marking legitimately separate user's accounts as duplicates and eliminating business.
Ahh, but experience matters too..
Yes yes, it is rather stupid for it to be "My Computer" or "Computer" at all, after all, it's just a Directory of part of the computer, it isn't representative of the computer as a whole at all. It should be something like "Browse Files" to eliminate all the stupid communications problems this creates.
The problem with having just one really strong password is that in the event that someone managages to get that one password (always plan security around how things might fail, not how they should work), its strength no longer matters and you're in the same position as having just one weak password for everything.
/etc/shadow; gives them less time to crack the password before it expires.
Someone could use a mechanism to get your one password that totally bypasses its strength againt cracking/guessing. For example, and this is rather common, someone could trojan an sshd, httpd, or smtpd server by either modifying it or replacing it with a version that just grabs your password when you enter it and store it. They can then take that password and use it for all of your other accounts, and do tons of damage to you before you have a chance to change your password everywhere.
Regarding "change your password every 30 days" systems - these are useful incase someone gets your password and you don't know, they can only use it for 30 days max (avg of 15) before the password is bunk. This also helps in the event that someone gets an encrypted or hashed copy of your password, say from a UNIX's
Ah, but I wasn't talking about stopping the email with profanity in it, I was talking about stopping the email with sensitive internal information that doesn't contain any profanity and has to be read by a human being with a sense for what is sensitive and what isn't before it is sent out.
The wrong paragraph regarding the status of a project or feelings about a client getting out can damage a business a lot more in the long term than a childish "fuck you" or something.
interesting story, but how would email monitoring help with this? The email would have been sent anyhow, and would have ended up in some pile of hundreds of other emails to be checked over?
Only thing that would have stopped this is if all outbound mail had to be read by a human monitor before leaving the company, which could get pretty ridiculous
I see a new Bollywood hit coming...
I must have missed the part where it said they were forcing people to work here? With the workers being 3.1 miles off of one of the biggest media laden metropolitan areas of the world, I doubt these people are going to try and hide very much.
This is probably the oppurtunity of a life time for a lot of people to get out of their home country for a while and see the U.S. a little bit.
Except that nobody has ever heard of the Silmarillion and many people have heard of The Hobbit (it was required reading for most of my friends and I when we were in grade school), and if they haven't heard of The Hobbit then they at least know what Hobbits are.
;)
Be glad that they aren't making a movie out of the Silmarillion, it is the last big bastion of Tolkien to remained unscathed by popularization via animation or film.
What about making a cartoon series for "Adventures of Tom Bombadil" ?
except for Beastie. In that spirit, i'm going to be realeasing a new BDS distro shortly: BeastieBSD.
It will be exactly the same as FreeBSD, except it will still get new users based soley on the awesomeness of its logo.
What about client side attacks, such as attacks against web browsers and email clients? These kind of security problems comprise a large portion of attacks against Windows based machines, and with the rising popularity of cheap routers that provide good protection to home users via firewall and NAT rules that will prevent direct attacks against daemons, client side attacks will be rising in popularity over the next few years, and cheaply available firewalls won't do anything to help.
Of course, this kind of analysis would require a more involved approach to testing O/S security, rather than just installing an O/S, throwing it on the internet and sitting back and waiting for whatever randomly happens to it to happen, which doesn't really seem to be the way honeynet likes to operate.
Keep in mind that Honeypots were originally intended to track the behavior of so called blackhats, not to analyze the security of operating systems, and they probbably aren't the best choice for the job.
Am I missing something here or does this paper totally ignore the fact that in the real world, what you can do to secure a system depends on what you want the system to do.
A secure system is great, but it is totally pointless if the server doesn't serve a function. Securing a system should always start with defining what exactly the system needs to do, so that you can know what exactly it doesn't need to do, as securing a system equates to eliminating possible security risks that aren't essential to system functionality.
For example, the paper's section on SUID/SGID binaries says that they can be dangerous, but doesn't inform the reader as to which SUID/SGID binaries are necessary to perform different tasks. This information is thus not very useful to kind of person that could potentially benefit from this paper, because the kind of person that doesn't know SUID/SGID bits can be dangerous will most likely not know which SUID/SGID bits can be safely removed.
I wouldn't say that Linux Vendors hardening their system by default has anything to do at all with Bastille Linux. For the most part, Bastille just covers up for shortcomings in distribution desgin, which are bound to be corrected over time anyway. In my opinion, Bastille's utility depends on how poorly the system was designed for a security standpoint to begin with, and isn't due to any extra value added features that Bastille provides. Having said that, there will continue to be a need for hardening systems such as Bastille as long as vendors continue to ship with things that provide an additional security risk to everyone who uses the distro while only being of utility to a small portion of the people that use a distro (like isdn utilities being set to SUID as default, don't even try to tell me that most people use ISDN). Hopefully in the future vendors will take a more role based approach to securing systems, and only things that are explicity selected as required functionality will be enabled, eliminating extra nextwork services and unnecessarily SUID/SGID binaries.
Most of the default services that run on common Linux distributions aren't specific to Linux itself, i.e. you can run apache, openssh, sendmail, etc on a BSD system just as easily as you can on a Linux system.
Granted, the underlying operating system can and does affect the exploitability of bugs that exist in these services, but the system comprimise is more of a direct result of the daemon than it is the underlying operating system.
In fact, the hardware of the system can and does have just as much or more influence over the exploitability of many daemon bugs as the operating system does, yet I see no mention of what architecture these honeypot boxes were running on in Honeypot Project's report.