Thursday, November 27, 2014

Whether to enable "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"

Use of "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"is the standard recommendation in order to align with many security compliance standards. The United States Federal Information Processing Standard (FIPS) standard defines cryptographic algorithms approved for use by US Federal government computer systems for the protection of sensitive data. The requirement to use approved and validated algorithms applies only to the protection of sensitive data. Systems and applications are free to use weak or non-validated cryptographic implementations for non-security purposes based on its security context.

Enabling FIPS mode makes Windows and its subsystems use only FIPS-validated cryptographic algorithms. For example if this is enabled, it does not allow to use SSL 2.0 or 3.0 and enforce to use TLS instead. Further with .Net framework, if FIPS mode is enabled, the .NET Framework disallows the use of all non-validated cryptographic classes. The problem here is that the Framework offers multiple implementations of most algorithms, and not all of them have been submitted for validation, even though they are similar or identical to implementations that have been approved. Another significant problem with FIPS mode is that until very recently there was no NIST-approved way to derive an encryption key from a password. That blocked use of the Bitlocker Drive Encryption feature that stored a computer’s 48-character recovery password to Active Directory.

Even through the security best practise is to enable "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing", it is up to the individuals to decide their way of implementation based on their security context of applicability.

Reference:
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx

Thursday, October 9, 2014

Configure wvdial.conf in Ubuntu 14.04

I wanted to configure my Etisalat broadband connection with Ubuntu 14.04. Network Manager has already been uninstalled.

In order to connect to the broadband network, I followed the below listed proceedure.

Wvdial, the software I used to connect, is  an  intelligent  PPP  dialer, which means that it dials a modem and starts PPP in order to connect to the Internet.  It is something like the chat(8) program, except that it uses heuristics to guess how to dial and log into your server rather  than  forcing  you to write a login script.

To install wvdial
$sudo apt-get install wvdial

As the next step the modem was connected to my PC.

To configure wvdial at the very first time, below command was used.
$sudo wvdialconf

I edited the /etc/wvdial.conf as shown below.
[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","etisalat3g"
Modem Type = Analog Modem
Baud = 9600
New PPPD = yes
Modem = /dev/ttyUSB0
ISDN = 0
Phone = *99#
Password = " "
Username = " "


Since I don't have any credentials to connect to the network, I kept the username and password field as blank.

The APN was specified as an initialization parameter
Init3 = AT+CGDCONT=1,"IP","etisalat3g"

As the final step, I was able to successfully connect to the broadband network with the command.
$sudo wvdial

Configure Wireless Network: Edit /etc/network/interfeces of Ubuntu 14.04

To discover the available wireless interfaces
$sudo lspci |grep Wireless
$sudo lspci |grep Network


To discover the available wireless networks
$sudo iwlist wlan0 scan

To ask the wireless interface to associate with an identified access point
$sudo iwconfig wlan0 essid

If there is an encryption to supply the secret key [Assume WEP]
$sudo iwconfig wlan0 key

Now to ask for an ip address
$sudo dhclient wlan0

Or else to manualy configure the interface
$vi /etc/network/interfeces

The configuration for wireless interface with a dynamic IP address File: /etc/network/interfeces
----------
----------
auto wlan0
iface wlan0 inet dhcp
     wpa-ssid
     wpa-psk


The configuration for wireless interface with a static IP address File: /etc/network/interfeces
----------
----------
auto wlan0
iface wlan0 inet static
        address 192.168.2.185
        netmask 255.255.255.0
        gateway 192.168.2.1
        network 192.168.2.0
     broadcast 192.168.2.255
     dns-nameserver 8.8.8.8
     wpa-ssid

     wpa-psk


Note: Auto tag is to automatically start and connect to the wireless network.

To stop and start the wireless interface
$sudo ifdown wlan0
$sudo ifup -v wlan0

Monday, August 11, 2014

Firewalking with nmap

Firewalking is a technique developed by Mike Schiffman and David Goldsmith that utilizes traceroute techniques and TTL values to analyze IP packet responses in order to determine gateway ACL (Access Control List) filters and map networks. It is an active reconnaissance network security analysis technique that attempts to determine which layer 4 protocols a specific firewall will allow.

Below description is about how to use nmap to perform firewalking. Some of the scripts arguments are also listed below for your reference.

firewalk.max-probed-ports
maximum number of ports to probe per protocol. Set to -1 to scan every filtered port.

firewalk.max-retries
the maximum number of allowed retransmissions.

firewalk.recv-timeout
the duration of the packets capture loop (in milliseconds).

firewalk.max-active-probes
maximum number of parallel active probes.

firewalk.probe-timeout
validity period of a probe (in milliseconds).

Example Usage
  • nmap --script=firewalk --traceroute
  • nmap --script=firewalk --traceroute --script-args=firewalk.max-retries=1
  • nmap --script=firewalk --traceroute --script-args=firewalk.probe-timeout=400ms
  • nmap --script=firewalk --traceroute --script-args=firewalk.max-probed-ports=7

Sample output is shown below.

$nmap --script=firewalk --traceroute 10.168.0.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-11 17:25 IST
Nmap scan report for 10.168.0.11
Host is up (0.0033s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
8009/tcp open  ajp13
8080/tcp open  http-proxy

TRACEROUTE (using port 1025/tcp)
HOP RTT     ADDRESS
1   2.63 ms 192.168.2.1
2   2.20 ms 10.168.0.11

Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds


Reference:
http://nmap.org/nsedoc/scripts/firewalk.html

Tuesday, July 29, 2014

Install and Use Nmap/Zenmap 6 in Ubuntu 14.04

For the installation, you follow the steps listed below.
  1. If you don't have the alien command, install it with a command such as $sudo apt-get install alien
  2. Download the Nmap RPMs for your platform (x86 or x86-64) from http://nmap.org/dist/nmap-6.46-1.i386.rpm or from http://nmap.org/dist/nmap-6.46-1.x86_64.rpm depending on your target operating system. Since my operating system is a 64bit edition I am using the nmap-6.46-1.x86_64.rpm version of Nmap.
  3. Verify the download integrity as described in the section called “Verifying the Integrity of Nmap Downloads”.
  4. Generate a Debian package with a command such as $sudo alien nmap-6.46-1.x86_64.rpm
  5. Install the Debian package with a command such as $sudo dpkg --install nmap-6.46-1.x86_64.rpm.deb
  6. Steps 2–5 can be repeated for the other Nmap RPMs such as Zenmap, Ncat, and Nping.
    • To download Zenmap - http://nmap.org/dist/zenmap-6.46-1.noarch.rpm
    • TO download Ncat - http://nmap.org/dist/ncat-6.46-1.x86_64.rpm
    • To download Nping - http://nmap.org/dist/nping-0.6.46-1.i386.rpm

After the installation of Nmap using the above proceedure, you will probably face the following error while you are executing the nmap command or Zenmap:
nmap: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory .

The solution is:

a) Install subversion:
$apt-get install subversion 

b) make this symlink:
$ln -s /usr/lib/libsvn_client-1.so.1.0.0 /usr/lib/libsvn_client-1.so.0  (This should work for most of the cases.)

or

$ln -s /usr/lib/x86_64-linux-gnu/libsvn_client-1.so.1.0.0 /usr/lib/libsvn_client-1.so.0 (In my case this works, not the above.)

To run Zenmap/Nmap:
$sudo Zenmap or $sudo nmap

Refer the website http://nmap.org/6/ for command references.

Tuesday, June 17, 2014

Forcing Password Complexity in Red Hat Linux

My requirement was to enforce the password complexity for all the users of my RHEL 5 server (This will works for RHEL 4/5 also). This would be helpful to you also.

Password complexity is a set of rules which define what set of characters and how many of each characters must be in a password. My policy requirement was to have:
  • Minimum Length = 10
  • Number of digits = 1
  • At least one uppercase letter
  • At least one lowercase letter
  • At least one other character.

As a precautionary method, always I used to backup existing configuration file. To create a backup of the existing file:
$ cp /etc/pam.d/system-auth /root/system-auth

First I looked for the line containing the pam_cracklib module in the file /etc/pam.d/system-auth. In RHEL 5 and RHEL 6 it looks like this:
password requisite pam_cracklib.so try_first_pass retry=3

In RHEL 4 it looks like "password requisite /lib/security/$ISA/pam_cracklib.so"

This is the place where we need to edit and add my password policy configurations. I changed the line as given below to reflect the my password policy configuration requirements.

password requisite pam_cracklib.so try_first_pass retry=3 minlen=10 ucredit=-1 dcredit=-1 ocredit=-1 lcredit=-1

Same can be configured in RHEL 4 as "password requisite /lib/security/$ISA/pam_cracklib.so retry=3 minlen=10 ucredit=-1 dcredit=-1 ocredit=-1 lcredit=-1"

I had existing users on my system and I wanted to make sure they are complied with the password policy. They were enforced the change their password during the next login. To do this I needed to lock the user account, expire their password, and unlock the user account. Here are the simple step to accomplish this.

Lock the account:
$ usermod -L kushan

Expire their current password:
$ chage -d 0 kushan

Unlock the account:
$ usermod -U kushan

Check the status of their password. (This will show the current configuration of the user "kushan":
$ chage -l kushan

Description of the parameters used above is given below.
  • retry=N: Prompt user at most N times before returning with error. The default is 1.
  • minlen=N: The minimum acceptable size for the new password (plus one if credits are not disabled which is the default).
  • reject_username: Check whether the name of the user in straight or reversed form is contained in the new password. If it is found the new password is rejected.
  • dcredit=N: (N >= 0) This is the maximum credit for having digits in the new password. The default for dcredit is 1.
  • lcredit=N: (N >= 0) This is the maximum credit for having lower case letters in the new password. If you have less than or N lower case letters, each letter will count +1 towards meeting the current minlen value. The default for lcredit is 1.
  • ocredit=N: (N >= 0) This is the maximum credit for having other characters in the new password. The default for ocredit is 1.
  • ucredit=N: (N >= 0) This is the maximum credit for having upper case letters in the new password. The default for ucredit is 1.

Blocking intrusion attempts using authentication module pam_tally2

It is possible to block these intrusions using the authentication module called "pam_tally2". This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

By default, pam_tally2 module is already installed on the most of the Linux distributions and it is controlled by PAM package itself. This is a guide to lock and unlock SSH accounts after reaching a certain failed number of login attempts.

For example I found the configuration file in my RHEL system at /etc/pam.d/password-auth.

I used ‘/etc/pam.d/password-auth‘ configuration file to configure login attempts accesses. First I opened this file and added the following AUTH configuration line to it at beginning of the ‘auth‘ section.

auth        required      pam_tally2.so  file=/var/log/tallylog deny=3 even_deny_root unlock_time=1800

Parameters of the above line is described below.
  • file=/var/log/tallylog – Default log file is used to keep login counts.
  • deny=3 – Deny access after 3 attempts and lock down user.
  • even_deny_root – Policy is also apply to root user.
  • unlock_time=1800 – Account will be locked till 30 Min.

I wanted to automatically unlock the account after 30mins. So I configured the unlock_time=1800 also. In order to block permanently till manually unlock, this needs to be removed.

Now, to verify or check the counter that auser attempts, I use the following command:

$ pam_tally2 --user=kushan

To reset or unlock the user account to enable access again, I use the following command:

$ pam_tally2 --user=kushan --reset


To verify login attempt is reset or unlocked, I use the command:

$ pam_tally2 --user=kushan

Reference
Do ‘man pam_tally2‘ from the command line inside RHEL to know more about pam_tally2.

Monday, June 16, 2014

How to Disable Directory Listings in IIS/Apache

The easiest way to disable directory listing is to create an index file. The name of the index file depends on the web server configuration. On Apache is called index.htm, index.html. On IIS is named default.asp, default.aspx, default.htm.
  • On IIS directory listings are disabled by default.
  • For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an .htaccess file. In the configuration file you will have the definition of the directory. Something like

Options Indexes FollowSymLinks
...

 
To disable directory listing for that directory you need to remove the ’Indexes’ option.

Reference
http://www.acunetix.com/blog/web-security-zone/directory-listing-information-disclosure/

Tuesday, June 3, 2014

DoS-ing & Countering Apache Web Link Saturation

Testing your webserver - DoS-ing

DoS, or Denial of Service attacks, are nothing new.  The main idea behind a DoS attack is to exhaust a devices resources (be it HTTP, some database backend, or any other form of  ‘service’) until it can’t respond to legitimate requests anymore. The most popular form of DoS (i.e. the ones you read about in the paper) is link saturation. The plan is to send a massive amount of requests to a server, much more than it normally receives, in order to saturate either the server or its link.

Recently, a new method of DoS-ing Apache HTTP servers has emerged. Recently a tool (Slowloris) has been developed by RSnake with help from John Kinsella to launch the attack. The tool works by exhausting Apache processes.  Apache comes configured to only allow a certain number of processes (default install is 256) and not answer any more requests when that limit is hit. This tool sends the first part of a HTTP request header. While Apache waits for the rest of the header, one of those 256 processes it taken up. By default, Apache will wait up to 5 minutes for those connections to complete.  Once the tool has taken up all the available connections the Apache server will not serve any new requests.

$ perl slowloris.pl -dns

Welcome to Slowloris – the low bandwidth, yet greedy and poisonous HTTP client

Defaulting to port 80.
Defaulting to a 5 second tcp connection timeout.
Defaulting to a 100 second re-try timeout.
Defaulting to 1000 connections.


This would help you to test whether your server is actually vulnerable to this kind of DoS attacks.

Countering
If you have a good baseline on your web servers and know the limits of expected traffic – there is a quick and dirty fix for this.  This fix assumes that the attack comes from the same source-ip.  The following iptables rule limits the amount of connections from the same source to 20 connections.

iptables -A INPUT -p tcp –dport 80 -m connlimit –connlimit-above 20 -j REJECT –reject-with tcp-reset

With this in place, Slowloris can only take up 20 connections per source ip, leaving the other connections open for legitimate users.



Reference

[1] Above content is mainly based on the article: http://www.redspin.com/blog/2009/06/21/dos-ing-over-dial-up/
[2] The tool is available at http://ha.ckers.org/slowloris/


Wednesday, February 12, 2014

Network Time Protocol(NTP) Based DDoS Attacks.

Accurate, reliable time is necessary for financial and legal transactions, transportation and distribution systemsand many other applications involving widely distributed resources. Network Time Protocol (NTP) is a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism.  NTP provides the protocol mechanisms to synchronize time in principle to precisions in the order of nanoseconds while preserving a non-ambiguous date, at least for this century.  The protocol includes provisions to specify the precision and estimated error of the local clock and the characteristics of the reference clock to which it may be synchronized [1].

Due to the use of UDP, NTP protocol is prone to amplification attacks because it will reply to a packet with a spoofed source IP address and because at least one of its built in commands will send a long reply to a short request. Symantec has notice in the last few weeks that there is a significant NTP reflection attacks. NTP is Network time protocol and it’s used to synch the time between client and server, it is a UDP protocol and it’s run on port 123 [4].

NTP contains a command called monlist (or sometimes MON_GETLIST) which can be sent to an NTP server for monitoring purposes. It returns the addresses of up to the last 600 machines that the NTP server has interacted with. This response is much bigger than the request sent making it ideal for an amplification attack [2].

In the case of DNS reflection, the amplification factor is 8x, meaning attackers could generate eight times more traffic than they would normally be able to generate with their botnet. However, in the case of NTP and SNMP reflection it can be over 200x and 650x, respectively, CloudFlare said in a blog post in January.

Recently CloudFlare was undergoing one of the biggest DDoS attack in the history. The new attack has used a technique called NTP reflection that involves sending requests with spoofed source IP addresses to NTP servers with the intention of forcing those servers to return large responses to the spoofed addresses instead of the real senders [3].

NTP is just one of several protocols that and can be abused to amplify DDoS attacks. Two others are DNS (Domain Name System) and SNMP (Simple Network Management Protocol). These protocols normally do not try to authenticate the source IP addresses. What these protocols have in common is that they allow a relatively small query to generate a large response and are vulnerable to source IP spoofing if certain precautions are not taken because they work over UDP (User Datagram Protocol) [3].

How to be safe in Unix Environment

In order to be safe against NTP based DDoS attacks targeting linux environments, following steps may be usefull. The following configuration is for a UNIX machine to act as simply an NTP client and never to allow NTP queries to it except from the loopback address [5]:

# by default act only as a basic NTP client
restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap
# allow NTP messages from the loopback address, useful for debugging
restrict 127.0.0.1
restrict ::1
# server(s) we time sync to
server 192.0.2.1
server 2001:DB8::1
server time.example.net


You can use your standard host firewall filtering capabilities to limit who the NTP process talks to. If you're using Linux and the host is acting as an NTP client only, the following iptables rules could be adapted to shield your NTP listener from unwanted remote hosts [5].

-A INPUT -s 0/0 -d 0/0 -p udp --source-port 123:123 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -s 0/0 -d 0/0 -p udp --destination-port 123:123 -m state --state NEW,ESTABLISHED -j ACCEPT


For further reading about DDoS refer: http://www.secure.edu.pl/pdf/2013/D1_1530_A_Graham-Cumming.pdf

Reference:
[1] Mills, D. L. (1985). Network time protocol (NTP). Network.
[2] http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
[3] http://www.pcworld.com/article/2096720/attackers-use-ntp-reflection-in-huge-ddos-attack.html
[4] https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300
[5] http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html