| Posted by Markovic, 01-09-2010, 05:55 AM | | Hello,
I'm planning to do this but I have no idea how. Basically, I have 1 server on a non ddos protected network and I'm waiting my other server on a ddos protected network in the United States of America.
I have 1st server up and running already with apache as it's a shared hosting company. Now we would like to setup litespeed on the ddos protected server and use it as a proxy shield for our main server with apache installed. So basically, the traffic would have to pass thought litespeed server first and it would filter him together with network firewalls of DDoS protected network and then the clean traffic would come to our main shared server on a non protected network?
I would really appreciate any help regarding this
Thank you
Best regards
Edit/Delete Message
|
| Posted by Markovic, 01-09-2010, 05:57 AM | | Basically, I need a LSWS server running in front of the main server to filter the traffic together with network firewalls. Is it possible?
Edit/Delete Message
|
| Posted by khunj, 01-09-2010, 11:24 AM | | Yes it is : http://www.litespeedtech.com/how-tos.html#qa_sproxy
This applies for HTTP/HTTPS traffic only.
|
| Posted by Markovic, 01-09-2010, 11:36 AM | | Hello,
Does it mean network firewall on the proxy server are pointless then? It will only filter traffic which comes to litespeed web-server only?
|
| Posted by khunj, 01-09-2010, 12:10 PM | | It will be used. Incoming traffic will get through the protected network, then the firewall and LiteSpeed will forward it to the destination server. You may also need to change your Apache logfile format so that it will log the X_FORWARDED_FOR variable (the visitor IP) instead of the REMOTE_ADDR variable (the server IP).
All other traffic (POP, SMTP, FTP or any other non-HTTP/HTTPS protocol) will not be forwarded.
|
| Posted by PeakVPN-KH, 01-09-2010, 09:57 PM | | Doesn't work like that though. LiteSpeed can't actually end-to-end encrypt. There is a bug with LiteSpeed whereas if you have https on the destination and https listening, you can't proxy to the https on the end server.
We've reported it but no word on them fixing it. It may not be broken in LSWS but definitely in LSLB.
Just because you have LiteSpeed doing the proxy piece, don't expect it to handle ddos traffic. Be sure you have real "http" ddos protection. Base ddos protection in most datacenters are meant for ICMP/UDP/TCP-based non-complex attacks.
It's definitely not as simple as it may appear when you're talking real ddos attacks LSWS/LSLB without *real* complex protection on the front-end can't handle large SYN floods, delayed attacks, GET floods, etc. It will work on a small scale but not when they are >1,000PPS
Good luck.
Last edited by PeakVPN-KH; 01-09-2010 at 10:01 PM.
|
| Posted by ddosguru, 01-09-2010, 10:27 PM | | I don't think it's really a bug per se but rather by design. Litespeed's external application setup is SSL agnostic. So you're creating a secure listener that is passing the traffic back plain text. The SSL connection is negotiated between the client and the server which consequently is the proxy itself. You couldn't then renegotiate on the back end of the proxy, it just wouldn't work. The work around for this if you're proxying over the public internet and are concerned about PCI (or whatever other standards) you can without too much difficulty setup a PtP VPN.
You could use nginx, it's a bit different in behavior. You're able to specify the full URL (http or https) in the proxy configuration and it will pull the site content via the desired method and serve it back to the client either plain text or secured.
|
| Posted by mistwang, 01-10-2010, 03:17 AM | | A simple SSH tunnel is what we recommended.
|
| Posted by PeakVPN-KH, 01-10-2010, 06:09 AM | | Yes, we use nginx for this purpose and the tunneling is also an option. If required in such a way that it's a big enough deal we just GRE anyway.
It's not a huge problem but it's something I do dislike. I shouldn't have to go out of my way on a commercial product to use a open source product underneath or a tunnel because of the lack of support in the primary product. Such as LSLB, in my opinion, it should be changed. LSLB's primary function is to provide the functionality for private and public networks. It doesn't help the user if they have to use an alternative. Why not just make it where it work public and private?
|
| Posted by mistwang, 01-10-2010, 09:51 PM | | Our LSLB is actually targeted for private network in front of a web server farm. You have found it useful in proxy shield service over public network, that's good. We appreciated your feed back and we have add that to our to-do list, but we cannot give a feature high priority because one customer with two licenses needs it. It will be implemented sooner or later depends on the ROI.
|
| Posted by PeakVPN-KH, 01-10-2010, 10:37 PM | | Well the thing is that we have 9 other proxy servers, the rest utilize a custom nginx implementation. We understand that and we've stated that in tickets that it makes sense you don't have as much demand. Although, it is a limiter and we've sent the feedback in hopes to help the product.
Same as the other feature requests we've mentioned but we don't seem to be making much traction on any of the feature requests we've mentioned. Including the need for more than 1 CPU to be utilized. It is definitely a limiting factor when the standard in the industry is more or less, quad-core systems, but the product can't use more than 1 CPU.
Either way, this wasn't intended to debate the usefulness. The product is great but I do wish it received half the attention that LSWS does. In that case, it'd likely be utilized more. Likely increasing demand on your end, and helping the customers like us. Layer4 which was stated as feature long ago, which still isn't there or has been removed, is another big thing.
I don't think it just applies to people like us but the fact that we have 10-15+ licenses altogether with LiteSpeed should make us somewhat of a priority. Especially considering we've migrated a new server, on average, about once a week since we started using LiteSpeed. We still have 20+ more shared hosting servers, 600 or so VPS customers, and 200+ dedicated servers running Linux/FreeBSD in consideration of LSWS not including the 9 other LSLB migrations possible. Although, the lack of acceptance to suggestion concerns us. Maybe we're not big enough, maybe we won't spend enough... I guess we can't help that, if so.
On the other hand, that will not continue if we can't see where we're taken seriously on either future requests or feedback. We're not asking to rebuild the product, we're just asking for implementation of the same featuresets that are available to LSWS.
We do appreciate the response here and we'd even pay for custom coding to implement some of the features we'd like to see. This is in no way to bash you or LS, I do have a little concern about you stating the services we have with you. Although, we don't necessarily use them for our ethProxy product but I think it's a possibility one day. We'd love to use it for that purpose instead of continuing custom coding on our proxy/nginx implementations.
Overall we think LiteSpeed products are amazing. We also have been *extremely* happy with your help/support and response times. You've gone out of our way to assist with the couple problems we've had and that means a lot in itself.
Last edited by PeakVPN-KH; 01-10-2010 at 10:50 PM.
|
| Posted by mistwang, 01-11-2010, 10:47 AM | | What you want in LSLB is on our 2.0 release feature list. We listen to our customers' feedback, we may be able to work on it in one or two months, depend on our progress of LSWS 4.1 release.
We will take all the factors into consideration, the most important one is the overall impact to our business. Right now we need to focus on LSWS 4.1 release.
|
| Posted by PeakVPN-KH, 01-12-2010, 03:52 AM | | Thank you for addressing this. This is all we really wanted to know was the roadmap. It sounds excellent and we sincerely appreciate what you guys do.
Thanks again
|
|
 Add to Favourites
 Print this Article
|
