*** Introduction –
* 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 http://www.dest-unreach.org/socat/)
* How to use ‘socat’ with haproxy stat
Step 1) Download ‘socat’ from http://www.dest-unreach.org/socat/download/ latest version ~ “socat-2.0.0-b3.tar.gz”
ravi@arun:~$ wget http://www.dest-unreach.org/socat/download/socat-220.127.116.11.tar.gz
ravi@arun:~$ tar xvzf socat-18.104.22.168.tar.gz
ravi@arun:~$ cd socat-22.214.171.124
NOTE ~ No need to install the ‘fipsld’ package if you got the below msg after running the ‘make’ just following steps for
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
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 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
stats socket /tmp/haproxy
timeout connect 5s
timeout client 25s
timeout server 25s
listen ravitestbed 0.0.0.0:80 ##ravi.com IP
server web1 192.168.19.117
server web2 192.168.19.122
#stats uri /stat #Comment this if you need to specify diff stat path for viewing stat page
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=192.168.19.117:4721 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=192.168.19.117:4723 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=192.168.19.117:4725 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
Uptime: 0d 0h42m53s
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
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 (http://www.joeandmotorboat.com)
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: 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
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)