Sponsored Content
Full Discussion: DDoS and brute force attack
Special Forums Cybersecurity DDoS and brute force attack Post 302885990 by cjcox on Wednesday 29th of January 2014 10:26:31 AM
Old 01-29-2014
DDoS is simply a way to overload services. So, to protect, you use some kind of QoS or application based limiter that slows things down when heavy traffic seems present. In some cases you may be able to figure out the DDoS and limit things specifically.

Brute force attacks are often times focused on services where a username/password are involved. Again, you'll have to craft a response to this specifically. So, if you see so many failed attempts from a source, you could issue a command to your firewall to add a rule to block that source (perhaps just temporarily). As an example of a tool to help with this, look at: 302 Found
 

7 More Discussions You Might Find Interesting

1. Cybersecurity

what is the better way to protect my server from DDos Attack

heloo today i have DDos Attack in my server what is the better way to secure my server from DDos Attack i use CentOS 4&5 i try every firewall and talk to softlayer - iweb i've Tried every possible solutions but I can not find a solution to the problems Give Me The best way plzz (4 Replies)
Discussion started by: a7medo
4 Replies

2. UNIX for Advanced & Expert Users

Apache brute force attack

Hi, I'm trying find out if there is a way to stop a brute force attack on a Webmail site. I'm trying to setup a webmail access, but I would like to prevent too many invalid logins from the same IP. I've looked into Snort, but I was wondering if there was an application level firewall that can... (1 Reply)
Discussion started by: nitin
1 Replies

3. UNIX for Advanced & Expert Users

Brute force SMTP attack right now *help*

Im currently experiancing a brute force attack on my server Nov 26 15:27:04 ws096 saslauthd: do_auth : auth failure: Nov 26 15:27:13 ws096 saslauthd: do_auth : auth failure: Nov 26 15:27:22 ws096 saslauthd: do_auth : auth failure: Nov 26 15:27:29 ws096... (4 Replies)
Discussion started by: mcraul
4 Replies

4. Cybersecurity

DDoS Simulation Tools

are there any popular DDoS simulation tools to test my own infrastructure? Anyone tried to setup all these in AWS EC2? (1 Reply)
Discussion started by: boriskong
1 Replies

5. Shell Programming and Scripting

Expect script that simulates a SSH brute force attack

I want to test the effectiveness of sshguard on some of my systems so I'm trying to write a script that simulates a brute force attack by sending a bunch of different username and password combinations to the servers being tested. So far I have this: #!/usr/local/bin/expect set timeout 3... (5 Replies)
Discussion started by: ph0enix
5 Replies

6. Emergency UNIX and Linux Support

DDOS attack please help!

Dear community, my site was recently attacjed by DDOS technique and goes down in a few minutes. My site runs under Debian/Apache2/Mysql. I identified the IPs who attack me and block it through iptable firewall from debian. Something like: iptables -D INPUT -s xxx.xxx.xxx.xxx -j DROP This... (7 Replies)
Discussion started by: Lord Spectre
7 Replies

7. UNIX for Advanced & Expert Users

Anti ddos shell script, is it useful?

Hi guys, just need a opinion from you. I found anti ddos script from github Script What is your opinion about it? Is it usefull? Do you have some similar? I want to protect my servers on all levels, why not in the servers via script. I assume I must fix this script to be useful for me, but... (1 Reply)
Discussion started by: tomislav91
1 Replies
PAM_ABL(8)							 Linux-PAM Manual							PAM_ABL(8)

NAME
pam_abl - PAM Auto Blacklist Module SYNOPSIS
Provides auto blacklisting of hosts and users responsible for repeated failed authentication attempts. Generally configured so that blacklisted users still see normal login prompts but are guaranteed to fail to authenticate. This functionality is only available to services which call PAM as root. If pam_abl is called for uid != 0 it will silently succeed. DESCRIPTION
Brute force password discovery attacks involve repeated attempts to authenticate against a service using a dictionary of common passwords. While it is desirable to enforce strong passwords for users this is not always possible and in cases where a weak password has been used brute force attacks can be effective. The pam_abl module monitors failed authentication attempts and automatically blacklists those hosts (and accounts) that are responsible for large numbers of failed attempts. Once a host is blacklisted it is guaranteed to fail authentication even if the correct credentials are provided. Blacklisting is triggered when the number of failed authentication attempts in a particular period of time exceeds a predefined limit. Hosts which stop attempting to authenticate will, after a period of time, be un-blacklisted. Commands can be specified which will be run when a host or user switches state from being blocked to clear or clear to blocked. See below or the pam_abl.conf(5) manpage for the details. If pam_abl is called for uid != 0 it will silently succeed. If this was not the case it would be possible for a malicious local user to poison the pam_abl data by, for example, discovering the names of the hosts from which root typically logs in and then constructing PAM authentication code to lock out root login attempts from those hosts. OPTIONS
Name Arguments Description debug None Enable debug output to syslog. expose_account None Ignored no_warn None Disable warnings which are otherwise output to syslog. try_first_pass None Ignored use_first_pass None Ignored use_mapped_pass None Ignored config Path to the configuration file. The configuration file contains additional arguments. In order for the pam_abl command line tool to work correctly most of the configuration should be placed in the config file rather than being provided by arguments. The format of the config file is described below. host_db Path to host database file. Path to the Berkeley DB which is used to log the host responsible for failed authentication attempts. host_purge Purge time for the host database. Defines how long failed hosts are retained in the host database. Defaults to 1 day. host_rule Rule for host blacklisting. The rule (see below for format) which defines the conditions under which a failed hosts will be blackisted. host_blk_cmd Host block command Command that should be run when a host is checked, and is currently blocked. Within the command, the strings %u, %h and %s are substituted with username, host and service. Not all need to be used. If substitution is called for, but there is no iformation for that field, the command will not run. host_clr_cmd Host block command Command that should be run when a host is checked, and is currently clear. Within the command, the strings %u, %h and %s are substituted with username, host and service. Not all need to be used. If substitution is called for, but there is no iformation for that field, the command will not run. user_db Path to user database file. Path to the Berkeley DB which is used to log the user responsible for failed authentication attempts. user_purge Purge time for the user database. Defines how long failed users are retained in the user database. Defaults to 1 day. user_rule Rule for user blacklisting. The rule (see below for format) which defines the conditions under which a failed users will be blackisted. user_blk_cmd Host block command Command that should be run when a user is checked, and is currently blocked. Within the command, the strings %u, %h and %s are substituted with username, host and service. Not all need to be used. If substitution is called for, but there is no iformation for that field, the command will not run. user_clr_cmd Host block command Command that should be run when a user is checked, and is currently clear. Within the command, the strings %u, %h and %s are substituted with username, host and service. Not all need to be used. If substitution is called for, but there is no iformation for that field, the command will not run. USAGE
Typically pam_abl.so is added to the auth stack as a required module just before whatever modules actually peform authentication. Here's a fragment of the PAM config for a production server that is running pam_abl: auth required /lib/security/pam_env.so auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf auth sufficient /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so Although all of accepted arguments can be supplied here they will usually be placed in a separate config file and linked to using the config argument as in the above example. The pam_abl command line tool reads the external config file (/etc/security/pam_abl.conf in this case) to find the databases so in order for it work correctly an external config should be used. EXAMPLES
auth required /lib/security/pam_env.so auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf auth sufficient /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so SEE ALSO
pam_abl.conf(5), pam_abl(1) AUTHORS
Andy Armstrong <andy@hexten.net> Chris Tasma <pam-abl@deksai.com> GNU
01/13/2010 PAM_ABL(8)
All times are GMT -4. The time now is 10:08 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy