Month: February 2010

How to use socat with haproxy stat

How to use socat with haproxy stat

*** Introduction –

All you know about the haproxy, that its the one of the good opensource load balancing software and to check the fun stats of haproxy here we using ‘socat’ – Multipurpose relay (SOcket CAT)

* What is socat?

Socat  is  a  command  line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from a large set of different types of data sinks and sources (see address  types),  and  because  lots  of address options may be applied to the streams, socat can be used for many different purposes. (see more info at ‘man socat’ 🙂 or at
* How to use ‘socat’ with haproxy stat

Step 1) Download ‘socat’ from  latest version ~ “socat-2.0.0-b3.tar.gz”

ravi@arun:~$ wget

ravi@arun:~$ tar xvzf socat-

ravi@arun:~$ cd socat-

NOTE ~ No need to install the ‘fipsld’ package if you got the below msg after running the ‘make’ just following steps for

compiling socat….

FIPSLD_CC=gcc fipsld -O -D_GNU_SOURCE -Wall -Wno-parentheses  -DHAVE_CONFIG_H -I.  -I.   -c -o socat.o socat.c
/bin/sh: fipsld: command not found
make: *** [socat.o] Error 127

ravi@arun:~$ ./configure –disable-fips
ravi@arun:~$ make

To install it login as root
ravi@arun:~$ su –

ravi@arun:~# make install

Step 2) Now you need to add stats socket PATH in Haproxy configuration and restart haproxy as per shown in following example,

where I have added it under in ‘global’ setting –

ravi@arun:~# more /etc/haproxy/myhaproxy.cfg

#———–Start of haproxy Config file————–
log   local0
log   local1 notice
#log loghost    local0 info
maxconn 25000
user ravi
group ravi
stats socket    /tmp/haproxy
option          contstats
timeout         connect 5s
timeout         client 25s
timeout         server 25s
maxconn         100

listen ravitestbed IP
mode            tcp
balance         roundrobin
server          web1
server          web2

listen stats
mode            http
#stats          uri /stat  #Comment this if you need to specify diff stat path for viewing stat page
stats enable
stats auth admin:admin ##Auth user pass

#———–End of haproxy Config file————–

Step 3) Used /tmp/haproxy. Now you can send the commands to get stats from HAProxy –

Now time to use socat

ravi@arun:~# echo “”  | socat unix-connect:/tmp/haproxy stdio
Unknown command. Please enter one of the following commands only :
show info   : report information about the running process
show stat   : report counters for each proxy and server
show errors : report last request and response errors for each proxy
show sess   : report the list of current sessions

This will dump (possibly huge) info about all know sessions.

ravi@arun:~$ echo “show sess” | socat unix-connect:/tmp/haproxy stdio
0x9ee3520: proto=tcpv4 src= fe=ravitestbed be=ravitestbed srv=arun as=0 ts=08 age=4s calls=3
rq[f=009202h,l=0,an=00h,rx=20s,wx=,ax=] rp[f=009202h,l=0,an=00h,rx=20s,wx=,ax=] s0=[7,8h,fd=1,ex=] s1=[7,8h,fd=2,ex=] exp=20s
0x9eeb8e8: proto=tcpv4 src= fe=ravitestbed be=ravitestbed srv=arun as=0 ts=08 age=4s calls=3
rq[f=009000h,l=0,an=00h,rx=20s,wx=,ax=] rp[f=009202h,l=0,an=00h,rx=20s,wx=,ax=] s0=[7,8h,fd=8,ex=] s1=[7,8h,fd=9,ex=] exp=20s
0x9ef3d08: proto=tcpv4 src= fe=ravitestbed be=ravitestbed srv=arun as=0 ts=08 age=4s calls=3
rq[f=009000h,l=0,an=00h,rx=20s,wx=,ax=] rp[f=009202h,l=0,an=00h,rx=20s,wx=,ax=] s0=[7,8h,fd=12,ex=] s1=[7,8h,fd=13,ex=]
0x9f04548: proto=unix_stream as=2 ts=09 age=0s calls=2 rq[f=00e042h,l=10,an=20h,rx=10s,wx=,ax=]

rp[f=048060h,l=716,an=00h,rx=,wx=10s,ax=] s0=[7,0h,fd=3,ex=] s1=[0,0h,fd=-1,ex=] exp=9s

This will give you information about the running HAProxy process such as pid, uptime and etc.

ravi@arun:~$ echo “show info” | socat unix-connect:/tmp/haproxy stdio
Name: HAProxy
Version: 1.3.23
Release_date: 2010/01/28
Nbproc: 1
Process_num: 1
Pid: 11829
Uptime: 0d 0h42m53s
Uptime_sec: 2573
Memmax_MB: 0
Ulimit-n: 50013
Maxsock: 50013
Maxconn: 25000
Maxpipes: 0
CurrConns: 1
PipesUsed: 0
PipesFree: 0
Tasks: 1
Run_queue: 1

This will give you stats on all of your backends and frontends, some of the same stuff you see on the stats page enabled by the stats uri configuration. As an added bonus it’s all in CSV.

ravi@arun:~$ echo “show stat” | socat unix-connect:/tmp/haproxy stdio
ravitestbed,trupti,0,0,0,2,,15,7020,22722,,0,,0,0,0,0,no check,1,1,0,,,,,,1,1,1,,15,,2,0,,2,
ravitestbed,arun,0,0,0,5,,15,25562,27894,,0,,0,0,0,0,no check,1,1,0,,,,,,1,1,2,,15,,2,0,,3,

show errors will give you a capture of last error on each backend/frontend.

ravi@arun:~$ echo “show errors” | socat unix-connect:/tmp/haproxy stdio


Thanks to Joe (

Thank you,

How to use TCP Wrappers for system security

How to use TCP Wrappers for system security


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/
[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: : banners /etc/banners # SSH connections from host IP addresses  between and

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)

Manoj Chauhan