If you were the administrator of an Apache web server, what protocol(s) would you prefer to provide, for the web developers to upload static files (html/gif/css/...), with the goal of maximum security ?
If you were the web developer/graphic designer, what protocols would you prefer to be available at the Apache server, to upload static files ?
SCP is what I'd go with.
You can even use Filezilla for it and pretend it's unsecure FTP: http://filezilla-project.org/
SSH/SCP. It's simple, fast, free, and can be as secure as you want. Alternatives are FTP (hahahaha, yeah right) and POSTing files over HTTPS.
I give web developers instructions on using an sftp/scp client and a login shell using scponly. That way they get their access to upload files, but I have fewer concerns about them doing bad things to the webserver.
I use ssh config to limit users to sftp on a development server then use version control to review the changes and move them to production with got format-patch
We deploy using Capistrano, which afaik does all its work via git (over SSH) - at least, in our deploy script it is.
Related
I read this recommendation in the installation guidelines from Symfony:
1. Use the same user for the CLI and the web server
In development environments, it is a common practice to use the same UNIX user for the CLI and the web server because it avoids any of these permissions issues when setting up new projects. This can be done by editing your web server configuration (e.g. commonly httpd.conf or apache2.conf for Apache) and setting its user to be the same as your CLI user (e.g. for Apache, update the User and Group values).
This is only good practice for local development environments or should I do this on my public test & prod server as well? To me this doesn't seem as a very secure configuration?
Questions Can I safely follow this recommendation on a prod server? What are the risks, if there are any?
This recommendation give an easy alternative to avoid the common permissions problem.
I would prefer setup the web server permissions correctly once and keep the default webserver group/user.
The documentation has a good guide to achieve this.
EDIT
You shouldn't make your CLI user as your webserver user, especially in production because it opens you up to all kinds of potential abuse.
The whole point of the www-data user is that it is an unprivileged user, by default not able to write to any file .
Your CLI user is most often root, also keep the www-data user as the web server owner protect you from bad manipulations that can involves a lot of problems and potential security issues.
Plus, if your webserver is under an attack, other services which depends on the same user can be also compromised.
Server daemons accessible from the outside network (such as the web server) typically run as an unprivileged user so that in the event that they are hacked due to a vulnerability, the possible things the attacker can do is minimal.
Im working on a project that is currently using goftp found in goftp to upload some files into a website directory where it is used and viewed by the website.
I am know questioning the security of this setup, so I have looked into ssh and sftp for golang, but I'm running into problems and it's just a big headache, since I'm new with golang.
My question is, what are the security threats or problems of just using goftp and are there more secure alternatives?
Thanks in advance!
All plain FTP servers are inherently insecure as they authenticate using plain text over an unencrypted link. This means that anyone on the same network (in particular WiFi networks) can sniff the network traffic and easily extract the username and password used to authenticate.
You've already mentioned some of the recommended alternatives, SSH and SFTP. SSH provides the means to use SCP to transfer files securely. SFTP also uses the underlying transport provided by SSH. There is also FTPS which uses standard FTP over an SSL encrypted connection.
Have a look at this link for more information on the differences between the protocols.
In researching Go libraries for FTP I came across a mention that the github.com/jlaffaye/goftp library breaks on multi-line responses.
It's highly recommended to use a more secure protocol than plain FTP so you would be better served by looking at SCP/SFTP/FTPS solutions. Here's a Github Gist claiming to be an example of using SCP in Go. That could be a good starting point.
I want to write a small back-end REST server using Play! Framework 2.1.3. This server will only serve WS requests, and all communication to it must be made over SSL. For this reason, I don't want to have an HTTP port open for this server at all.
I've seen this question regarding SSL on various Play! branches, and according to the linked discussion, the only way to open SSL port (which worked for me) is to add JAVA_OPTS before running the server, like so:
JAVA_OPTS=-Dhttps.port=9443 play run
This setting opens both HTTP and HTTPS ports for communication.
My questions are:
Is it possible to open the server only for SSL communication? How?
Is there a configuration file where I put this setting?
Thanks!
This is super easy with Play 2.2, not sure it works on 2.1.3, I didn't see it in the 2.1.x docs...but was in the 2.2.x docs...so give it a shot, it might be implemented.
Throw this in your configuration file :
http.port=disabled
Or you could run it with the command line option :
-Dhttp.port=disabled
http://www.playframework.com/documentation/2.2.x/ConfiguringHttps
I need a way to use Glassfish 3.1.2.2 admin service (REST call to deploy and configre) from a remote machine and from local machine (command line and applications).
It is clear that for remote access it is necessary to enable secure admin. If we enable secure admin it will break all local access from applications. These application can not be changed to using https to access the admin service. Only thing I can change is that we can use a different port.
I see two possible ways for me:
Using a hack. So I can administrate with secure administrate disable. So I can use plan http. For use a possible solution, because this machine used internally in a test environment.
Configure Glassfish that we can use admin service remote via secure access https and from a local environment with http.
We prefer solution 1, because it fit better in our environment and we have lesser effort. At the moment I see no way or exist a solution (not for production)?
I tried something for solution 2, simular to http-listener-1 http-listener-2. So use two ports 4848 for local unsecure access and as example 4949 for remote secure access.But I always fail with configuration. So I start with a step by step configuration. First enable admin interface oon two ports and as second step I want to add the secure access to the new port admin-listener. But I got only one of the ports working.Please can anyone help me with target configuration? Any domain.xml will be welcome.
Thanks florian
You can try to use SSH and run asadmin utilities from remote machine.
Please correct me if I am wrong about my understanding of mod_dav_svn, which is that it basically serves 2 purposes:
Expose the SVN repository (on the filesystem) to clients, which can be either:
repository browsers (e.g. web)
the 'svn' command itself, which is a client command line program
Act as a repository browser to make the repository viewable in a convenient way
Now for point 1, are my following assumptions correct?
Anytime a repository is exposed using mod_dav_svn, the http:// or https:// form of accessing the repository is used
If using svnserve, the svn:// form of accessing the repository is used
In this case, mod_dav_svn would serve no additional use
For point 2, if using Trac's repository browsing functionality, there is no additional use for the repository browsing functionality offered by mod_dav_svn?
Does mod_dav_svn serve any other purpose I haven't outlined here? Asked another way, is there any disadvantage to going with svnserve and Trac?
I ask because I get the impression that mod_dav_svn is very commonly used, so I wonder what I'm missing.
Forget Point #2: HTTP Browsing. That's just a slight bonus. It doesn't replace your need for something like Fisheye, ViewVC, or (my favorite) Sventon.
There are some disadvantages of using Apache's http for your Subversion server:
It's slower
It's harder to setup
Then, there are advantages:
It uses a standard port (80) that's not normally blocked by firewalls.
It can be integrated with LDAP and Active Directory
You can use HTTPS which will encrypt updates and checkouts (including user passwords).
You can have multiple repositories use the same Apache httpd instance. With svnserve, you can only do a single repository per instance and if you have multiple repositories on one system, you'll have to run each svnserve process on a non-standard port.
My personal take: If you are doing a corporate environment, the advantages of using the HTTP or HTTPS protocol way outweigh the disadvantages. If you are talking about a small repository and you and your friends, I run svnserve simply because of the lower overhead and easier setup. However, in those circumstances, I just use Github and not worry about it.
I run Subversion as my personal source control system on my machine, and I use svnserve in that instance.
Thanks, some follow up questions. 1) When I access a URL on my svn server as svn://server/repo, isn't that using port 80 as well? 2) If LDAP integration can't be done for svnserve, is the only way users can authenticate is if they're in the file referred to by password-db in svnserve.conf for svn:// or have a shell account for svn+ssh://? 3) Can't the same protection offered by https:// be offered by svn+ssh://, or is there a difference? (Sorry I can't put paragraphs here it submits every time I hit enter am I doing it right.) –
It's using port 3690 by default. This can be changed when you run svnserve, but then your svn URL has to reflect that too.
Pretty much true. Most places that use svnserve use the passwd file. However, since version 1.5, you can use SASL. However, I have never seen anyone use it.
Yes, ssh+svn:// does offer encrypted packets. However, SSH can be tricky to implement. Basically, the svnserve process has to be spawned and run for that particular user. That means each user needs direct read/write access to the repository. You need to setup umask for each user and create a Subversion Unix group everyone belongs to. Then, since these users have direct access to the repository files, keep them from logging onto the repository server. The Online Manual has complete details. But, in the end, it only works on Unix servers and Unix clients. Windows clients don't have SSH on them, and would have to install that. I've tried it a few times, but https:// is much easier.
The simplicity of svnserve makes it a no brainer for quick and dirty installs, especially if you are deploying on Windows.
However, the moment that you need to memorize a lot of passwords, and would wish that the Subversion repository use the same SSO mechanism that is used in the organization, using Apache's authentication mechanisms coupled with mod_dav_svn helps a lot.
Prior to Subversion 1.7, mod_dav_svn's performance was said to be atrocious and known to be slower than svnserve. Subversion 1.7 supposedly offers a faster and simpler HTTP protocol which should make mod_dav_svn use more palatable.