LDAP CONFIGURATION FOR USER AND GROUP CENTRALISED AUTHENTICATION ON UBUNTU LTS 12.04 – PART-3

TLS Authentication of LDAP sessions:

Till now all the sessions made by the LDAP client to the server is open and not encrypted. Its time to make our LDAP client-server sessions encrypted by some mechanisms. The most common encryption method includes Transport Layer Security (TLS) and/or Secure Sockets Layer (SSL) encryption.

Here, we are using own Certificate Authority (CA) and then create and sign our LDAP server certificate as that CA. The first step in the process is to obtain or create a certificate. Because slapd is compiled using the gnutls library, the certtool utility will be used to create certificates.  Now we install the gnutls-bin package by running the following command as root from the LDAP server:

root@ubuntuserver:]# apt-get install gnutls-bin

(Click To Enlarge Screenshots)

After the package is installed, we create a private key for the Certificate Authority (CA) by the following command:

root@ubuntuserver:]# sh -c “certtool –generate-privkey > /etc/ssl/private/cakey.pem”

The –generate-privkey option generates a private key and it is saved to file /etc/ssl/private/cakey.pem.

Now we create a template file /etc/ssl/ca.info to define the CA with the following entries as shown below:

root@ubuntuserver:]# : vi /etc/ssl/ca.info

============================================
cn = Support Sages
ca
cert_signing_key
============================================

Now create the self-signed CA certificate using the following command:

root@ubuntuserver:]# certtool –generate-self-signed –load-privkey /etc/ssl/private/cakey.pem  \
–template /etc/ssl/ca.info –outfile /etc/ssl/certs/cacert.pem

Note that we are using the –template option to pass the template file /etc/ssl/ca.info created before to define the template for our self-signed CA. The –load-privkey loads the CA private key file cakey.pem which we created earlier and the –outfile option creates the required self-signed CA  cert /etc/ssl/certs/cacert.pem

Now make a private key for the LDAP server by:

root@ubuntuserver:]# certtool –generate-privkey –outfile /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Replace ldapserver.int.sages.com in the slapd key filename with your server’s hostname.

To sign the server’s certificate with the CA, create the /etc/ssl/ldapserver.int.sages.com.info info file containing:

root@ubuntuserver:]# : vi  /etc/ssl/ldapserver.int.sages.com.info

=========================================================

organization = Support Sages
cn = ldapserver.int.sages.com
tls_www_server
encryption_key
signing_key
expiration_days = 3650
=========================================================

The expiration_days attribute define the number of days the cert is valid. The above certificate is good for 10 years.(Rough calculation)

Replace canonical name cn ldapserver.int.sages.com with your server’s hostname.

And now we create the server certificate with the following command:

root@ubuntuserver:]# certtool –generate-certificate –load-privkey /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem \
–load-ca-certificate /etc/ssl/certs/cacert.pem –load-ca-privkey /etc/ssl/private/cakey.pem \
–template /etc/ssl/ldapserver.int.sages.com.info –outfile /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem

In the above command we pass the template file ldapserver.int.sages.com.info using the –template option to define the template for our server cert as we did for creating our self-signed CA. The –load-privkey loads the servers private key file ldapserver.int.sages.com_slapd_key.pem which we created earlier, –load-ca-privkey loads our CA private key , –load-ca-certificate option passes the CA cert cacert.pem and the –outfile option creates the cert /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem.

Now we have a certificate, key, and CA cert installed. Use ldapmodify command to add the new configuration options to slapd tree. As we know that ldapmodify is a command to modify our DIT and we use LDIF file format for this. So we create an LDIF file certinfo.ldif with the following entries:

root@ubuntuserver:]# : vi certinfo.ldif

=========================================================================
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

=========================================================================
Note that the certificate file names should be configured correctly in the above file with respect to the certs you created for your hostname.

Now we use the ldapmodify command to add the data to the cn=config DIT and tell slapd that our TLS work via the slapd-config(cn=config) database.

root@ubuntuserver:]# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f certinfo.ldif

You can see an output as shown below:

===================================

modifying entry “cn=config”

===================================

Once this is done make usre that the follwing entry is uncomented in /etc/default/slapd file:

SLAPD_SERVICES=”ldap:/// ldapi:///”

Contrary to our popular belief, we do not need ldaps:// in /etc/default/slapd in order to use TLS encryption. You should have just:
SLAPD_SERVICES=”ldap:/// ldapi:///”

LDAP over TLS  works using StartTLS. STARTTLS is an extension to plain text communication protocols, which offers a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication. So here an existing LDAP session (listening on TCP port 389) becoming protected by TLS/SSL. Whereas LDAPS, like HTTPS, is a distinct encrypted-from-the-start protocol that operates over TCP port 636. We are using STARTLS for our encryption.

Now its time to set permissions and ownerships for our certificate files such that the openldap user gets access to these certificates:

root@ubuntuserver:]# adduser openldap ssl-cert

At times you will get an error mesasge as given below while excecuting the adduser command:
===================================
adduser: The group `ssl-cert’ does not exist.
===================================
To overcome this install the package ssl-cert by:

root@ubuntuserver:]# apt-get install ssl-cert

This installs the ssl-cert package which creates the ssl-cert group automatically. Now excecute the adduser command:

root@ubuntuserver:]# adduser openldap ssl-cert

Run the following commands to change the group and permissions:

root@ubuntuserver:]# chgrp ssl-cert /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem
root@ubuntuserver:]# chmod g+r /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Now restart slapd by:

root@ubuntuserver:]# /etc/init.d/slapd restart

If slapd restarts fine, then we can make sure that the TLS configurations are fine. Or if you run into troubles with the server not starting, check the /var/log/syslog. If you see errors like main: TLS init def ctx failed: -1, it is likely there is a configuration problem. Check that the certificate is signed by the authority from in the files configured, and that the ssl-cert group has read permissions on the private key.

Now we should configure our LDAP server to use TLS by editing the /etc/ldap/ldap.conf file as shown below:

===========================================
BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

===========================================
Now we should make our client use TLS authentication. This can be done by editing the configuration file /etc/ldap.conf on the LDAP client machine:

[ldapclient@ubuntuserver:]#   vi  /etc/ldap.conf

Make sure the following entries are uncommented :

======================
ssl start_tls
tls_checkpeer no
======================
These two entries in ldap.conf makes the client use TLS certs for encrypted sessions with our LDAP server. Lets check whether the session is using TLS using ldapsearch command.

You can use the ZZ switch to the ldapsearch utility to see if we are using encrypted sessions.

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

(-x disables SASL authentication, -Z tells to start TLS request (-ZZ to require successful response) , -h defines the hostname of our LDAP server)

But this command returns an error as show below:
========================================
ldapsearch -xZZ -h ldapserver.sages.com
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
========================================
Note that the ldapsearch is an ldap utility which we got when we installed ldap-utils package. And the ldap-utils uses /etc/ldap/ldap.conf file. So make sure the following entries are there in /etc/ldap/ldap.conf on LDAP client :
========================================
BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
========================================
Now run the ldapsearch from the LDAP client as follows:

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

You will see all our LDAP users from our LDAP server. If all the users are listed while using the -ZZ switch with ldapsearch command we can make sure that the session is encrypted for that listed users.

Continue Reading

SSL Installation in a cPanel based server

What is SSL

SSL (Secure Sockets Layer) is a cryptographic protocol which ensure the security of communication over the Internet. SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability.

How SSL works

Web servers and Web browsers rely on the SSL protocol to create a unique encrypted channel for private communications over the Internet. The SSL Certificate consists of a public key and a private key. The public key is used to encrypt information and the private key is used to decrypt it. When a Web browser points to a domain which is secured by SSL, a level of encryption is established based on the type of SSL Certificate as well as the client Web browser, operating system and host server’s capabilities. This is why SSL certificates feature a different range of encryption levels.

Obtaining an SSL Certificate

Domain example.com needs an SSL Certificate. The following steps are involved in it :

a) Example.com generates a CSR (Certificate Signing Request) and during this process, a private key is generated.
b) With this CSR, Example.com goes to a trusted, third party Certificate Authority like Verisign. They take the Certificate Signing Request and validates example.com. The Certificate Authority validates example.com.
c) When the validation process is complete, the third party Certificate Authority gives a new public key (certificate) encrypted with their private key.
d) Example.com installs the new certificate and gets secured.

Installing SSL

(i) Through cPanel/WHM
Its quite easy to install SSL through cPanel/WHM interface.

Generating CSR

Under Security tab, click SSL/TLS Manager.

Generate the Private Keys first by accessing the option Generate, view, upload or delete your private keys

Access the option Generate, view, or delete SSL certificate signing requests. Fill in the forms like Domain Name, E-mail Address, Country etc.

You will obtain the CSR. Contact the Certificate provider with this information. The Certificate Authority will then provide the Certificate (CRT). Finally you will have the following files associated with SSL :

CSR in the format domain.com.csr or domain_com.csr

CA bundle, which have the Public key of the Certificate Authority in the format domain.com.cabundle or domain_com.ca-bundle

CRT, the certificate in the format domain.com.crt or domain_com.crt

Private key in the format domain.com.key or domain_com.key

Method 1 : Installing from cPanel

1. Go to SSL/TLS Manager.
2. Click Generate, view, upload, or delete your private keys.
3. Under the Upload a New Certificate section, click on the Browse button (next to Choose a .crt file option) and find the Domain Certificate file (example.crt) that you obtained from the SSL vendor. Alternatively you can paste the Certificate contents on the section Paste the crt below. Make sure to include the BEGIN and END tags, while copying your certificate. Click the Upload button.
4. Go Back and click Return to SSL Manager at the bottom of the page.
5. Click on Setup a SSL certificate to work with your site. If this option is not available, your web host may have disabled it. You will need to contact them for further support.
6. Now, select the domain you are using from the Domain drop down menu. It will attempt to fetch the SSL Certificate and the private key. If this doesn’t work, you may need to contact your web host.
7. In the box labeled CA Bundle paste the contents of the Intermediate certificate (DigiCertCA.crt).
8. Click Install Certificate. Your SSL certificate should now be installed, and the website configured to accept secure connections. You or your web host may need to restart Apache before it will work.

Method 2 : Installing from WHM

You can install SSL certificate from WHM also. Its quite simple when compared to the installation through cPanel. All you need is the root access to WHM. Once you login to the WHM, search for the option Install a SSL Certificate and Setup the Domain.

You’ll find three boxes. Paste the CRT file contents in the first box. It will automatically fetch the Key and CA Bundle (In most cases, CA bundle needs to be fetched manually). Finally click Submit once all the fields are populated. You’ll see a message that indicates the installation is successful

Method 3 : Manual Installation

You need the Server Root shell access for this. Go to the Apache configuration file in the server, in the cPanel case its /usr/local/apache/conf/httpd.conf. Locate the VirtualHost entry configured for SSL. Configure it like :

<VirtualHost xxx.xxx.x.xx:443>
 ServerName example.com
 ServerAlias www.example.com
 DocumentRoot /home/example/public_html
 SSLEngine on
 SSLCertificateFile /usr/share/ssl/certs/example.com.crt
 SSLCertificateKeyFile /usr/share/ssl/private/example.com.key
 SSLCACertificateFile /usr/share/ssl/certs/example.com.cabundle
</VirtualHost>

where SSLCertificateFile is the SSL certificate file path, SSLCertificateKeyFile is the Key file path, SSLCACertificateFile is the path to the Intermediate file. Make sure you’ve the files in the specified path (It may vary on different scenarios). Restart the Web server and you’re done.

Continue Reading

DDoS, prevention, cure! – Part 2

DDoS/DoS Prevention and Cure :

DDoS/DoS cannot be completely prevented by any of the service provides, but certain measures could help us to reduce the impact of attack.

The companies must develop and produce certain strict policies and rules to ensure the best practices are allowed. Strict security policies must be used and should be always updated. Having a AUP is a key tool to remove the abusive user from the network/system.

Having a separate team to handle abusive incidents is a good practice to whom the incidents could be notified and alerted.

Upgrades and Updates : Through testing must be done before a system is introduced to a production environment. Security should be considered from the start of the system design. Things to consider include:

  • Operating system lockdown and removal of any unnecessary processes,services and software. This should be done via scripts or by checklists preferably developed using industry best practices.
  • Review of system protocols to ensure communication paths are properly authenticated and if necessary encrypted.
  • Scanning of the systems to confirm and mitigate, if necessary, any security risks found.
  • If software source code is available, security source code reviews should be performed to eliminate buffer overflows and other vulnerabilities.
  • Apply patches in time

Here are some steps by which we could defend the impact of DDOS to a certain extent.

Setup machine / network keeping security in mind (Implement Good Security policy)

Setup a firewall which does Ingress and Egress Filtering at Gateway

Eg: Steps to Install AFP

wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

 tar -zxf apf-current.tar.gz

cd apf-<version number>

./install.sh 

Notes: Go through the Document in the Apf and configure it for your needs. All configuration is set at conf.apf which is normally located at /etc/apf/conf.apf

Enable Anit-DOS mode in Apf (ie in conf.apf) . Also make sure that your root’s cron has an entry like the one below

*/8 * * * * root /etc/apf/ad/antidos -a >> /dev/null 2>&1

Install IDS on your gateway/hosts to alert you when someone tries to sniff In.

Eg: AIDE

wget ftp://ftp.cs.tut.fi/pub/src/gnu/aide-0.7.tar.gz

tar -zxvf aide-0.7.tar.gz

 cd aide-0.7

 ./configure -with-gnu-regexp 

Final steps to install make;make install. Now the main step..To configure AIDE.AIDE stores all its rule sets in the file called aide.conf. Lets populate it get more details of how to configure and all from man aide.conf

Here I am taking an example .See below

Here is a sample short aide.conf:

Rule = p+i+u+g+n+s+md5

 /etc p+i+u+g

 /sbin Rule

 /usr/local/apache/conf Rule

 /var Rule

 !/var/spool/.*

 !/var/log/.* 

In the above configuration listed , a rule called “Rule” is set to check permissions (p), inode (i), user (u), group (g), number of links (n), size (s), and md5 checksum (md5). This rules are applied to all files in /bin, /sbin, /var, and /usr/local/apache/conf because they should rarely if ever change. Files in /etc are checked for changes in only permissions, inode, user, and group because their size may change, but other things shouldn’t. Files and directories in /var/spool and /var/log are not checked because those are folders where maximum updation takes place.

After configuring AIDE should be initiated with all these rules.

For that execute aide -init

Conduct regular Audits on each host on the network to find installation of DDOS tools / Vulnerable applications.

Use tools like RKDET(vancouver-webpages.com/rkdet),RKHUNTER(www.rootkit.nl) and CHKROOTKIT(www.chkrootkit.org) to find if any rootkit has been already installed and to locate the effected binaries in the machine, if any.

Please find a simple Audit check List below to be done on a Hosts

Eg: Audit Check List

A quick checklist:

* Software Vulnerabilities.

* Kernel Upgrades and vulnerabilities.

* Check for any Trojans.

* Run chkrootkit.

* Check ports.

* Check for any hidden processes.

* Use audittools to check system.

* Check logs.

* Check binaries and RPMS.

* Check for open email relays.

* Check for malicious cron entries.

* Check /dev /tmp /var directories.

* Check whether backups are maintained.

* Check for unwanted users, groups, etc. on the system.

* Check for and disable any unneeded services.

* Locate malicious scripts.

* Querylog in DNS.

* Check for the suid scripts and nouser scripts.

* Check valid scripts in /tmp.

* Use intrusion detection tools.

* Check the system performance.

* Check memory performance (run memtest).

Enforce and Implement Security Measures on all hosts in the network.

Machines new or old should only be allowed to run on your network, if your Security Admin or DSE (Dedicated Security Expert) member approves it with status “OK-to go live” after auditing the box. All Host in the network should be checked on a regular basis by your DSE team to make sure that all hosts are uptodate and can fight any attacks.

Audit network on a regular basis to see if your network is vulnerable to attacks

Use Open Source Tools like NESSUS(www.nessus.org) ,NMAP(www.insecure.org/nmap),SAINT( www.saintcorporation.com/products/saint_engine.html),SARA (www-arc.com/sara/sara.html)for auditing a network to find its vulnerabilities.

Create a DSE (Dedicated Security Expert ) Team for your company.

Collect your networks and hosts data . Analysis them and study them to see from where and what kind of attacks are coming into the network. This step will help us to understand what kind of attacks we are facing and will help us to strengthen the preventive measures. Let me tell you this move is worth the money you spend,for sure.

Implement Sysctl protection against DDOS

Eg:

 vi /etc/sysctl.conf 

add the below code:

# Enable IP spoofing protection, turn on Source Address Verification

 net.ipv4.conf.all.rp_filter = 1

 # Enable TCP SYN Cookie Protection

 net.ipv4.tcp_syncookies = 1 

Add the below code in /etc/rc.local and restart network

for f in /proc/sys/net/ipv4/conf/*/rp_filter;

 do echo 1 > done

 echo 1 > /proc/sys/net/ipv4/tcp_syncookies 

Install Mod_dosevasive to your apache.

Mod_dosevasive is module for Apache to perform evasive action in the event of an HTTP DDoS attack or brute force attack. Please find the installation step of mod_dosevasive in DSO mode below

Install Mod_dosevasive

wget http://www.nuclearelephant.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

tar -zxvf mod_evasive_1.10.1.tar.gz

cd mod_evasive_1.10.1

 $APACHE_ROOT/bin/apxs -iac mod_evasive.c 

Dont get scared by the variable “$APACHE_ROOT” . Its nothing, but a simple variable which stores the location of the apache installation (eg $APACHE_ROOT =/usr/local/apache)

vi /usr/loca/apache/conf/httpd.conf 

After this add the below code in httpd.conf

<IfModule mod_dosevasive.c>

 DOSHashTableSize 3097

 DOSPageCount 2

 DOSSiteCount 50

 DOSPageInterval 1

 DOSSiteInterval 1

 DOSBlockingPeriod 10

 </IfModule> 
/usr/loca/apache/bin/apachectl restart 

Install Mod_security .

Since DDOS normally targets http. Its always good to have a filtering system for apache . So that the request gets analyzed before web server handles it. Please find the installation step of mod_security in DSO mode below

Eg: Installation Steps

http://www.modsecurity.org/download/modsecurity-apache-1.9.2.tar.gz

 tar -zxvf modsecurity-apache-1.9.2.tar.gz

 cd modsecurity-apache-1.9.2

/usr/local/apache/bin/apxs -cia mod_security.c 

Create a file named mod_security.conf under the folder /usr/local/apache/conf

 vi /usr/local/apache/conf/mod_security.conf 

Create the rule with reference to the link http://www.modsecurity.org/documentation/quick-examples.html

and add it in the mod_security.conf file.

Add the location of mod_security.conf to httpd.conf

 vi /usr/local/apache/conf/httpd.conf 

Add the string below Include /usr/local/apache/conf/mod_security.conf

 /usr/local/apache/bin/apachectl stop

 /usr/local/apache/bin/apachectl start 
Continue Reading

DDoS, prevention, cure! – Part 1

DDoS – Distributed Denial Of Service  Wiki : http://en.wikipedia.org/wiki/Denial-of-service_attack

DDoS is an attack on a computer/server or its resources and thereby making it unavailable to intended users.

Web-hosts must be familiar with this term and will be a victim at-least once. The intention of this post is to give  a brief description about DDoS, its prevention and cure if effected. Please note that this will not server as a perfect guide to the mentioned “Subject-line”, but a “tip-note”.

Understanding DDoS:

The four commonly used programs used by attackers to launch DDoS attacks are

  1. Trinoo
  2. TFN
  3. TFN2K
  4. Stacheldraht

Symptoms of DDos:

  1. Unusually slow network performance (opening files or accessing web sites)
  2. Unavailability of a particular web site
  3. Inability to access any web site
  4. Dramatic increase in the number of spam emails received—(this type of DoS attack is considered an e-mail bomb)
  5. Packet loss for pings to IP/Domain

How DDoS is done:

Pictorial representation of Stacheldraht DDoS attack.

In Stacheldraht DDoS attack, the attacker uses a client program to connect handlers which is a set of compromised machines that issues commands to the agents which in-turn facilitate the DDoS attack. The agents are another set of machines which is compromised using handlers by the attacker. Each handler can control thousands of agents  and all these widely distributed agents floods the target server and thereby increasing the impact of attack.

DoS and DDoS are not the same:

If the attacker initiates an attack from a single host, it is classified as a DoS  as it is not ‘distributed’. In fact, any attack against availability would be classed as a Denial of Service attack. On the other hand, if an attacker uses a thousand systems to simultaneously launch smurf attacks against a remote host, this would be classified as a DDoS attack.

Then what is DRDoS? DRDoS is Distributed Refected Denial of Service. These attacks forge the source address of the IP packets with the victim’s IP and send pings/packets to intermediate hosts. When the intermediate sends back the reply to these pings , it is sent to the victims IP thereby flooding the victim.

Some other types/methods of DDoS/DRDoS/Dos attacks are :

Reflective ICMP attack: The reflective ICMP attack uses public sites like google.com that responds to ICMP ping requests to that of victims IP. The attacker spoofs the victims IP and send requests to the Public servers which will then reply to the actual IP.

TCP SYN flood attack : The attacker sends a packet with SYS bit set of the well known TCP three way handshake. The victim responds to the request by sendong a reply packet with SYN_ACK bit set, but the attackr never responds and thereby increasing the TCP receive queues and denying new TCP connetions. But modern  UNIX and Windows fixed this by increasing the queue qize and limited the number of TCP SYS packets allowed.

UDP attacks : The UDP is one of the most effective way of DDos/DoS attacks. UDP is a stateless protocol and does not have any acknowledgement mechanism by design. PROTOS,the SNMP test suite, and other SNMP tools have been used successfully to launch application level DoS attacks. The Slammer worm was extremely fast because it did not require a response from the compromised computer.

TTL Expiration : The attacker forges the victims IP and send packets with low TTL set to it so that it will expire in the transmit at high speed router. When the TTL reaches zero, the router drops the packet and sends an ICMP TTL expired message to the source address, ie the Victim IP. This attack could be lowered by rate limiting ICMP to all routers in the service provider’s network.

Permanent DoS attacks (PDoS) :  PDoS is an attack that damages the system so badly that it needs the hardware to be replaced or reinstalled. The PDoS is purely a hardware targeted attack in which the attacker modifies the devide fireware by the legitimate method caled flashing. The attacker replaces the hardware firmware with his own modified version which will make the device unstable and render it from the original purpose for which it is made or designed for. The is done by exploiting the hardware security flaws which will allow remote administration of devices such as routers, printers and other networking hardwares.

Degradation Of Service Attacks : The compromised computers are used by the atackers to launch short-lived flooding on victims website which will slow down the website rather than crashing it. This is degradation of service rather than deniel of service and is more seriver than DoS as this is pretty difficult to detect and resolve.

Un-intentional Denial Of Services :  Sudden spike in popularity for a website is the major cause for this. This happens when an extremely popular wesite posts a link to a second site as a part of referrence for news or article. This will lead significant increase in traffic to the secondary website which will result in crashing or server/services. An example for this hapened when Michael Jackson died in 2009 which took down sites like Google and Twitter. (In this case you cant just blame someone ;) )

Blind Denial Of Service : In Blind Deniel of Service, the attacker must be able to receive traffic from the victim, then the attacker must either subvert the routing fabric or use the attacker’s own IP address. Either provides an opportunity for the victim to track the attacker and/or filter out his traffic. With a blind attack the attacker uses a forged IP addresses, making it extremely difficult for the victim to filter out those packets. The TCP SYN flood attack is an example of a blind attack. Designers should make every attempt possible to prevent blind denial of service attacks.

Continue Reading

CRITICAL : One more kernel exploit known to the public

A continuation of the previous exploits. http://isec.pl/vulnerabilities/isec-0025-syscall-emulation.txt

Full Disclosure here  - http://seclists.org/fulldisclosure/2010/Sep/268 & mitigation at http://seclists.org/fulldisclosure/2010/Sep/273

Details about the 0 day exploit and how to test whether your system is exploitable or not. However no need to get panicked as this particular exploit was with l33t hackers for last 2 years as you can see at the above link. Now since it is public now, take an extra care if uname -m gives you a x86_64.

http://sota.gen.nz/compat2/

http://sota.gen.nz/compat1/

Two CVE candidates are there – CVE-2010-3081 and CVE-2010-3301. One will affect the server and other don’t.

Temporary solution would be to follow https://access.redhat.com/kb/docs/DOC-40265

Continue Reading


 

About this blog

This blog, acts as a knowledge repository for the world and is unofficial! Anything we find interesting in the cyber world will go here. Most cases, this blog will reflect the happiness of our staff in reaching successful solution to an issue (s)he worked on. A reference for other fellow SAGEs who come across similar issues later