Plesk 9.2.1 - Looking to upgrade - Need Advice please

[ClearlyTechnical]

What is the best path to upgrade, and how high should I upgrade to?

php 5.3 has issues with vTiger, so I would like to stay young here.

currently have stable solution to provide domain specific php.ini using php-cgi wrapper. I understand 9.5++ makes it a breeze (as per brucelee), would like to know if it is worth it to upgrade.

Server has been extremely stable, looking to know pitfalls. Also, what is the update path on the yum repos to make sure I pull everything correctly for current version and os, etc.

All feedback welcome


Regards

[BruceLee]

I would upgrade to Plesk 9.5.3 not further. I had no problems upgrading from Plesk 9.X to 9.5, Everything went smoothly. I always update via yum but after some research lately would advise to at least run the autoinstaller once at the end of an yum based Plesk update.
I still use 9.5.2 but I don't think there are big differences between both except some bugfixes and the very important proftpd fix that you definitely need if you don't use the proftpd packages from ART.
I would stay with php 5.2.X and sue ART repo too.
My plesk.repo file looks like this and gives you the update path to the latest Plesk 9.5.3.
Watch out if you use postfix and not qmail like me with this config.

Code: Select all

[plesk]
name=Plesk Server Administrator
mirrorlist=http://www.atomicorp.com/mirrorlist/plesk/9.5/centos-$releasever-$basearch
gpgcheck=0
enabled=0
# Plesk RPM bug. Default is to assume postfix
#exclude=psa-mail-qc-driver*
exclude=psa-mail-pc-driver*

[ClearlyTechnical]

Brucelee,

Funny, I was watching history channel today and it was all about Bruce Lee.


1. Ok, so proftp issue. Could that be related to a problem I am having with Windows 7 and the native FTP client via explorer? If I ftp to my server using explorer, I can login, see the directory, add folders, but can't save files or rename them, etc. But I can through ftp client like SCP or whatever. In other words, it's only when I use explorer or ftp:// in the browser.

2. So you just yum upgraded from 9.x to 9.5 and there were no issues?

Bruce, also, I have php-cgi working flawlessly right now. I like your model of a single startup file that serves all hosts. So you only need put a php.ini in a give directory and it just works?

Postfix: Tried it after the 9.x, but fell back to qmail after postfix proved buggy. Not just referring to the repo exclude bug. Can you refresh me as to the advantage of postfix?

(getting itchy finger to upgrade)

Also, how to stay on php 5.2 as I definitely want to say on 5.2, 5.3 is not working with many lamp applications.

Also, just re-read your post and I can see the error regarding ftp was in 9.5.2, not my 9.2.x

Good to see you active in the forums. PM me, we should connect.

[ClearlyTechnical]

Bruce,

Also, regarding FTP. I keep all my ports closed except mail and web related and dns.

I use a simple port knocking solution that is iptables code and on the client side to knock, I just wrote a program in c# that does the knock sequence.

I give that program to clients and they just click unlock, it then opens tcp sockets to the ports I prescribe, in order, and bing, the ports open for 10 minutes. Will stay open as long as they are connected, 10 minutes is the envelope they have to form a connect.

If you want the script and source code so you can brand the knock client, let me know.

No reason to leave ftp port hanging open out there.

[BruceLee]

1. IE as an FTP Client is really crap in my opinion. I don't think that your problem in IE will be solved by updating proftpd. I have seen lots a situations where IE as FTP Client did not work properly. But you could try to check the ftp mode IE is running in (under advanced options in IE) and if the folderview is activated. Sometimes this helps. I never use IE as FTP Client and I don't recommend it.

2. Yes, I just used yum upgrade. But run the autoinstaller once after upgrading, because I don't know if the MicroUpdates get repacked in parallels packages. See the last post here: https://atomicorp.com/forums/viewtopic. ... 4&start=30

3. Follow this instructions and set correct permissions + your favorite path and it should work. But I liek the way Hultenius is going. Maybe between X-Mas and newyear I will try to test that in some sort of way on my test virtual machine.

1. set domain to fastcgi
2. edit the cgi wrapper file under /var/www/cgi-bin/cgi_wrapper/cgi_wrapper to your needs
mine looks like this:
Code:
#!/bin/sh
#
# Custom PHP FCGID wrapper for Plesk domains
#
A=`fgrep -m 1 "$UID" /etc/passwd| awk -F\: '{print $6}' |awk -F"/" '{print $5}'`
PHPRC=/var/www/vhosts/php-inis/$A/php.ini
[ -f ${PHPRC} ] || PHPRC="/etc/php.ini"
export PHPRC
exec /usr/bin/php-cgi

3. create php.ini for the domain you want with correct permissions (if no php.ini for this domain is present the default php.ini is used)
4. service apache graceful
-> and there you GO.

4. I also use qmail. It's rock solid and I don't see any advantage of postfix now. Sometimes I read about postfix problems with Plesk and therefore I don't want to be Parallels Beta tester. I stay with qmail. My plesk.repo is configured to ignore postfix.

5. It's possible that Plesk 9.2.X does not have this vulnerability (haven't checked it). If not, you are safe from that one.

6. Concerning Php 5.3.: It won't take long until Centos 5.6 is out that comes shipped with Php 5.3. That will probably be the time Atomicorp puts Php 5.3 from testing to stable. I will wait for that one. Maybe also so long until Parallels set Centos 5.6 on compatibilty list. I'm not sure now. Since I don't have a project that needs php 5.3 i'm not in hurry. some extensions like zend are still not available for Php 5.3. Check before updating, but I think php 5.3 is only available in testing repo. stable is 5.2.14

7. About your knock script. That sound real interesting. I bet Scott and Mike are interested in that one. I'm always concerned about security and how to improve it. One point about your script comes in my mind that might open a bigger risk than you prevent by closing the ports. If a client can just trigger an unlock that opens the tcp sockets it might be able to be abused for opening more than you like. Do the clients authenticate before triggering? There are some controlpanels with that feature. The client logs in the controlpanel, clicks "open ftp", can connect for a period of time and the port gets closed. The approach is good but is has to be configured in that manner that it's not possible to abuse it. Imagine someone with expertise abuse it to open more than just ftp, maybe with more permissions. I would definitely start a thread for that one and send the code to Atomicorp. With atomicorps expertise and some good brainstorming in a thread it might become a usefull addition for everyone.

[scott]

6. yup, spot on!

7. ditto, I think we put that into the book. Or maybe it got cut, I forget. Anyway its on the ASL todo list.

[ClearlyTechnical]

Thanks for the feedback. Regarding #7

You can't get to the control panel, unless you portknock first. I see no reason to advertise that we have a plesk control panel waiting at 8443

We only leave open those ports which are absolutely necessary.

You can have a seperate knock for each port if you want. For example. I have one sequence which opens 22, 8443. I have another for port 21.

There are numerous debates about port knocking. Nothing is perfect. For me it's about wrappers and leaving 21 open, verses not opening 21.

(By the way, if someone tries to portscan, they are immediately blocked. So trying to brute force the port knock would be ridiculously difficult.)

The idea here is to take simple tools, much like greylisting is to mail, portknocking is to our doorway management. You reduce 95% of the crap straight away. It's a great bang for the buck.

Also, by using iptables, you install no software. No dependency issues. Just insert script, and telnet into certain ports in a certain order, and the firewall opens up. Now that windows has chosen not to install telnet by default (wth was that all about?), I opted to write a simple c# program that makes it easy to knock. I am going to be adding LDAP support to the client which will make it really slick, because they would use their ftpusername/password to authenticate the client, which would then knock, which then opens 21. I thought that was pretty elegant.

Just got openLDAP tweaked and working great and have been using it to consolidate all the cms admin logins I have for an array of different sites/client that we host. (about 100 Joomla sites can now all have the admin password changed from one place in an instant. Great for when you fire someone. No editing 100 .htaccess files or joomla databases) I just need to get the ldap code working for the client and then it's a great little sourceforge project that I think could be adopted quickly. Particularly because of the LDAP piece as an option and the fact that the knockserver is nothing more than iptable script.

Much of the portknocking I have seen is way too complicated for my feable mind. The clients are overly sophisticated. The man in the middle debates, etc. and criticisms are like debating the probability of whether or not we should have a budget for defending against aliens from a nother dimension or planet. Possible, sure, likely, probably not.

Mind you this is a solution for noob admins like myself verses leaving my tail exposed to the world. It's the "greylisting wrapper" model verses trying to patch qmail, etc. Simple, elegant, powerfully effective. Best of all is the TIME to implement. Less than 45 minutes and even less for a non-noob.

You could have unlimited scripts for any number of portsequences.

EDIT:
Also, with LDAP server, we can offer another layer of security for CMS clients. Everyone knows the admin urls for the common CMSs. So by putting in an LDAP auth based .htaccess file in the admin directories for clients, we can reduce their CMS admin exposure. Again, they could first authenticate at the url level using LDAP (same ftpuser/pass combo as provided when you setup the hosting account for them) and then the admin url would be exposed. Great to keep out those trolling scripts looking for known vulnerabilities.

We can also add sub accounts in ldap upon request for the hosting clients which would be specific only to that URL or admin group.

These are simple things which allow unique, simple, yet powerful solutions to our hosting clients which help differentiate us from the competition. But in reality, it's less work for the admins because we have better management than we did before and less exposure, lol.

[BruceLee]

I sounds really nice. You are right, there are tons of debates about port knocking.

[mikeshinn]

My very portable, multi-distro compliant port knocking server and client, written in bash shell using iptables, with no listener or vulnerable service to be pwn3d:

https://www.prometheus-group.com/labs/u ... sh-pk.html

[BruceLee]

Thanks, Scott & Mike. So this is going to be implemented in future vesion of ASL if I understand Scott correctly?!

100% of my customers are Windows Users and 100% of them get a headache when they have to make a simple ftp upload
or just login into Plesk CP.

My dream would be a ready-for-ordinary-customers-solution where I provide a zipped folder with a ready2run configured ftp client (e.g WinSCP) that does everything in one step - portknock and than open the FTP session. Just a dream

@clearlytechnical: Did you send Atomicorp your solution already? Maybe you should open a new thread and introduce it in detail? Thanks for sharing!

[scott]

Yup, the link mike just posted is what we'll have in there

[ClearlyTechnical]

Thanks, Scott & Mike. So this is going to be implemented in future vesion of ASL if I understand Scott correctly?!

100% of my customers are Windows Users and 100% of them get a headache when they have to make a simple ftp upload
or just login into Plesk CP.

My dream would be a ready-for-ordinary-customers-solution where I provide a zipped folder with a ready2run configured ftp client (e.g WinSCP) that does everything in one step - portknock and than open the FTP session. Just a dream

@clearlytechnical: Did you send Atomicorp your solution already? Maybe you should open a new thread and introduce it in detail? Thanks for sharing!

Brucelee, we could do something like this. Portknocking client knocks, confirms opening of port 21, then fires up ftp client. User downloads the zip from your server and everything is in there. They would just run the client branded in your name, then it would knock and then launch ftp client. Client wouldn't fire up unless the port was opened. This tool could also be used as a troubleshooting device to see if their own firewall is blocking the outgoing port 21.

Regarding debates, they are pointless to me. For me, portknocking with iptables, client to knock ports, is a no-brainer. The debates are for people who want to major in the minors and knit pick amoung their peers for know-it-all points. The reality is, it's a no-brainer on par with what greylisting wrapper is to qmail. Simple and highly effective. If you want to be anal, then just turn off your server and be sure to unplug it from the wall.

Scott/Mike,
My iptables script is much smaller. It simply looks for a port knock combination in a certain order then unlocks whichever ports you want to run. I have it load at the end of my iptables script. Considering you wrote the book on iptables, could you document the script a bit. My client code just pokes a series of ports in a pre-defined order.


TODO:
LDAP Authentication prior to knocking
Ability to update knock sequence
Auto-launch ftp client (WinSCP is my favorite)

For host providers (brucelee e.g.)
Auto-Generated session file for WinSCP which includes ssl key pair. This way they authenticate with LDAP, and then client knocks, opens port, then WinSCP auto launches with ssl key and opens right up to the httpdocs directory all in one fell swoop. (brucelee, you would be a huge help with this piece and we could use the code as part of our per domain solution for cgi, php, etc. It could be another aspect. This way it would reside in our skeleton file and build it all right on the fly when a domain is created. Furthermore, we could have the ports arbitrarily generated per domain with their own script and have iptables just run the read only script for every domain when it fires.)

I am starting on an android port knocking solution as well. I can port knock using browser tabs and then quickly switching betwen them e.g. http://testthisout.com:6161 in one tab, and a similar url in another tab but with maybe :9960 and so on. But it's very tricky to do manually, lol. But it can be done in a jam if you have to ssh to a server or need to open 8443 for control panel access.

Scott, Mike, Brucelee, should I fire up a SourceForge? What does everyone think of the overall spec. I am not a programmer or admin, but I can help get things started.

[mikeshinn]

So my two cents:

Let me start off by saying I love portknocking, wiith that said, I also accept that it isn't as easy to implement as one might think from first glance. So, if you like it, go for it! But please be aware that port knocking is a very advanced firewalling method, and it breaks very easily. In simple terms, the server and client are the EASY part - the hard part is everything you don't and won't ever control that will stymie you. For port knocking to work, you need an unfiltered, unfirewalled connection between the user and your system. Otherwise, its a lot of headache - and I mean a LOT to get it to work reliably. If you think debugging firewall issues is hard, then you should never use portknocking. Its like the difference between shooting a bullet and throwing it. Portknocking can a bit too much for some to sort out and rely on consistently.

Portknocking works, for those that are not familiar with it, by requiring the user to connect to a series of "random" ports on your server, in a sequence to "authenticate" the connection, which then causes your server to "unfirewall" a port for that users IP (and only for their IP). Its a very clever idea for the very (very) security concious. For example, if I want to restrict connections to port 22 and my user have dynamic IPs I cant use traditional firewall rules (allow only from this source). If I want to use portknocking, then lets say for example if the user was coming from IP 1.2.3.4 and they wanted to connect to my server on port 22, I might require the user (this is a very simple example) to connect to port 10000, 100001 and 10002 in that order to "prove" they are legit and then my port knocking server would allow connections from 1.2.3.4 and ONLY from 1.2.3.4 to port 22.

Damn spiffy solution for that problem. The downside is what happens if the user can't connect to ports 10000, 100001 and 10002? Furthermore, for the portknocking to work I need to make sure the ports are random and can't be replayed or easily guessed - so they need to change. So I can't just pick something simple, so I need a large enough range and I have to hope the user can get to those ports all the time - otherwise they get locked out, and then your helpdesk gets irate calls from your users - difficult ones to diagnose too. So in reality, its difficult to rely on portknocking unless you can control the path and make sure nothing gets in the way (like another firewall, desktop, antivirus suite, hosting firewall, egress and ingress filtering, etc. or all of the above!)

And finally, its important to recognize what port knocking does and does not do - if you give away the sequence (say you have a free client) its totally useless, dont bother the bad guys know it too. You need the sequence to be a shared secret, which means all you are doing is authenticating your users, its an added layer, but its not a big layer. It won't protect you if the users credentials are stolen.

This is just from personal experience, it does work - but it also breaks. So, if you don't have a hosting firewall, or outbound egress filtering, or have to worry about third parties doing egress filtering (like on ships, at airports, in hotels, at customer sites, etc.), or desktop AV or firewall clients that will break outbound connections - yes it works great, and portknocking is a really really cool feature, but only when no one is filtering your connection - be prepared to debug these issues with your issues.

Airport wifi? Forget it, portknocking won't work all the time if they filter (and more seem to do it now than ever). Paranoid hotel? Yeah, locked out from your box. Stuck in a foreign country with a paranoid ISP? Yeah, SOL on logging into your box, I've been to some where it should be called the Republic of Filtering.

We found portknocking to be one of those cool things that just breaks way WAY too easily which is why we never rolled it into ASL. We even working on some neat Windows apps to do filtering of SMB connections via port knocking, again fragile - its good enough for clever engineers who are willing to debug these things, but absolutely unacceptable to the typical non-engineer user.

So, IMHO, and this is just Mike's opinion not Atomicorps official position - Portknocking is definitely an advanced firewalling trick - you need good troubleshooting skills to use it and lots of patience with desktop users and AV products that intercept outbound connections, and third party firewalls. I don't recommend it for those without time to work out the issues on their own.

So with that said, when we add it into ASL well want to make sure its clear to the admin this is one of those advanced features that requires troubleshooting on the users end and some forethought before implementing it. You don't want to cause heartache for someone. Good customer service ya know.

[ClearlyTechnical]

Um, this was one of the debates I was hoping to avoid

Anyway, it's been 5+ years, same iptables script. Most of my clients have in excess of 1,000,000 hits per year per domain and are heavily SEO'd.

As far as guessing is concerned, if you scan more than x ports in x period of time, you're blocked. I have the script set so the port seq has to happen fast. So it's like a port scan, but has to be perfect or they are locked out.

As far as outgoing firewall problems (them to us), that's not my problem.

As far as clients knowing the seq, I don't care. It's to keep the bots and kiddies at bay.

As far as having a client is concerned, yes, port seq is exposed if they want to sniff with Wireshark, etc. No biggy. The worst that happens is they open the server to expose ports that many already have open and covered by things like ASL and wrappers. So I am not losing sleep. I mean if someone wants to get my secret combo, in order to open 21,22, or 8443, then have at it.

It's simply a layer.

As far as implementing. It's pathetically easy, at least my script is. As far as breaking? I absolutely have not had a single problem on over 5 servers, many generations. Over 450 sites, nearly 500 Million hits per year ++

Nothing to brag about, but certainly more than a casual wordpress site on VPS.

Just to be clear, I know what I want. I know the risks. And I know the risks of not having anything.

The LDAP does little to protect the knock sequence, but it does help provide some security if the client were accidently put in the wrong hands. They would need to know the ftp user pass, or they would need to profile the software and know they are looking for ports. I mean this can go on and on and on, it's pointless to me.

Another idea I had was to self generate some port knocks and provide them for one time use only. The user would need to authenticate using their FTP account and we would let our client grab the sequence from a web url that is dynamically generated for that one session. The client would then knock.

Obviously, there are great out of band solutions, but most if not all require installing software and not just appending iptables. The model i prefer is to append iptables with the sequence.

In closing, if you want to really be concerned about security, then you should probably hookup a logic analyzer to the chips on your iphone, android, pc, mac, server devices, tv's, etc. and see what's being sent back to mama or collected.

how do you know when your microphone is being turned on, or when that camera is turned on. You can't know what's in the very server you are trying to protect. And if you host your server with a 1and1, etc., then you have no idea what they are doing to your box. At some point, you have to punt. I am simply saying that it's either port knocking, or nothing (for most of us) but wrappers (if that).

Also, I still have 22 and 8443 closed 100% only available by my knock. My clients don't use the control panel. They use their CMS and rarely, if ever use 21/ftp. So it also has to do with the needs of the admin. For encrypted ftp, I will need to be more liberal, but for now, generic is fine.

Mike is absolutely right with what he is saying, and I prefaced my post to avoid said. I just want the solution, I know the risk going in and I love the benefit of portknocking. It is especially helpful on my phone when I need to ssh, etc. Bringing my notebook with me is a thing of the past. I don't need it anymore now that the EVO is out (yes, blows away the iPhone. NOW THAT'S A DEBATE WORTH HAVING!! (I don't care...))

Brucelee sounds like myself in that he has some clients that might need ftp now and again, and he doesn't want to leave it hanging open. Portknocking is just such an answer.

I will pass on the sourceforge dilio for now. Keeping it simple and going forward.

[ClearlyTechnical]

Mike,

And another thing, my script could just as easily monitor webserver log for access to certain urls, or files that are randomly generated. Then you would only need port 80.

So instead of port knocking, it would be page/url knocking. Another option is portknocking known unfiltered ports. For example, if you can't port knock to 21, then opening it won't do you any good anyway?

So maybe it's something like 21, 80, 443, 21, 80, 80, 21, then wait 10 secs, then port 21 then 80, then 587. You get the idea. If I can't port knock 22, or 21, then sure as heck won't do me any good to open it!

For MOST small time noobs like myself, iptables based port knocking is a dream come true.

Because everyone was asleep at the switch during the net neutrality debates, don't expect comcast and company to be keeping all those pretty ports open forever. Game over on that front.

Oh well, it was fun while it lasted