Author: Manoj Chauhan

How to use TCP Wrappers for system security

How to use TCP Wrappers for system security

Introduction:-

Access control to services compiled with TCP wrappers support is implemented by the /etc/hosts.allow and /etc/hosts.deny files. When a connection attempt is made, the hosts.allow file is checked. If a line is matched, the connection is allowed. Then the hosts.deny file is consulted, if a line is matched, the connection is denied. If no matches have occurred in either file, the connection is allowed.

Create Authorized Use Only Banners

If configured as described below, TCP wrappers will display a warning banner to any user attempting to connect to a service it monitors. The following set of commands generate the directory /etc/banners, and the files therein contain warning banner text for each service. In this example, the banner text is “Use of this system is restricted to authorized users.” Note that exact wording of a warning banner is site specific; however, it should at least emphasize that the use of the system is restricted to authorized persons and that consent to monitor activities is implied by logging in to the system.

[root@localhost]# /bin/mkdir -p /etc/banners
[root@localhost]# /bin/echo “Use of this system is restricted to authorized users” > /etc/banners/
prototype
[root@localhost]# cd /etc/banners ; /usr/bin/make -f /usr/share/doc/tcp_wrappers-7.6/Banners.Makefile

Deny Everything Except What is Explicitly Allowed

In order to implement the security best practice stance of deny everything except what is explicitly allowed, issue the following command.
[root@localhost]# echo ‘ALL: ALL: spawn (/bin/echo -e ‘/bin/date'”\n%c attempted connection to %s
and was denied” \
> | /bin/mail -s “Connection attempt to %s” root) &’ > /etc/hosts.deny

Any connection attempt not listed in the hosts.allow file will be denied, a message will be logged to the syslog auth facility, and an email will be sent to root.
Allow Access to Those Who Require It

Edit the hosts.allow file and add a line for each service to which access should be allowed. A few examples are shown below (See the man pages for hosts.allow for more detail).

ALL: LOCAL : banners /etc/banners            # All services from local clients (hostnames with no “.”)
sshd: 10.1.1.0/255.255.254.0 : banners /etc/banners # SSH connections from host IP addresses  between 10.1.1.0 and 10.1.2.0

Thanks
Manoj Chauhan

Good practices for apache & php

Good practices for apache & php

Introduction –

To conclude the discussion about session management, here are some best practices to demonstrate that a robust scheme requires serious thinking:
•    Create a session token upon first visit.
•    When performing authentication, destroy the old session and create a new one.
•    Limit session lifetime to a short period (a few hours).
•    Destroy inactive sessions regularly.
•    Destroy sessions after users log out.
•    Ask users to re-authenticate before an important task is performed (e.g., an order is placed).
•    Do not use the same session for a non-SSL part of the site as for the SSL part of the site because non-SSL traffic can be intercepted and the session token obtained from it. Treat them as two different servers.
•    If cookies are used to transport session tokens in an SSL application, they should be marked “secure.” Secure cookies are never sent over a non-SSL connection.
•    Regenerate session tokens from time to time.
•    Monitor client parameters (IP address, the User-Agent request header) and send warnings to the error log when they change. Some information (e.g., the contents of the User-Agent header) should not change for the lifetime of a session. Invalidate the session if it does.
•    If you know where your users are coming from, attach each session to a single IP address, and do not allow the address to change.
•    If you can, do not accept users coming through web proxies. This will be difficult to do for most public sites but easier for internal applications.
•    If you can, do not accept users coming through open web proxies. Open proxies are used when users want to stay anonymous or otherwise hide their tracks. You can detect which proxies are open by extracting the IP address of the proxy from each proxied request and having a script automatically test whether the proxy is open or not.
•    If you do allow web proxies, consider using Java applets or Flash movies (probably a better choice since such movies can pretend to be regular animations) to detect the users’ real IP addresses. It’s a long shot but may work in some cases.
•    Web users can upload only jpeg, gif, png files not php extension
•    We can place a blank index page in each directory in question and users can not execute php etc scripts from the image folders or image/document upload folders.
•    Upgrade apache current version (2.0) to newer version (2.2)

Thanks
Manoj Chauhan