Author: Manoj Chauhan

如何使用系统安全TCP会绕

如何使用系统安全TCP会绕

简介: –

访问控制与TCP封装编译支持服务是通过在/ etc / hosts.allow和/ etc / hosts.deny中的文件。当连接试图的hosts.allow文件检查。如果线路匹配,连接是允许的。然后hosts.deny文件的咨询,如果某行匹配,连接被拒绝。如果没有匹配任何文件有发生,该连接是允许的。

只有建立授权使用横幅
如果配置如下所述,TCP包装将显示一个警告旗帜,任何用户试图连接到一个服务进行监察。下面的命令设置生成目录/ etc /横幅,其中包含的文件为每个服务的警告横幅文本。在这个例子中,横幅文本是“这个系统的使用仅限于授权用户。”请注意,警告字眼的旗帜,是网站的特定,但是,它至少应该强调,该系统的使用仅限于授权的人,并同意通过监督活动在登录到系统的暗示。
[@本地主机根]#/斌/ mkdir磷的/ etc /横幅
[@本地主机根]#/斌/回声“这套系统的使用限制在授权用户”“的/ etc /横额/
原型
[@本地主机根]#光盘的/ etc /旗帜,/ usr /斌/化妆f / usr/share/doc/tcp_wrappers-7.6/Banners.Makefile

拒绝一切除明确允许的是什么
为了落实安全最佳否认除明确允许的是什么,发出以下命令一切做法的立场。
[@本地主机根]#回声’所有:所有:产卵(/斌/回声娥’/本/日’“\ ñ%荤试图连接到%s
和被剥夺“\
“| /斌/邮件- s”的连接尝试到%s“根)&”> / etc / hosts.deny中

没有任何连接尝试在hosts.allow文件中列出的将被拒绝,一条消息将被记录到syslog权威性设施,和电子邮件将被发送到根。
允许访问那些需要它

编辑hosts.allow文件,并添加为每个哪些应该允许访问服务项目。一些例子如下(见hosts.allow进行了更详细的手册页)。

所有:本地:横幅的/ etc /横幅#所有来自当地的客户服务(主机名没有“。”)
sshd的:10.1.1.0/255.255.254.0:横幅的/ etc /横幅#之间的主机的IP地址10.1.1.0和10.1.2.0 SSH连接

谢谢
Manoj•肖汉

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