It isn't part of the solution, it is just lazy (which ironically ends up being more work), and imparts a false sense of security.
Even if I were foolish enough to buy into the whole security through obscurity angle, I would implement this via a firewall/router that forwards traffic on a nonstandard port to port 22 on the server in question, not by simply plugging in the red cable into my box and having it listen on a nonstandard port (or even more retardedly forwarding the nonstandard port ssh traffic to a nonstandard port on the ssh server).
The whole nonstandard port thing is silly. It does nothing (yes, nothing) to enhance security but to be fair it doesn't impact security either. Note that some places block outbound connections on nonstandard ports.
It decreases the number of script based dictionary attacks aimed at port 22, so your logs are not as cluttered. Other than this running on a nonstandard port does nothing to enhance security.
Patch the hole because you don't want someone else (say a pron spammer) to come in behind you and end up getting caught (or screwing up your server). But yes there could be an exploit they are using in 5.x as well.
I suspect it was not a brute force attack, they simply disguised the exploit as one so that it falls into the noise of the hundreds of brute force attacks each day.
My name appears in the comments of well crafted code, in svn, and in Redmine where the issues and feature requests consistently get knocked out on time. My customers see high quality work, and know who did it.
That is all the recognition I need. If I get laid off because I am not playing politics, so be it. I am good. I can get another job at will. I have a years salary in the bank. Aside from that if it doesn't involve my family, or to a lesser extent my hobbies, I don't give a shit.
This is obvious, hence why I said so in the first place... but the developers rarely screw things up. In fact, the developers reach a stable point rather quickly (lest it become impossible to do their jobs)... and then absolutely DO NOT WANT IT TOUCHED. Especially by some IT fool with a certificate in Christ knows what who has not been attending the scrums and has not idea why things are set up they way they are. Now, said stable point might not be equivalent to the best (or even mediocre) practices, hence the reason it should be separate as well as a variety of other reasons)
You get some dickwad in there smugly thinking "oh oh why is port 25 open and also port 69! Better close them!" Seconds later howls from down the hall because everyone's shit just broke, and pubic hair guy from IT doesn't realize that telnet and tftp are commonly still used in an embedded environments, but then again this wipe just thought he was the shit in the lawyers office he worked in for two entire years.
Sigh.
Now, most normal nerds would never be running telnet and tftp servers on the corporate network, but IT had to have their bowl of rice and because of the tantrum they threw in some meeting... development is now going on the same wire that the secretaries are posting pics of their latest dildo on Facebook.
Development machines should be on a separate network that IT is forbidden from touching. A network that is insulated from the corporate office network.
Most IT departments simply cannot deal with their corporate users... when they end up in the engineering department conflicts ensue, and the engineers 1) are usually right, and 2) well, they are funding everyone's paycheck, so in a sense they can't be wrong.
What happens with the secretaries and suits... well the IT types can go right ahead and have their way.
Anyone with a security clearance should be ashamed to use such a line for a multitude of reasons. Keep it real, and stand in line with those you are charged with protecting.
HAARP looks like your average electrical substation. I used to work for BAE Systems Advanced Technologies (designed and built it). Trust me, the tin foil hat crowd that constantly harps on HAARP would be severely let down were they to believe the real story (which incidentally is available on the HAARP website).
Runs nightly, full backup, archives yearly, monthly, and weekly.
Recovery scripts and directions located locally, offsite with the backups, and on my laptop (as well as in our company Redmine which runs on a separate server which is backed up similarly).
I test recovery once a season (to make sure it still works and to remind myself how to do it).
It wasn't rocket science to set up, and took a few days to stand up and fine tune.
Slashdot Mirror
Just because the overseas programmers suck (debatable, but let's assume) doesn't mean management isn't going to go for the $14/hr carrot.
>> Sometimes I think Slashdot is stuck in the 90s with their MS borg pictures for MS stories and a normal corporate logo for Apple stories
I think that all the time.
DOCEX (document exploitation) is a very active activity within the armed forces.
I have a working Zip Drive, SCSI. I also have the cables and a card, along with the drivers and an old 386SX that will read it.
Not that I have a VGA monitor anymore....
But CentOS X.Y is supposed to be basically identical to RHEL X.Y-1.
So, again, why no exploited RHEL servers? Note that RHEL is pretty damn common as well.
Just asking.
This event spanned YEARS. Why no RHEL victims?
I smell a rat in CentOS.
It isn't part of the solution, it is just lazy (which ironically ends up being more work), and imparts a false sense of security.
Even if I were foolish enough to buy into the whole security through obscurity angle, I would implement this via a firewall/router that forwards traffic on a nonstandard port to port 22 on the server in question, not by simply plugging in the red cable into my box and having it listen on a nonstandard port (or even more retardedly forwarding the nonstandard port ssh traffic to a nonstandard port on the ssh server).
The whole nonstandard port thing is silly. It does nothing (yes, nothing) to enhance security but to be fair it doesn't impact security either. Note that some places block outbound connections on nonstandard ports.
Have fun logging into your box from such places.
It decreases the number of script based dictionary attacks aimed at port 22, so your logs are not as cluttered. Other than this running on a nonstandard port does nothing to enhance security.
However some fools somehow think it does.
Patch the hole because you don't want someone else (say a pron spammer) to come in behind you and end up getting caught (or screwing up your server). But yes there could be an exploit they are using in 5.x as well.
I suspect it was not a brute force attack, they simply disguised the exploit as one so that it falls into the noise of the hundreds of brute force attacks each day.
That makes me think twice about skipping on that Redhat license.
Perhaps the folks at Cent should be checking their logs.
Because that is exactly what I want.
My name appears in the comments of well crafted code, in svn, and in Redmine where the issues and feature requests consistently get knocked out on time. My customers see high quality work, and know who did it.
That is all the recognition I need. If I get laid off because I am not playing politics, so be it. I am good. I can get another job at will. I have a years salary in the bank. Aside from that if it doesn't involve my family, or to a lesser extent my hobbies, I don't give a shit.
That alone will cut out most of the personal email.
Strangely enough, it's true.
Don't see why they *need* to publish this work, but if it is done can they atleast wait until they have administered 200 million or so vaccinations?
This is obvious, hence why I said so in the first place... but the developers rarely screw things up. In fact, the developers reach a stable point rather quickly (lest it become impossible to do their jobs)... and then absolutely DO NOT WANT IT TOUCHED. Especially by some IT fool with a certificate in Christ knows what who has not been attending the scrums and has not idea why things are set up they way they are. Now, said stable point might not be equivalent to the best (or even mediocre) practices, hence the reason it should be separate as well as a variety of other reasons)
You get some dickwad in there smugly thinking "oh oh why is port 25 open and also port 69! Better close them!" Seconds later howls from down the hall because everyone's shit just broke, and pubic hair guy from IT doesn't realize that telnet and tftp are commonly still used in an embedded environments, but then again this wipe just thought he was the shit in the lawyers office he worked in for two entire years.
Sigh.
Now, most normal nerds would never be running telnet and tftp servers on the corporate network, but IT had to have their bowl of rice and because of the tantrum they threw in some meeting... development is now going on the same wire that the secretaries are posting pics of their latest dildo on Facebook.
Development machines should be on a separate network that IT is forbidden from touching. A network that is insulated from the corporate office network.
Most IT departments simply cannot deal with their corporate users... when they end up in the engineering department conflicts ensue, and the engineers 1) are usually right, and 2) well, they are funding everyone's paycheck, so in a sense they can't be wrong.
What happens with the secretaries and suits... well the IT types can go right ahead and have their way.
What a load of crap.
Anyone with a security clearance should be ashamed to use such a line for a multitude of reasons. Keep it real, and stand in line with those you are charged with protecting.
Wrong.
Thank you Captain Obvious.
HAARP is a boring place, unspectacular in nature, and even more bland to look at.
HAARP looks like your average electrical substation. I used to work for BAE Systems Advanced Technologies (designed and built it). Trust me, the tin foil hat crowd that constantly harps on HAARP would be severely let down were they to believe the real story (which incidentally is available on the HAARP website).
Precisely how would this impede spoofing log messages?
Runs nightly, full backup, archives yearly, monthly, and weekly.
Recovery scripts and directions located locally, offsite with the backups, and on my laptop (as well as in our company Redmine which runs on a separate server which is backed up similarly).
I test recovery once a season (to make sure it still works and to remind myself how to do it).
It wasn't rocket science to set up, and took a few days to stand up and fine tune.