Category: Security

“There is no substitute for proactive Security”

Much as you would love to believe that you are safe you are not. Chances are that a new Vulnerability was discovered a few weeks after you patched your servers. We can take the pain out of managing security for you through our Security centric services.

Bolstered by our vast experience in securing and resurrecting mission-critical servers and over 6 years of core system administration and impelmetation work, we provide you with a comprehensive-one stop server security solution.

Unlike those fancy “consultants”, who charge you a million bucks and leave you all scared and sweating, we have been in the field, grappled with real issues and patched real servers (not the ones in a lab or in a textbook). We have what it takes to make your servers “really” safe. We don’t just tell you what your problems are but we go the whole nine yards and “fix it” so you can sit back and relax.

Our services include but are not restricted to:

Security incident handling and emergency rescue operations.
framing of security policies, keeping in mind target systems/users
Basic and Advanced vulnerability Analysis of servers
Application Security Audits
Firewall implementation and tuning
Disaster Recovery and Redundancy planning
centralized as well as offline log repository management and monitoring
Mail and Messaging systems security

As stated earlier we do not restrict ourselves within the above stated activities. We take each case on a one to one basis and proceed to evaluate and suggest a solution that we can provide and that you would like to take from us. So please feel free to contact us .

wannacrypt killswitch morph proof

I was tracking Wannacrypt over the weekend and had an idea which I felt can be rolled out quickly. Listing it out as succinctly as possible:

The killswitch is what it essentially hinges on. An unregistered domain in the code
the encryption and further execution stops if the domain specified in code is resolved and a http connection established.
the killswitch domainname in the wannacry code has changed which means sinkholing just one or two domain names will not work
so what if we could resolve all unregistered domains to a honeypot.
DNS by nature cannot be gamed to do this as it will cause havoc.
Maxmind GeoIP has a domainame database
write a small dns server drop in replacement which uses a local copy of this database
the drop in dns server sits infront of actual organization dns server
checks domain name in the maxmind db.
if found in db lets request pass on to actual dns or replies
if not found our drop in dns server replies with a honeypot IP
honeypot IP is running a http server and allows the http connect
http connect happens and killswitch is activated. Wannacrypt/wannacry stops execution

This can be dynamically configured by giving dns IP to our drop in application server. Later as dust settles further course of action can be decided.

Potential to provide clients with a solution that so far is not available. Effect on normal working of applications is nil. It can be explained to clients in an advisory.

secure mail (Postfix+SMTP_AUTH+SMTPS — DOVECOT+IMAPS)

This is a quick and dirty on howto enable smtp_auth and ssl encryption for smtp services along with secure imap. I like ot use postfix and dovecot.

INSTALL DOVECOT AND CYRUS-IMAPD
yum install dovecot cyrus-imapd

INSTALL POSTFIX WITH SASL TLS AND CYRUS SUPPORT
wget http://www.tigertech.net/mirrors/postfix-release/official/postfix-2.8.3.tar.gz tar -zxf postfix-2.8.3.tar.gz cd postfix-2.8.3 make tidy make makefiles CCARGS="-DUSE_TLS -DUSE_SASL_AUTH -I/usr/local/include/sasl -DUSE_CYRUS_SASL -I/usr/include/sasl" AUXLIBS="-L/usr/local/lib -lsasl2 -lssl -lcrypto" make make install

EDIT /ETC/POSTFIX/MAIN.CF
smtpd_tls_auth_only = no smtp_use_tls = yes smtpd_sasl_auth_enable = yes smtpd_sasl_type = cyrus local_recipient_maps = smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes broken_sasl_auth_clients = yes smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom
EDIT MASTER.CF
smtps inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_sender=yes -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o broken_sasl_auth_clients=yes -o smtpd_tls_wrappermode=yes
(NOTE: last line is important for supporting buggy clients like outlook express for mac and windows)

GENERATE THE SSL CERTIFICATE
mkdir /etc/postfix/ssl cd /etc/postfix/ssl/ openssl genrsa -des3 -rand /etc/hosts -out smtpd.key 1024 openssl req -new -key smtpd.key -out smtpd.csr openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out smtpd.crt openssl rsa -in smtpd.key -out smtpd.key.unencrypted openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650 openssl pkcs12 -export -in smtpd.crt -inkey smtpd.key -out OutlookSMTP.p12

RELOAD POSTFIX (at this point smtps and smtp_auth are done)

EDIT /ETC/DOVECOT.CONF

protocols = imaps pop3s


 protocol imap {

listen = *:143

ssl_listen = *:993

}

protocol pop3 {

listen = *:110

ssl_listen = *:995

}
ssl_disable = no
ssl_cert_file = /etc/pki/dovecot/certs/dovecot.pem

ssl_key_file = /etc/pki/dovecot/private/dovecot.pem

mail_location = mbox:~/mail:INBOX=/var/mail/%u

RELOAD DOVECOT (at this point imaps and pops3 on ports 993 and 995 respectively are enabled)

ensure firewall allows ports 993, 995, 465 are all open.

Challenge-Response — to fight email SPAM

You’ve probably already tried spamassassin and a host of other tools, which are good mind you, and still there’s spam bothering you! So whats next? How do you manage the spam situation?

Well how about a challenge-response mechanism. How about asking the sender to ensure that they sent you the message before letting the message reach your mailbox.

This is implemented beautifully by TMDA (short for Tagged Message Delivery Agent)! TMDA combines whitelists, blacklists, a challenge/response system, and special-purpose e-mail addresses called “tagged addresses” to thwart spam.

This howto is for setting up TMDA on a per user basis (not everyone would probably appreciate the interception and so better to give it only to those on your server who ask for it)! It assumes Postfix is the MTA.

cd /usr/src
wget http://tmda.sourceforge.net/ftp/releases/tmda-1.1.1.tgz
tar -zxf tmda-1.1.1.tgz
cd tmda-1.1.1
./compileall
su – imtiaz
mkdir .tmda
cd .tmda/
/usr/src/tmda-1.1.1/bin/tmda-keygen —> dont forget to chmod 600 your crypt_key after pasting output of this command into ~/.tmda/crypt_key)
mkdir logs
touch logs/debug
touch logs/
touch lists/confirmed
mkdir filters
cat > .forward

|/usr/src/tmda-1.1.1/bin/tmda-filter

echo “from-file ~/.tmda/lists/confirmed accept” > filters/incoming
cat > config

MAIL_TRANSFER_AGENT = "postfix" RECIPIENT_DELIMITER = "+" DELIVERY = "/var/spool/mail/imtiaz" CONFIRM_APPEND = os.path.expanduser("~/.tmda/lists/confirmed") LOGFILE_DEBUG = "~/.tmda/logs/debug" LOGFILE_INCOMING = "~/.tmda/logs/incoming" LOGFILE_OUTGOING = "~/.tmda/logs/outgoing" FILTER_INCOMING = os.path.expanduser("~/.tmda/filters/incoming") FILTER_OUTGOING = os.path.expanduser("~/.tmda/filters/outgoing") ACTIONOUTGOING = "bare=append" BARE_APPEND = os.path.expanduser("~/.tmda/lists/confirmed")

Once this is done send a test mail to [email protected] It should result in a automatic reply being generated asking for a confirmation from our end. Once you confirm the address becomes whitelisted and you can send without a confirmation until the user, Imtiaz, removes your id from the confirmed list.

Send a mail to [email protected] to see how this works

Please use this form to contact us to request a qoute for this implementation on your server. We can also do this server wide if required.

Secure SMTP + pop-before-smtp + road warriors

This writeup illustrates how you can enable secure roaming access to an smtp server while simultaneously adding a further layer of security to your postfix mail server. Not 100% guaranteed to keep thieves at bay but very effective.

It works on the principle that if you have an account on the server you are authorized to relay from that server. So if you can authenticate your self to the pop daemon you’re allowed to send mails using the smtp server running on the same server. Otherwise not!

Assumes you’re using Dovecot for pop3/imap access and Postfix for the MTA

Download the source for pop-before-smtp

cd /home/imtiaz/src/
wget http://nchc.dl.sourceforge.net/sourceforge/popbsmtp/pop-before-smtp-1.41.tar.gz
tar -zxf pop-before-smtp-1.41.tar.gz

setup some required Perl modules

perl -MCPAN -e shell;
install Bundle::CPAN
install Time::HiRes File::Tail Net::Netmask Date::Parse DB_File

Move around the files

cd /home/imtiaz/src/pop-before-smtp-1.41
cp pop-before-smtp.init /etc/rc.d/init.d/pop-before-smtp
cp pop-before-smtp /usr/sbin/
cp pop-before-smtp-conf.pl /etc

Edit the /etc/pop-before-smtp-conf.pl file to customize it for your system.
# Set the log file we will watch for pop3d/imapd records.
$file_tail{‘name’} = ‘/var/log/maillog’;

set the pattern to what you have on your system (HINT: setup dovecot to log to /var/log/maillog and then enable it)

/usr/sbin/pop-before-smtp –dumpconfig
/usr/sbin/pop-before-smtp –debug –nowrite –reprocess
chkconfig pop-before-smtp on
/etc/init.d/pop-before-smtp start

ls -l /etc/postfix/pop* —>this will show you the db being created

Add these two lines to your postfix config

check_client_access=hash:/etc/postfix/pop-before-smtp
smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient, check_client_access hash:/etc/postfix/pop-before-smtp, reject_unauth_destination

restart postfix by running postfix reload

N’joi

If you need help setting up pop-before-smtp on your server to allow remote SMTP in a secure manner to road warriors and hosting clients please contact us.

Linux Security + prevent password brute forcing + ssh security + firewall + iptables

This is a quick and dirty how to on setting up a firewall + Bruteforce detection/prevention mechanism + AntiDOS system on your dedicated Linux server.
Assumes root access

APF

APF is a policy based iptables firewall system designed for ease of use and configuration.

mkdir $HOME/src cd $HOME/src wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz tar -xvzf apf-current.tar.gz cd apf-0.9.6-1/ ./install.sh vi /etc/apf/conf.apf (edit the IG_TCP line and add ports you need. Also the directive to run it in demo mode)

/etc/init.d/apf start

AntiDOS

Antidos is a log parsing script made for r-fx.org’s APF (advanced policy
firewall). It’s purpose is to parse specific log formats for network attacks
against a given system; and take certain actions.

vi /etc/apf/ad/conf.antidos (edit the config for alerts and other options) /etc/init.d/apf restart

BFD

BFD is a modular shell script for parsing applicable logs and checking for authentication failures. There is not much complexity or detail to BFD yet and likewise it is very straight-forward in its installation, configuration and usage. The reason behind BFD is very simple; the fact there is little to no authentication and brute force auditing programs in the linux community that work in conjunction with a firewall or real-time facility to place bans.

cd $HOME/src wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz tar -zxf bfd-current.tar.gz cd bfd-0.9/ ./install.sh vi /usr/local/bfd/conf.bfd (edit alarm settings, email address etc.)

A cron job gets added to run bfd at intervals to detect and abn brute force attempts.

This is just an example of what can be done to stop hackers in there tracks. There’s a lot more which we can help you with on your servers.

Please WRITE TO US for this and other security or system administration related question/requirements/qoutes.