what are the absolute security guidelines for a server with LAMP stack?
Also, you must make sure that you have changed Apache's administrative interface default password. It's the easiest way to hack a LAMP server.
I recommend you try denyhosts if you are using ssh to auto-ban IPs that try to hack your server using basic scripting techniques.
Also be sure your site folders (i.e. /var/www/) are owned by the server "user" this is somtimes "www-data" or "nobody" and I think even occasionally "apache", depending on your distro etc. From then on, be careful about the permissions, I'm sure you can google for permissions for web folders.
Update early and often (make backups before you do).
Related
Hello or Good evening,
I actually work as a trainee for a small society and one of the improvement that they want, is to have a central authentication server. After some research, we chose to use UCS (Univention Corporate Server) which handle a lot of tools that they want to use in the future. And my problem begin here ...
I want to do a authentication at computer startup and only authentication, by my UCS (no roaming profile or else). I just need to get a ticket to allow the user to have a single sign on, on the intranet (to access NAS or cluster for example). I know that an LDAP server run on my UCS because when I use univention-ldapsearch, I can see a big file with a lot of information ... However, I don't know which LDAP server it is. I have kerberos v5, slapd, pam (maybe), so everything for an SSO and authenticate a user.
What they want to have is this :
--> When a user start a computer, they can connect with their login/password from everywhere.
--> The home directory have to stay ONLY on the main user computer. (so the fact that they can connect from everywhere is more for accessing to data in the intranet)
--> They can access, with SSO to all device (allowed for the user) in the intranet.
Now :
I know :
how to add a user / group. UCS is very user friendly for that,
that an LDAP server is running on UCS.
that I have samba but i'm pretty sure I can do it without using it.
I don't know :
how to set up the authentication at startup (nsss doesn't want to install on UCS and the documentation from UCS using PAM don't take missing files inside UCS -_- ...),
Which LDAP server is running (not an openldap (no directory from them.))
If it's possible to create (ONLY) if it's not the main user computer, an empty home directory and how.
I don't know if someone is familiar with this tech, I hope so because it's more like : "I need a tutorial" than "RTFD" where, a lot of point are missing.
I prefer to specify that we don't have an heterogeneous network, all computer are linux based.
If someone can help me,
Please,
I spent the day trying to do one startup connection and nothing ...
(I can connect from a browser but it's just to change password. And we really need a central authentication).
Thank's in advance,
Regards.
Hello Black Butterfly,
I am working at Univention and know that UCS is quite versatile, so you can connect pretty much any box to it.
UCS comes with OpenLDAP and Kerberos which are closely connected (and even the PAM-Stack uses Kerberos in the end). The important part to know is, that OpenLDAP is running on ports 7389 (LDAP with StartTLS) and 7636 (LDAPS).
Samba/AD is optional and "only" needed if you have Windows(-like) clients. But since you said that you only have Linux boxes, you don't need Samba/AD.
Now, if you want to connect Linux/Unix-like clients to UCS, you will have to ...
1. create a computer object for the client in the UCS LDAP/management system. There's a webmodule for that: http://docs.software-univention.de/manual-4.1.html#computers::hostaccounts
2. configure the client:
- use UCS as nameserver
- use UCS as timeserver
- configure the LDAP-client to use UCS as LDAP-Directory server
- configure the Kerberos-client to use UCS as KDC/Kerberos-Realm
- use some kind of identity/group caching and bridging software like NSS and/or SSSD
Unfortunately every Linux distro behaves differently regarding the nitty-gritty details.
There is a straight forward tutorial on how to do this with Ubuntu - it's mostly copy&paste:
http://docs.software-univention.de/domain-4.1.html#ext-dom-ubuntu
What Linux distro(s) are you using at your organisation for the Linux clients? Maybe I can give you better advice if I know.
Regarding home directories: Do I understand correctly, that you don't want "Roaming Profiles" or shared home directories? That would be the default.
For further advice, you can also always refer to the Univention forum.
I have a web application written in Perl using PostgreSQL.
When accessing the PostgreSQL database I need to supply both username and password. In order to have the password available for unattended start-ups of the system I need have that password embedded in my application or in a configuration file or as an environment variable configured in Apache.
In either case I have to have the password in clear text format somewhere.
How is it done in real web sites?
The most secure way to do it is to have a configuration file, and put that outside the public folders.
Make sure the password is somewhere the web server is never going to serve. If possible put it outside the webroot; if that's not possible,
Make sure the file containing the password is readable only by the user the web server runs as, and not writeable by anyone
Rotate it regularly, to minimise the impact if it does somehow leak
Make sure that the database user you're using has minimal permissions. Eg, for a Wordpress installation, create an account just for Wordpress to use, and give it access only to the databases it actually needs
Configure the database to only accept connections from the web server, to minimize the impact of a leak by preventing the attacker from being able to use that password from just any old random node on the net
You can "trust" your Web server's IP (or the localhost, if it's the same node) in your PostgreSQL's pg_hba.conf, and use no password at all. At least, I don't think it's less secure than storing the database password somewhere in the file system of your Web server.
Of course, you can try encrypting and obfuscating the password somehow. But this security through obscurity is not really a barrier for someone who has managed to get into your Web server, especially when all the Perl source code is there to read.
You can store the password in ~/.pgpass (for the web server user, of course). This is obviously not safe in shared hosting where the same user is used for many different websites, but if you have a dedicated setup it often works very well. See http://www.postgresql.org/docs/current/static/libpq-pgpass.html.
The important thing is to store it outside the general web tree.
Use Firewall IP:port filter at PostgreSQL Server and limit the access to only IPs of your web-server.
I have a client who, printed 10,000 advertisements with a specific password for an FTP account written on it lets say: horses1, for many reasons I have had to migrate her over to a new host, she chose mediaTemple, and bought an account.
The Login is now horses1#HER-DOMAIN.com, which is a problem, becuase of all her print ads.
I'm thinking this can be fixed with mod_rewrite and htaccess, but I'm pretty sure apache2 and ftp are different programs... I'm really screwed if I cant fix this....
EDIT:
is there a way to create an FTP user alias?
Apache is just a HTTP server. But maybe mod_ftp and its StripHostname option can help you.
Apache is an HTTP server (which, due to being magic, can be made to act like pretty much any kind of TCP/IP server you like, but almost never is) so won't be responsible for the FTP.
The FTP will almost certainly be supplied by a different server, and you'll need to find out what that is and what level of configuration control you have on it before you can proceed any further.
FTP sites that need #domain are almost always shared hosts.
You will not be able to make configuration changes to make it work without.
Every LAMP or XAMPP writeup or tutorial I see says "Not for production use", so what do I use for production?
you use apache, php and mysql installed as they should be for production. xampp is all those things in one package with basically no set up security .. root passwords are empty .. users are well known .. but the components are the same as the ones you would use if you downloaded them each ..
The XAMPP philosophy says:
The philosophy behind XAMPP is to build an easy to install distribution for developers to get into the world of Apache. To make it convenient for developers XAMPP is configured with all features turned on.
The default configuration is not good from a securtiy point of view and it's not secure enough for a production environment - please don't use XAMPP in such environment.
So it’s primarily designated as a development environment and not as a production environment.
Given the right installation options, you can use them as a starting point for a production server. But there are some holes to fill in, mainly wrt security. The disclaimers you refer to are (wisely) to make sure you are wary and suspicious of what you start with (and also make sure no one can claim they supplied you with something dangerous without letting you know, so don't blame them if Bad Things happen.)
It's like selling you a car without seatbelts.
But what you learn, and the solutions you develop, are generally fully compatible with a "real" server.
XAMPP installation is easy as compared to LAMP. If you are on development server it makes no difference, but if you are on production server than it is good to do from basic instead of relying on 3rd party and you will get exact services you want on your production server, no extra services which can lower down your production server performance.
And try to keep same setup on development and production server, it will make sure that if application is running on development server will also run on production without doing any extra settings.
For production you've make your own configuration, it depends on visitors count, RAM installed on your server, scripts you're using. F.E. You need only 5 PHP extensions for Wordpress, but if you're using Woocommerce you need more PHP memory, for multiple sites you've use VirtualHosts, and if you have not domains registered also user UserDir modules.
All I've said is only examples, you must know your script requirements, install everything is not good idea.
Subversion has multiple server types:
svnserve daemon
svnserve via xinetd
svn over ssh
http-based server
direct access via file:/// URLs
Which one of these is best for a small Linux system (one to two users)?
http:
very flexible and easy for administration
no network problems (Port 80)
3rd party authentication (eg. LDAP, Active Directory)
Unix + Win native support
webdav support for editing without svn client
slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
especially slow on history
no encryption of transferred data
https:
same as http
encryption of transferred data
svn:
fastest transfer
no password encryption in std. setup: pw are readable by admin
firewall problems as no std.port is used
daemon service has to be started
no encryption of transferred data
svn+ssh
nearly as fast as svn://
no windows OS comes with build in ssh components, so 3rd party tools are essentiell
no daemon service needed
encryption of passwords
encryption of transfer
1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.
However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.
My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)
If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.
Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.
I've always used XInetD and HTTP.
HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).
It really depends on what restrictions (if any) you're under.
Is it only going to be on a LAN? Will you need access outside of your LAN?
If so, will you have a VPN?
Do you have a static IP address and are you allowed to forward ports?
If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).
Most other options are more effort with less benefit.
It's an SVN Repo -- you can always pack your bags and change things if you don't like it.
For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.
So, I'd recommend:
http for anonymous connections
svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)
I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.
If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.
If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.
Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.
I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.
I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.
Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.
As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.
I am curious why NOT FSFS?? Important information - I am managing Windows systems.
I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.
We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.
Advantages:
No backend required (or dedicated server)
Fast and reliable
Hook scripts are supported
NTFS permissions are used
Easy to understand, easy to support, easy to manage
Disadvantages:
Not so easy access from outside your network (VPN)
Permissions only on repository-level (Read, Read/Write)
Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)
Martin