Squid proxy: How to add value to an already great service

Posted Leave a comment

Proxies are proxies and already a 90% of their usage goes that way. While so, I was wondering to hack the service to get it rolled for even better scenarios: apps and package updates through squid.
You may be thinking already that huh we have local repository for that case or WSUS for windows machines and perhaps couple of centralized administration for enterprise AV solutions. If you do the latter you would know the headaches accompanied. :)Now why not get something in a low level “to rule them all” if you get what I mean.

Sysadmins constantly try to minimize, simplify and ultimately optimize their set-up.Sometimes it comes out of necessity and as a requirements from the authorities. My case was the application zone servers that had no access to the Internet and while so per the security requirements the servers had to do regular updates… and to add to the mess had to have an anti-virus solution on them as well…

Scenario: we are involved: Servers OS: CentOS 7 + clamav AV in an environment where the servers are managed by puppet open source.
Target Packages: yum-cron, clamav
Here is the minimal recipe I went to meet this:
a. On the puppet server side, install yum_cron module from puppetforge and deploy it to the groups of nodes or default
b. On the puppet server side, install the clamav module form the puppetforge and deploy it to the groups of nodes or default
c. On the puppet server side, within the above classes declare the proxy server in the conf file of the apps.
Note: Obviously the above lines in absence of puppet service needs to be configured manually on each individual server. The beauty of both of these solutions is that there is a directive in their conf file to allow communication to the main servers through a proxy. That value needs to be pushed by puppet server.
This is the line in clamav config & yum to allow the update flow through a proxy:

/etc/freshclam.conf:HTTPProxyServer 192.168.10.57
/etc/freshclam.conf:HTTPProxyPort 3128
/etc/yum.conf:proxy=http://192.168.10.57:3128

d. Ready to roll? here is the excerpt of the squid proxy excerpt that needs your attention. I initially had a lot of headache in the IPV6 translation and MISS status of the packets. Anyway the conf file tells it all if you are already familiar with squid:

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.1.0/24 172.17.1.0/24 # RFC1918 possible internal network
acl localnet src 192.168.10.0/24 192.168.80.0/24 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
icp_port 0
htcp_port 0
icp_access deny all
shutdown_lifetime 1 second
dns_nameservers 192.168.10.1
cache_mem 2048 MB
memory_pools on
cache_store_log none
half_closed_clients off
maximum_object_size 30000 KB
dns_v4_first on #this saved a lot of hassles in tcp connections on the IPV6 where the partial networks are not supporting it...hence missing the HITs
# AV updates
#refresh_pattern -i \.kaspersky-labs\.(com|ru)\/.*\.(cab|zip|exe|ms[i|p]) 4320 100% 43200 reload-into-ims
#refresh_pattern -i \.kaspersky\.(com|ru)\/.*\.(cab|zip|exe|ms[i|p]|avc) 4320 100% 43200 reload-into-ims
#refresh_pattern -i .update\.geo\.drweb\.com 4320 100% 43200 reload-into-ims
#refresh_pattern -i \.avast.com\/.*\.(vp[u|aa]) 4320 100% 43200 reload-into-ims
#refresh_pattern -i \.avg.com\/.*\.(bin) 4320 100% 43200 reload-into-ims
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128
# Uncomment and adjust the following to add a disk cache directory.
#http_port 192.168.10.57:3128 transparent
cache_dir ufs /var/spool/squid 7000 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
refresh_pattern -i db\.[\w]*\.clamav\.net\/[\w]*\.cvd 4320 100% 43200 reload-into-ims
refresh_pattern -i db\.[\w]*.clamav\.net\/daily\-[\d]*.cdiff 4320 100% 43200 reload-into-ims
refresh_pattern -i .(deb|rpm|exe|zip|tar|tgz|bz2|ram|rar|bin)$ 129600 100% 129600 override-expire ignore-no-cache ignore-no-store
#logformat custom %{%Y-%m-%d %H:%M:%S}tl %6tr %>a %Ss/%03>Hs %

Artillery: a low-interaction honeypot minimal howto on CentOS7

Posted Leave a comment

As a requirement for enterprise infras, you need to have a honeypot or sort of in your arsenal…Here is my solution for a solution that is nifty and easy to implement, I also try to get one step ahead to configure it in a way to send logs to a central log server and at the same time make it run at reboot in a detached screen . As ever my environment is purely on the CentOS7 so expect systemd and firewalld and selinux mix…Also note that all the below is run as root
Installation
install git
yum install git
clone the repo from the latest
git clone https://github.com/trustedsec/artillery/ artillery/
cd to the artillery dir and run the python install script
cd /var/artillery && ./setup.py
once installed-which will be in the /var/artillery-you need to explicitly create the below dir
mkdir -p /var/artillery/database
Now cd to /var/artillery and read through the config file. It is enough self-explanatory and note what it can do…in my case the below changes needed to be done:
a. the ports it is listening to
# PORTS TO SPAWN HONEYPOT FOR
PORTS="22,80,1433,3306,8080,21,5900,25,53,110,1723,1337,10000,5800,44443,16993"
#

b. Get the remote log server info into the below directives
# Specify SYSLOG TYPE to be local, file or remote. LOCAL will pipe to syslog, REMOTE will pipe to remote SYSLOG, and file will send to alerts.log in local artillery directory
SYSLOG_TYPE="REMOTE"
#
# IF YOU SPECIFY SYSLOG TYPE TO REMOTE, SPECIFY A REMOTE SYSLOG SERVER TO SEND ALERTS TO
SYSLOG_REMOTE_HOST="192.168.10.111"
#
# IF YOU SPECIFY SYSLOG TYPE OF REMOTE, SEPCIFY A REMOTE SYSLOG PORT TO SEND ALERTS TO
SYSLOG_REMOTE_PORT="514"
#
# TURN ON CONSOLE LOGGING
CONSOLE_LOGGING="ON"

Exit from the editor.
Interface addition
If you are like me and have different zones of operation in production, you need to add interfaces to your VM and enable routing config. Remember that in the linux world there are no multiple default gws in NetworkManager unless by issuing nmtui and editing respective interface custom route. If you followed my steps you will be presented with something like:
default via 192.168.10.1 dev ens160 proto static metric 100
default via 172.17.1.1 dev ens192 proto static metric 101
default via 172.16.1.1 dev ens224 proto static metric 102
172.16.1.0/24 dev ens224 proto kernel scope link src 172.16.1.200 metric 100
172.17.1.0/24 dev ens192 proto kernel scope link src 172.17.1.200 metric 100
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.109 metric 100

Enabling ssh on different port
This step is necessary only if you want to keep an eye on the port:22;and if you don’t while you have port 22 in the list of listening ports for artillery, every time you run artillery it will complains so lets cut to the chase and go that further last mile to change the ssh port to another port:
change the ssh port value in /etc/ssh/sshd_config
Port 2222
I hate to see people setting off selinux or permissive, I used to be one with permissive habit but long dropped it by learning to fix issues of services with non-default behavior/config/port…here is howto achieve it:
Install policycoreutils
yum install policycoreutils-python
Get the service allowed
cat /var/log/audit/audit.log |grep denied |grep ssh |audit2allow -M ssh
allow the new port
semanage port -a -t ssh_port_t -p tcp 2222
restart the sshd service-you need to reconnect to it on the new port and make sure from the console if the service is green-status

All goes fine and now changing directory to the /var/artillery and issuing the ./artillery.py will get you a rolling window and notification how the service is working. Did I tell you how shameful it is to turn off selinux and firewalld? in this case you need to turn off firewalld all together for good as the correlation of the ports/service with the firewall allowing it makes it complex and remember that in the first place you are setting up a honeypot which is promiscuous in a sense…so lets turn off firewalld
systemctl stop firewalld && systemctl disable firewalld

Final step to make it run with no interactions
The problem with the script is that it does not fully integrate to systemstartup in Centos7, no worries we make it work in a clean and nifty way 😉
Install screen on the box
yum install screen
Create a bash script to run the application,something like the below but be my guest and allow your wildest imagination to come out,hahaha:
vim /root/artillery.sh
#!/bin/sh
# This is the main script to run artillery...it is used in another rc.local script to create a screen and attach to it to run this script
cd /var/artillery
/usr/bin/python artillery.py

Edit the /etc/rc.local to include the below
screen -dmS artillery-screen ./root/artillery.sh
Finally do the execution enabler
chmod +x /etc/rc.d/rc.local
Reboot and smile time for a test…
make sure that the artillery has started and already running by executing
screen -ls
and connect to it by:
screen -r artillery-screen
From another machine simply run the below commands and see the notifications on the screen
curl -I http://artillery-machineIP
ssh root@artillery-machineIP

docker and the issue of the default IP subnet

Posted Leave a comment

Have you had trouble getting the docker set up and suddenly recognize that the default docker bridge and its wide subnet conflicting with your private network?
Here is a recipe to address this as it took me a while to find out and seriously it must not be that way. The culprit in my opinion is that 172.17.0.0/16 is too wide by default 😉
a. Get the docker service stopped:
sudo systemctl stop docker
b. Get the list of the bridges to double check
sudo brctl show
c. Bring down the docker0 bridge
sudo ip link set device docker0 down
d. Delete the docker0 bridge all together to create it from scratch
sudo brctl delbr docker0
e. Recreate it with smaller subnet-as an old patron of kvm and getting used to the 122 value in the third octet and simplifying this process to remember I’ll go with 172.17.122.0/24:
sudo brctl addbr docker0
f. final touch
sudo ip addr add 172.17.122.0/24 dev docker0
g. bring up the bridge/service and look at the service details for the new bridge value
sudo ip link set dev docker0 up
systemctl start docker && systemctl status docker -l
voila

Tired of cracked and broken software…worry no more

Posted Leave a comment

Have you had nightmares in the peak of your business bloom when things go haywire because the solution you used in your enterprise failed ? The story is shared among a lot. Business owners seek advice of their IT department who in turn being shy of budget tightness suggest several cracked enterprise solutions that are-in the first glance- promising but then in the nick of the time they fail the very reason they are made for…be it backup, infra services, virtualization, load balancing or high availability etc,etc you name it…

A practice seen in a lot of governmental privet sector companies in Iran is mostly above, or else that would be the long recipe and 4,5,6 digit bill alternative which is again painful to the owners not to forget the obstacles of embargoed rules and cultural barriers.

If you seek the third way which indeed is around is the world of open source solution and free software. A plethora of well and seasoned solutions based on the *nix solutions that address any sizes of business and already proven sources as well. Yet the problem here is the knowledge of this unknown world to the big businesses IT folks and the learning curves here. Yes you guessed right we are here for that gap to fill…acting as a catalyst and bring you alternatives if not yet better; and at the fraction of costs. Our consultancy,deployment and train ing for such solution is that perfect middle way to  give you that ease of mind and shift your focus to the right area..

Please do contact us now and hear us…