|
DarkLotus posted:LOL, goon fail! The new updates we pushed out broke the goon plans Looks like it's not entirely fixed... 
|
#
?
Nov 29, 2015 07:23
|
|
|
|
| # ? May 29, 2024 03:09 |
|
|
nuvan posted:Looks like it's not entirely fixed... Send me a PM or post in my thread, this isn't really the thread for it.
|
|
#
?
Nov 29, 2015 15:06
|
|
|
Well lets encrypt went beta/live and pretty good albeit some weird quotas on IPv6 addressing (especially if you are on Linode). Puny code is not available in the beta, and Nginx is not supported for automated configurations. I am surprised Nginx has pretty awful non-obvious SSL configuration, everything else is not too bad. I have A+ rating on SSL Labs SSL Server Test but it appears that means all old versions of MSIE are blocked 
MrMoo fucked around with this message at 01:07 on Dec 5, 2015 |
|
#
?
Dec 5, 2015 01:05
|
|
|
considering anything below IE11 is officially EOL in a month
|
|
#
?
Dec 5, 2015 01:11
|
|
|
I just tested a server at work and it managed an A- grade supporting all the way back to IE8/XP. That rules out SNI though for SSL virtual hosting so I don't care too much for that.
I think the certificate chain support for OCSP stapling is a bit messed up in Nginx with Let's Encrypt. I'm not going to run it on anything important for a while.
|
|
#
?
Dec 5, 2015 01:24
|
|
|
MrMoo posted:
This isn't configured properly for www.
|
|
#
?
Dec 5, 2015 01:48
|
|
|
Rufus Ping posted:This isn't configured properly for https://www. What should it be doing? There is vanilla http://www.yorkion.com redirecting to https://yorkion.com. If I need https://www.yorkion.com to redirect to https://yorkion.com I need to register another certificate against Let's Encrypt 
|
|
#
?
Dec 5, 2015 04:42
|
|
|
MrMoo posted:What should it be doing? There is vanilla http://www.yorkion.com redirecting to https://yorkion.com. If I need https://www.yorkion.com to redirect to https://yorkion.com I need to register another certificate against Let's Encrypt A certificate for https://www.yorkion.com will cover yorkion.com. Just not vice versa. I see this all the time, people order certificates without the www and then want it reissued later.
|
|
#
?
Dec 5, 2015 04:56
|
|
|
The docs for Let's Encrypt now specify https://www.example.com and example.com so a bit better than before. There is a command line option "--duplicate" to pull in extra sub-domains on certificate and raises a dialog if there are new domains. The SSL Server Test tool seems happier now, thanks 
|
|
#
?
Dec 5, 2015 06:11
|
|
|
If anyone is interested I am using the configuration posted by Croc Monster earlier in this thread. OCSP stapling requires a certificate in the Nginx default_server, I'm using Nginx on CentOS 7 so it is a rather old 1.6.3 but includes support for SPDY 3.1. code:The include file: code:
|
|
#
?
Dec 5, 2015 17:37
|
|
|
Glad this was of use! I remember the discussion here. Just to confirm, I still use the same config on various sites, still have an A+ rating as well.
|
|
#
?
Dec 5, 2015 17:42
|
|
|
The annoying bit afterwards is now that all embedded content needs to be HTTPS to work in modern browsers, which usually means changing all links from "http://example.com/blaa" to "//example.com/blaa". I'm using a referral link from http://ipv6-test.com but alas they don't have HTTPS on IPv6 so I had to cheat and copy their image.
|
|
#
?
Dec 5, 2015 17:47
|
|
|
Croc Monster posted:Glad this was of use! I remember the discussion here. I'm still using this as well 
|
|
#
?
Dec 5, 2015 19:29
|
|
|
^^^ awesome! This is actually a timely (re)discussion of SSL on nginx, as the 1.9 branch of nginx now includes http2 support in lieu of SPDY. Good article from cloudflare here: https://blog.cloudflare.com/tools-for-debugging-testing-and-using-http-2/ Article from nginx itself here: https://www.nginx.com/blog/nginx-1-9-5/ According to the nginx article there's some issue with certain cipher lists. I'm going to move from 1.8 to 1.9 this week, disable speedy, and switch to http2. I'll then make sure I can still get an A+ rating. If I run into trouble with the cipher list, I'll post back a new config here. Trip report either way, even if I roll it all back.
|
|
#
?
Dec 8, 2015 00:02
|
|
|
Trip Report All of five minutes, and I'm now http2 enabled. The cipher list is fine, still have an ssllabs A+ rating, and the chrome SPDY/http2 checker extension mentioned in the cloudflare article confirms that I'm connected via http2. The only gotcha here is that in order to upgrade to 1.9 from 1.8, you need to switch from the stable channel to the "mainline" one. This could very well be a deal breaker for you.
|
|
#
?
Dec 10, 2015 02:56
|
|
|
MrMoo posted:I am surprised Nginx has pretty awful non-obvious SSL configuration, everything else is not too bad. read the docs, it's actually not that difficult at all and far more powerful than apache's imo. pretty much everything you need will be ssl_* Croc Monster posted:Trip Report mainline is fantastically stable in my experience, and i've been running it since 1.9.0 without any issues that i can recall this is anecdotal of course, but it probably won't be an issue, especially not for personally hosted sites RISCy Business fucked around with this message at 15:29 on Dec 14, 2015 |
|
#
?
Dec 14, 2015 15:15
|
|
|
piss angel posted:read the docs, it's actually not that difficult at all and far more powerful than apache's imo. pretty much everything you need will be ssl_* I expected to be able to set some global ssl variables like the other http parameters, not having to include an entire file for every virtual host.
|
|
#
?
Dec 14, 2015 17:46
|
|
|
You can set cipher suite, dh params etc globally then just set key pairs for per vhost
|
|
#
?
Dec 14, 2015 19:13
|
|
|
^^^^ this.piss angel posted:read the docs, it's actually not that difficult at all and far more powerful than apache's imo. pretty much everything you need will be ssl_* Yeah, I was on stable more by happenstance than anything. Never heard of any problems with mainline myself either.
|
|
#
?
Dec 14, 2015 20:11
|
|
|
Question about STREAMING VIDEO. How do those .tv sites work where someone uploads a stream of a video or event, and then people can view it. What kind of bandwidth does each person watching take? Assuming a 720p HDTV stream I guess. Is there a turnkey software package you can install?
|
|
#
?
Dec 14, 2015 22:53
|
|
|
you can literally just use nginx to accept a stream, and rebroadcast it to everyone connected to it - dont' really need a software.
|
|
#
?
Dec 15, 2015 02:04
|
|
|
Building on that, OBS Project ties in very nicely with nginx.
|
|
#
?
Dec 15, 2015 19:08
|
|
|
re: nginx and obs https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/ RISCy Business fucked around with this message at 19:28 on Dec 15, 2015 |
|
#
?
Dec 15, 2015 19:26
|
|
|
deep impact on vhs posted:re: nginx and obs This is kick rear end. If I wasn't in love with YouTube streaming, I'd do the hell out of this.
|
|
#
?
Dec 22, 2015 17:42
|
|
|
I'm home for Christmas and my mom has asked to setup a WordPress blog that she can use to sell things and show her art and poems to her friends. Is there hosting out there that will keep WordPress updated (and any other technical maintenance) for her so that she never has to worry about anything except uploading content? She's not going to be able to manage a WordPress installation herself.
|
|
#
?
Dec 24, 2015 19:15
|
|
|
wordpress.com But maybe she's using wordpress as a generic term for website or blog or cms and something else would be better
|
|
#
?
Dec 24, 2015 19:19
|
|
|
Yeah, I suggested tumblr or Blogger and she wanted something different and showed me a free wordpress theme that looks like it does what she wants. I'm a little hesitant about setting her up with a free theme maintained (or not maintained) by god-knows-who, though. :/
|
|
#
?
Dec 24, 2015 19:26
|
|
|
Safe and Secure! posted:Yeah, I suggested tumblr or Blogger and she wanted something different and showed me a free wordpress theme that looks like it does what she wants. I'm a little hesitant about setting her up with a free theme maintained (or not maintained) by god-knows-who, though. :/ wpengine et al but it'll cost you disgusting, insane amounts of money
|
|
#
?
Dec 24, 2015 20:23
|
|
|
WordPress will handle minor updates automatically. And there's a plugin to coalesce major updates into this automatic update process.
|
|
#
?
Dec 25, 2015 07:36
|
|
|
nem posted:WordPress will handle minor updates automatically. And there's a plugin to coalesce major updates into this automatic update process. The catch to that is that you have to give WordPress write access to itself, which is a patently bad idea if you care at all about not getting owned.
|
|
#
?
Dec 25, 2015 17:18
|
|
|
Thalagyrt posted:The catch to that is that you have to give WordPress write access to itself, which is a patently bad idea if you care at all about not getting owned. Would you rather take 1 fist or 2 fists up the rear end? Neither solution is optimal; pick the best worst solution. At least in this setup you can be proactive, rather than reactive. More importantly, you have less to think about, which is the OP's goal. Alternatively, a separate user apart from the web server can own the files and that information stored in wp-config.php for automatic FTP updates. Your tradeoff is that FTP login info for this user is stored in wp-config.php, which again can lead to getting owned... Then again, if a hacker has access to one ingress, backdoor installation is so drat trivial.
|
|
#
?
Dec 25, 2015 23:22
|
|
|
nem posted:Would you rather take 1 fist or 2 fists up the rear end? Neither solution is optimal; pick the best worst solution. At least in this setup you can be proactive, rather than reactive. More importantly, you have less to think about, which is the OP's goal. Nah, I'd rather give WordPress no write access other than wp-content/uploads, and explicitly disable PHP execution in wp-content/uploads. Upgrade it manually, either by relaxing permissions temporarily (if you're lazy) or ideally by pushing out an entirely new codebase as a new atomic release using something like capistrano + git, symlinking content directories in from a common shared folder. The benefit of that, of course, being that your git repo instead of web server is authoritative for what code belongs on your web server. As soon as your application has write access to its own codebase through any means you're completely done for. Doesn't take much netsec/ops experience to know that... Thalagyrt fucked around with this message at 00:06 on Dec 26, 2015 |
|
#
?
Dec 26, 2015 00:03
|
|
|
Thalagyrt posted:Nah, I'd rather give WordPress no write access other than wp-content/uploads, and explicitly disable PHP execution in wp-content/uploads. Upgrade it manually, either by relaxing permissions temporarily (if you're lazy) or ideally by pushing out an entirely new codebase as a new atomic release using something like capistrano + git, symlinking content directories in from a common shared folder. The benefit of that, of course, being that your git repo instead of web server is authoritative for what code belongs on your web server. A hole elsewhere in its codebase will still allow arbitrary execution regardless of whether uploads/ or themes/ are satisfactorily locked down. You might halt its spread, but compromised accounts or a newfound spam relay are just as obnoxious as a security relapse. The only practical solution is vigilance. Always be on top of updates. You can make the exposed surface smaller, but a hole is a hole and in 13 years I can only attest to one thing: end-users are a mixed bag of ability. Never assume too much.
|
|
#
?
Dec 26, 2015 00:30
|
|
|
nem posted:A hole elsewhere in its codebase will still allow arbitrary execution regardless of whether uploads/ or themes/ are satisfactorily locked down. You might halt its spread, but compromised accounts or a newfound spam relay are just as obnoxious as a security relapse. The only practical solution is vigilance. Always be on top of updates. You can make the exposed surface smaller, but a hole is a hole and in 13 years I can only attest to one thing: end-users are a mixed bag of ability. Never assume too much. The vast majority of vulnerabilities in WordPress have boiled down to arbitrary file write vulnerabilities, which then get chained with another HTTP request to execute injected code. Preventing WP from writing executable code stops those dead in their tracks. The other large portion of vulnerabilities are SQLi attacks, and yes, for those you need to be vigilant and keep things updated. You can totally automate that without giving WP write access to itself, though. Not through WordPress itself, but a bit of Chef solo, or hell, even a simple bash script will do the job. Thalagyrt fucked around with this message at 00:35 on Dec 26, 2015 |
|
#
?
Dec 26, 2015 00:33
|
|
|
Run a good modsec ruleset and keep WP up-to-date. Don't keep around old plugins and themes because they are exploitable even when inactive. Those 3 will prevent the huge majority of issues.
|
|
#
?
Dec 26, 2015 02:34
|
|
|
Just venting... I've had a VPS with A Small Orange for about 18 months. My server has been down and inaccessible for two days now. ASO was cool with helping me get everything all set up when I first started with them, but they've had multiple outages for significant periods of time since then and this one is the last straw.
|
|
#
?
Dec 29, 2015 19:50
|
|
|
Do Not Resuscitate posted:Just venting... That's EIG for ya!
|
|
#
?
Dec 29, 2015 20:03
|
|
|
Do Not Resuscitate posted:Just venting... Thalagyrt is right, there isn't a single hosting provider purchased by EIG that has improved or stayed the same. They have all gone downhill in quality on all fronts according to what I've heard from previous EIG brand customers.
|
|
#
?
Dec 29, 2015 20:23
|
|
|
DarkLotus posted:Thalagyrt is right, there isn't a single hosting provider purchased by EIG that has improved or stayed the same. They have all gone downhill in quality on all fronts according to what I've heard from previous EIG brand customers. I'm gonna sign up with you guys as soon as ASO comes up again. So maybe by the end of the week.
|
|
#
?
Dec 29, 2015 21:06
|
|
|
|
| # ? May 29, 2024 03:09 |
|
|
I wonder how Arvixe is doing after the EIG buyout earlier this year. Surely it... *checks WHT shared hosting subforum, which I haven't visited in months* Oh. Yep. Bonus points for an ASO thread on the first page too.
|
|
#
?
Dec 29, 2015 21:29
|
|