Hi, I have servers of mixed OS, some Centos, some Fedora, and after the flame war that erupted last week (where I said basically nothing and just watched), my server was hacked by this team of hackers, actually their friend: http://www.sibersavascilar.com/ This made Karanbir's statements about mixing Cpanel and Centos (any maybe any linux distro) come true very quickly. If one of the top package maintainers says this, it bears weight. I'd like to know more about this subject, specifically on the package front, for security's sake. Karanbir, can you restate the issues with Cpanel please? They are trying to recommend CentOS as the OS to install on, and even that Linux Journal article did -and before anyone else wastes their time, -let's get everything out in the open so that there's a pipermail archive trail for future folks 'googling' for info later on pros/cons of using, or avoiding use of, non-complimentary projects/technologies. Is the issue that both parties maintain separate packaging/updating regimes and have little or no successful communication as far as keeping thing secure and up to date? That seemed to be what you said, -and if I had the old email, i'd just run with it's advice. Also, can you list the IRC channels you mentioned last time that contain the various hackers bragging about freshly broken Cpanel/Centos builds? Freenode right? Any others? I've been on IRC back when BITNET was still active and there wasn't even mosaic yet, but have always avoided it after 1992 because of hackers 'sniffing for future targets'. William, Jim, Johnny, -any comments are truly welcome, -anyone really. Basically i'd like to help stop or curtail the 'open season' this set of circumstances is creating for hackers, -I have already decided to avoid Cpanel on Centos as it is, -my server that was hacked with Cpanel was not a Centos box, and those that have it, have been shut down. The server next to it was *also* hacked, and that *was* a centos machine, with only a yum update from 3 days prior. Is it really recommeded that I run yum update evry night then? It was stunning to have a box up for 3 days and then get owned so fast. Luckily this was for my personal business entity, and not my full-time job, which indeed does run 50-70 Centos servers behind layers of firewalls and other protections, and *no* commercial products, only centos packages by Dag or Karanbir. To anyone in the mood for scolding, please hold off OK? I'm not in the mood for overbearing attitudes right now. I'm trying to run a business and seek solid answers. I see Centos as a reliable alternative to commercial offerings *if* you pay careful attention to what the senior staff and relevant discussion groups advise. As for the team of hackers, if anyone knows who this is, or can point out who they might be or how to ban them, -that is also most welcome. Hacked By Crackers_Child For Peace DONT WAR ! Greetz : X_Alperen_X, XTech Inc , Metlak, Root_Mor,Dr Hacker, Dr.Jr7 ,Dr,Dermann,Code_Power,CukurOval? ALL My Friends And All SiberSavascilar.Com Members ! --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20060809/a32d29d5/attachment-0002.html>
On Wed, 2006-08-09 at 09:08 -0700, Karl Balsmeier wrote:> Hi, > > I have servers of mixed OS, some Centos, some Fedora, and after the > flame war that erupted last week (where I said basically nothing and > just watched), my server was hacked by this team of hackers, actually > their friend: > > http://www.sibersavascilar.com/ > > This made Karanbir's statements about mixing Cpanel and Centos (any > maybe any linux distro) come true very quickly. If one of the top > package maintainers says this, it bears weight. > > I'd like to know more about this subject, specifically on the package > front, for security's sake. > > Karanbir, can you restate the issues with Cpanel please? They are > trying to recommend CentOS as the OS to install on, and even that > Linux Journal article did -and before anyone else wastes their time, > -let's get everything out in the open so that there's a pipermail > archive trail for future folks 'googling' for info later on pros/cons > of using, or avoiding use of, non-complimentary projects/technologies. > > Is the issue that both parties maintain separate packaging/updating > regimes and have little or no successful communication as far as > keeping thing secure and up to date? > > That seemed to be what you said, -and if I had the old email, i'd just > run with it's advice. > > Also, can you list the IRC channels you mentioned last time that > contain the various hackers bragging about freshly broken > Cpanel/Centos builds? Freenode right? Any others? I've been on IRC > back when BITNET was still active and there wasn't even mosaic yet, > but have always avoided it after 1992 because of hackers 'sniffing for > future targets'. > > William, Jim, Johnny, -any comments are truly welcome, -anyone really. > Basically i'd like to help stop or curtail the 'open season' this set > of circumstances is creating for hackers, -I have already decided to > avoid Cpanel on Centos as it is, -my server that was hacked with > Cpanel was not a Centos box, and those that have it, have been shut > down. > > The server next to it was *also* hacked, and that *was* a centos > machine, with only a yum update from 3 days prior. Is it really > recommeded that I run yum update evry night then? It was stunning to > have a box up for 3 days and then get owned so fast. > > Luckily this was for my personal business entity, and not my full-time > job, which indeed does run 50-70 Centos servers behind layers of > firewalls and other protections, and *no* commercial products, only > centos packages by Dag or Karanbir. > > To anyone in the mood for scolding, please hold off OK? I'm not in > the mood for overbearing attitudes right now. I'm trying to run a > business and seek solid answers. I see Centos as a reliable > alternative to commercial offerings *if* you pay careful attention to > what the senior staff and relevant discussion groups advise. > > As for the team of hackers, if anyone knows who this is, or can point > out who they might be or how to ban them, -that is also most welcome. >---- The only way to close the door is to figure out which door they used to get in. The likely culprits are ssh - things like php (especially if using phpbb or other content management systems which allow users to write things on the web site). My money these days is always on SSH, allowing users to log in via password and users with weak passwords. It's not really germane to discuss whether it was CentOS, CPanel or whatever until you actually know how they got in. Craig
Hm, we have mixed results with security regarding cPanel and CentOs (or any distribution really). It seems like anytime there are forums involved, an insecure /tmp directory, or the default cPanel services all left enabled, you're headed for trouble. That's just my opinion. -Drew ________________________________ From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf Of Karl Balsmeier Sent: Wednesday, August 09, 2006 12:08 PM To: CentOS at centos.org Subject: [CentOS] Server Hacked: Cpanel Hi, I have servers of mixed OS, some Centos, some Fedora, and after the flame war that erupted last week (where I said basically nothing and just watched), my server was hacked by this team of hackers, actually their friend: http://www.sibersavascilar.com/ This made Karanbir's statements about mixing Cpanel and Centos (any maybe any linux distro) come true very quickly. If one of the top package maintainers says this, it bears weight. I'd like to know more about this subject, specifically on the package front, for security's sake. Karanbir, can you restate the issues with Cpanel please? They are trying to recommend CentOS as the OS to install on, and even that Linux Journal article did -and before anyone else wastes their time, -let's get everything out in the open so that there's a pipermail archive trail for future folks 'googling' for info later on pros/cons of using, or avoiding use of, non-complimentary projects/technologies. Is the issue that both parties maintain separate packaging/updating regimes and have little or no successful communication as far as keeping thing secure and up to date? That seemed to be what you said, -and if I had the old email, i'd just run with it's advice. Also, can you list the IRC channels you mentioned last time that contain the various hackers bragging about freshly broken Cpanel/Centos builds? Freenode right? Any others? I've been on IRC back when BITNET was still active and there wasn't even mosaic yet, but have always avoided it after 1992 because of hackers 'sniffing for future targets'. William, Jim, Johnny, -any comments are truly welcome, -anyone really. Basically i'd like to help stop or curtail the 'open season' this set of circumstances is creating for hackers, -I have already decided to avoid Cpanel on Centos as it is, -my server that was hacked with Cpanel was not a Centos box, and those that have it, have been shut down. The server next to it was *also* hacked, and that *was* a centos machine, with only a yum update from 3 days prior. Is it really recommeded that I run yum update evry night then? It was stunning to have a box up for 3 days and then get owned so fast. Luckily this was for my personal business entity, and not my full-time job, which indeed does run 50-70 Centos servers behind layers of firewalls and other protections, and *no* commercial products, only centos packages by Dag or Karanbir. To anyone in the mood for scolding, please hold off OK? I'm not in the mood for overbearing attitudes right now. I'm trying to run a business and seek solid answers. I see Centos as a reliable alternative to commercial offerings *if* you pay careful attention to what the senior staff and relevant discussion groups advise. As for the team of hackers, if anyone knows who this is, or can point out who they might be or how to ban them, -that is also most welcome. Hacked By Crackers_Child For Peace DONT WAR ! Greetz : X_Alperen_X, XTech Inc , Metlak, Root_Mor,Dr Hacker, Dr.Jr7 ,Dr,Dermann,Code_Power,CukurOval? ALL My Friends And All SiberSavascilar.Com Members ! ________________________________ Stay in the know. Pulse on the new Yahoo.com. Check it out. <http://us.rd.yahoo.com/evt=42974/*http:/www.yahoo.com/preview> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20060809/439a8a56/attachment-0002.html>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some excerpts: On Wed, Aug 09, 2006 at 09:08:00AM -0700, Karl Balsmeier wrote:> This made Karanbir's statements about mixing Cpanel and Centos (any maybe any > linux distro) come true very quickly. If one of the top package maintainers > says this, it bears weight. > > I'd like to know more about this subject, specifically on the package front, > for security's sake.First things first. When you install cPanel, you no longer have a CentOS machine, you have a cPanel one. As simple as that. cPanel is way too intrusive. It will stop any efforts from the CentOS team to keep the machine current and secure. It will change everything from services to libraries.> Is the issue that both parties maintain separate packaging/updating regimes and > have little or no successful communication as far as keeping thing secure and > up to date?Actually no. There are many features on cPanel that depend on heavy patching of packages, including Apache and Exim. There is actually no way better communication would make any difference, unless cPanel was made opensource (and correctly documented).> Also, can you list the IRC channels you mentioned last time that contain the > various hackers bragging about freshly broken Cpanel/Centos builds?Is there any need for that ? Hacking a cPanel server is trivial for any hacker but a script kid. Not only it will use unsecure versions of many softwares and some patches of questionable safety, it will also stop you from using several method of improving security (/tmp hardening with ACLs is just one example). There are some people (rack911.com) that can do wonders securing a cPanel server, but even them can't make it as secure as a pure CentOS server. If you really need to use cPanel (and other CPs for that matter), I urge you to contact Steve at rack911.com and ask him to secure your server. Regarding CP based servers, he is the best I know.> William, Jim, Johnny, -any comments are truly welcome, -anyone really. > Basically i'd like to help stop or curtail the 'open season' this set of > circumstances is creating for hackers, -I have already decided to avoid Cpanel > on Centos as it is, -my server that was hacked with Cpanel was not a Centos > box, and those that have it, have been shut down.It really will make no big difference if you are using CentOS or some other base distro for cPanel. cPanel will replaces so many things, and will give you Fantastico, which is an amazing tool, as long as you don't mind security.> The server next to it was *also* hacked, and that *was* a centos machine, with > only a yum update from 3 days prior. Is it really recommeded that I run yum > update evry night then? It was stunning to have a box up for 3 days and then > get owned so fast.Again, wouldn't have made any difference.> Luckily this was for my personal business entity, and not my full-time job, > which indeed does run 50-70 Centos servers behind layers of firewalls and other > protections, and *no* commercial products, only centos packages by Dag or > Karanbir.That is the way to go.> To anyone in the mood for scolding, please hold off OK? I'm not in the mood > for overbearing attitudes right now. I'm trying to run a business and seek > solid answers. I see Centos as a reliable alternative to commercial offerings > *if* you pay careful attention to what the senior staff and relevant discussion > groups advise.I hope you don't think I'm scolding you. CPs have a business value. I'm well aware of that. But you get that at the price of security (along other things that don't relate to this thread). My point is very simple: if you are using cPanel, you WILL get hacked. I suspect the same holds true for all other CPs (DirectAdmin, Cubix etc), but I can't say for certain, since I never audited a machine with those CPs, only read their specs. Your best shot is to get speciallized cPanel securing assistance. As I said, Rack911 is your best bet as far as I'm concerned.> As for the team of hackers, if anyone knows who this is, or can point out who > they might be or how to ban them, -that is also most welcome.Don't want your time trying to ban them. It won't work. They will simply hack someone else's cPanel server and use it to access your. There are some tips and HOWTOs on www.webhostingtalk.com that might help you secure your machine by yourself, and if nothing else, I would check there. Best Regards, - -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2g04pdyWzQ5b5ckRApYaAJ9RyqnonfdcNZ5hZ36krIsxCBMy4wCgr3iU BiskH0c+60kcsv+ZcQnTmSo=zK61 -----END PGP SIGNATURE-----
<snipping everything> Okay, here's my personal take on the matter, for the $0.000002 that it's worth. For production machines, sometimes control panels are required for the job. I'll preach against them, but that doesn't do much. If you install something like Cpanel to a system, you're adding a level of complexity. You're stepping over what's provided in the base, and adding to it. This means you need to not only know the base inside and out, but you need to know Cpanel inside and out as well. So, lets go through the admin checklist: 1. Minimal packageset. Go through the rpms installed on your system and clean out ones that you don't need or don't use. window managers, compilers, etc have no business on a production box. If you need a compiler to install/update cpanel, you might want to look at the possibility of removing them after the install/update. If they stay on the system, you're only giving the attacker something else to use that he doesn't have to provide himself. 2. Regular updates and backups. Duh, but still needs to be said. Too many people don't do this. 3. Config changes. Many default application settings are wide open. Make sure that you lock down or disable what you don't need. For example in php things like allow_url_fopen, globals, etc should be off. Safe Mode should be on if you can manage it within your application. 4. Permissions: Unix permissions by default are DAC style, where the user has the power to change permissions. Make sure that you stay on top of this and keep permissions in places like your webroot to a minimum to do the job. If you can, enable SELinux, which is MAC style based permission, which enforces restrictions no matter what the user does. 5. Data input checking: SQL injections and other such annoyances can be avoided with proper input checking. Utilities like mod_security for apache are a must in my book. If you're able, go through the code for whichever app you're using and see if they're checking input properly. Invest some time in mod_security and learning the rulesets. It's archaic, but the defaults are good, and they stay updated. If you're using a common app (phpbb or some such) you shouldn't have to tweak much to enjoy the protection of mod_security. (it's at centos.karan.org all packaged up for you. Thank karanbir for it) 6. Log checking use logwatch other other such utilities and keep up on your logs. If someone's been poking at your site for a few days, and they've gone from getting loads of 40(3,4)'s to 302s or 200's.. you'll want to know about it. Yes this is tailored mostly to web services. There are loads of other things to do.. but these are the basics, and most people who get bitten aren't staying on top of them. -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell
William L. Maltby wrote:> > Same here, even in my own net (I have grandchildren: they can be > "snoopy"). The darn trouble is trying to remember them all, including > those for different 'net sites; all have a different password.The solution to that is a secure password manager. http://passwordsafe.sourceforge.net/ You just have to remember the one password and the program will track all of the rest for you. This way you can use gibberish passwords for important sites such as online banking and you don't have to remember them or write them down anywhere. The password database is encrypted using Twofish and SHA-256. The only real downside is that if you don't have access to the password manager, you don't have access to anything else either. Oh...and don't forget backup the password database! :) -- Bowie
William L. Maltby wrote:> On Wed, 2006-08-09 at 17:26 -0400, Bowie Bailey wrote: > > William L. Maltby wrote: > > > The solution to that is a secure password manager. > > http://passwordsafe.sourceforge.net/ > > > > You just have to remember the one password and the program will track > > all of the rest for you. This way you can use gibberish passwords for > > important sites such as online banking and you don't have to remember > > them or write them down anywhere. The password database is encrypted > > using Twofish and SHA-256. > > I don't care for that concept. One password cracked gives access to all. > I would rather take the admitted risk of writing them down (in *my* > scenario, rather secure at home) and referring to that when needed.True, but if you make that one a good one and use it only for that purpose, the risks are minimal.> The ones I use frequently will be remembered. I don't use them on the > road at all, so that's reasonable. I prefer to not have passwords stored > on computers any more that necessary.I don't think it's a problem to have the passwords stored on the computer. Just make sure they're securely encrypted.> No I'll admit I fudge a *small* amount. Those who have access in my home > know windows only, not Linux and I have no shares with them. They are > TDU (Typical Dumb Users) and don't know how to use SSH, FTP, ... or even > how to find my comps on the LAN (now SMB node or Domain Controllers > here). > > > > The only real downside is that if you don't have access to the > > password manager, you don't have access to anything else either. > > Well, I do consider the one password exposes all a downside. But I also > grant that it is more secure than many alternatives.You know what they say: "You can put all your eggs in one basket, but WATCH THAT BASKET!" As long as you are extremely careful with the access password, you shouldn't have a problem. I will take this risk for the advantage of being able to easily use highly secure passwords. For example, my online banking password is a sequence of random characters. I don't have to remember it or type it. If I didn't have a tool like this, I would have to either write it down somewhere or use a less-secure password that I could remember.> > Oh...and don't forget backup the password database! :) > > I'm finalizing my LVM-based snapshots with aging of deleted files right > now, so I will be covered.That works, but a simple backup copy to a floppy disk or external hard drive works as well.> Thanks for the URL. I will go take a look. My mind is not yet > rusted closed even if (... *when*) I think I'm right! :-)The creator of this tool is a rather paranoid security expert. I figure if he is willing to use it, it's worth a look. http://schneier.com/ (note that the Password Safe information on that page refers to an older version that used Blowfish rather than Twofish) -- Bowie
hi! Karl Balsmeier wrote:> Hi, > > I have servers of mixed OS, some Centos, some Fedora, and after the > flame war that erupted last week (where I said basically nothing and > just watched), my server was hacked by this team of hackers, actually > their friend:the issue with cPanel + CentOS has been security related, always. They ( cPanel ) are very lethargic about doing security updates, and are quite willing to continue to push known bad packages. Also, they seem to have decided ( for no real reason, that i can see ) to use their own packages for the core operational packages on web servers ( stuff like php, mysql, apache etc ) - none of these apps are then being either audited / monitored / patched / updated like the other packages in the CentOS distribution are. Some very good points have been made by the others here w.r.t security and checklists etc. It would be nice to see someone from cPanel ( we know there are some on this list! ) address some of these issues... -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq
cPanel or ANY server solution should never be deployed until it is locked down! We have been using cPanel for years as well as Hsphere and Plesk for both linux and windows. They all are ?hackable? if not locked down and hardened. We use Trustix, RHEL & CentOs for our Linux environments. The more you allow (in cPanel or any control panel), the less secure. Fix the tmp directory BEFORE you plug it in to the network. File there should NOT be executed by ANYONE. About 3 and a half years ago, we learned this the hard way and every index.* file on a particular server that had cpanel installed was defaced (RH 7 I believe). This was NOT a cPanel issue. It was a combination of a PHP exploit, tmp not being secured, and my lack of knowledge. cPanel has a utility to secure the tmp directory. On a machine that has cPanel installed type the below command: /scripts/securetmp I have never had a problem with this sort of attack after I secured the tmp directory. I also recommend not giving shell access by default. Only give it out to people who need it. Make it a little difficult for the end user. Ask them them to fax a copy of their DL and/or copy of the first page of a utility bill. Sure a bad person can create these documents, but it typically is not worth their time. Also if a user needs ssh bad enough, they will send this info in and they probability will be good users. It also lets them know that you are "security conscious". You can also install a ?keystroke auditing? system such as eas / easd so you can review ssh sessions should you suspect something. If you grant a user ssh rights, reset the end users password to a secure password and let them know that they should maintain a strong password. If their account is ?bruteforced? due to a weak password, cancel their account, as they are too much of a risk for you (or ask them to go dedicated). Install some type of BFD (Brute Force Detection) software. I like http://www.rfxnetworks.com/bfd.php (free and easy to install) Disable things like gcc, wget, lynx . . .etc. I also like to chattr +i files. A very good application is another product from rfnetworks called LES http://www.rfxnetworks.com/les.php Disable root direct login via ssh. Block all incoming traffic except needed ports in iptables (22, 80, 443, 21, . . . ). I like to block all outgoing traffic to all users except for root with the exception of common API's such as Domain registration, Credit Card Gateway etc.) Enable suexec and php safemode if possible. Also disable the mod_dl and other php modules known to have caused problems. If you have users who need ?every module known to man?, setup a server with the php modules needed and only place these users on these systems who specifically need them. Why introduce more risk to users who do NOT need all these features? Install mod_evasive to help against Ddos as well as Mod Security. Run updated rootkit checkers (rkhunter & chkrootkit) daily. This is not perfect, but it will help determine a systems integrity. If a machine has been hacked or owned - you MUST setup a new machine and restore the non binary files to the new machine. This is the sad truth, but you never know what is hiding on a machine after its hacked (owned). Do NOT allow cPanel to automatically update your software or you are asking for problems. Have a cheap server or virtual server with cpanel running on it and update that "test" machine and make sure that nothing breaks. We have 50 beta users who we give hosting to. We place on these users on beta (test) machines. The beta users are aware that these machines are at greater risk than the production machines and they are 100% responsible for backups. It is worth giving away 50 free accounts and place them on test beta platforms so that we can actually simulate a "real" environment while testing cpanel upgrades. If testing is successful, then roll out in production. cPanel has broke many things in the past that were easily fixed by their support staff but why take chances??? I recommend the above measures for any system (cPanel installed or not). cPanel is the most popular control panel for Linux. It allows the end user to control their site and cpanel ties into many billing systems so account provisioning can be automatic. We use it because it offers features that end users demand. Without it, we can't compete . . . so we have to adapt by securing the system as much as possible. Tim Rice Host It Now Networks http://hostitnow.com/ Timothy Rice Host It Now Networks http://hostitnow.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20060811/ae628152/attachment-0002.html>