Implemented IPv6 needs testing

[jgmdev]

IPv6 was implemented by using ss to properly display connections and ip6tables to block excessive connections. Still it hasn't been implemented for block_incoming only and needs testing.

Any testing appreciated.

[jgmdev]

Tested and fixed every major issue found, everything should be working properly on v1.1

[Akshay-Hegde]

I am not sure, but it looks like not detecting and blocking ipv6

You may see below info

# ss -ntu6
Netid State      Recv-Q Send-Q                                            Local Address:Port                                              Peer Address:Port 
tcp   ESTAB      0      0                                           ::ffff:172.27.27.21:80                                         ::ffff:172.27.27.20:43615 
tcp   ESTAB      0      0                                           ::ffff:172.27.27.21:80                                         ::ffff:172.27.27.20:43616 

# ddos -y6
# ddos -v6 
# cat /etc/ddos/ignore.ip.list 
127.0.0.0/8

[Akshay-Hegde]

Actually there is

# netstat -antu | awk '{print $5}' | grep 172.27.27.20 | wc -l
361

Created using ab

$ ab -n 1501 -c 2 http://172.27.27.21

# cat /etc/ddos/ddos.conf 
# Paths of the script and other files
PROGDIR="/usr/local/ddos"
SBINDIR="/usr/local/sbin"
PROG="$PROGDIR/ddos.sh"
IGNORE_IP_LIST="ignore.ip.list"
IGNORE_HOST_LIST="ignore.host.list"
CRON="/etc/cron.d/ddos"
# Make sure your APF version is atleast 0.96
APF="/usr/sbin/apf"
CSF="/usr/sbin/csf"
IPF="/sbin/ipfw"
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"
TC="/sbin/tc"

# frequency in minutes (max: 59) for running the script as a cron job
# A minimum value of 1 is recommended for the script to be effective.
# Caution: Every time this setting is changed, run the script with --cron
#          option so that the new frequency takes effect.
# Warning: This option is deprecated and you should run the ddos-deflate
#          script in daemon mode which it is more effective.
FREQ=1

# frequency in seconds when running as a daemon
DAEMON_FREQ=5

# How many connections define a bad IP per user? Indicate that below.
NO_OF_CONNECTIONS=50

# Only count incoming connections to listening services, which will
# prevent the server from banning multiple outgoing connections to
# a single ip address. (slower than default in/out method)
ONLY_INCOMING=true

# If set to true the script will also use tcpdump to scan for ip
# addresses given in the CF-Connecting-IP header tag sent by cloudflare
# servers and ban using iptables string matching module.
ENABLE_CLOUDFLARE=false

# This option enables the usage of PORT_CONNECTIONS. Same as ONLY_INCOMING
# but you can also assing blocking rules per port using PORT_CONNECTIONS.
# (slower than ONLY_INCOMING method)
ENABLE_PORTS=false

# Maximum amount of connections per port before blocking. If a user
# is making all its connections to a single port the max connections
# specified for the port will take precedence over the
# NO_OF_CONNECTIONS value.
# You should specify a rule for all the service ports your server is
# running since those ports not defined on this list will be ignored
# when ENABLE_PORTS is enabled making those ports vulnerable to attacks.
# The form for each port element should be:
# "<from_port[-to_port]>:<max_conn>:<ban_period>"
PORT_CONNECTIONS="80:150:600 443:150:600 20-21:150:600"

# The firewall to use for blocking/unblocking, valid values are:
# auto, apf, csf, ipfw, and iptables
FIREWALL="auto"

# An email is sent to the following address when an IP is banned.
# Blank would suppress sending of mails
EMAIL_TO="root"

# Number of seconds the banned ip should remain in blacklist.
BAN_PERIOD=120

# Connection states to block. See: man ss
# each state should be separated by a colon (:), for example:
# "established:syn-sent:syn-recv:fin-wait-1:fin-wait-2"
# by default it blocks all states except for listening and closed
CONN_STATES="connected"

# Connection states to block when using netstat. See: man netstat
CONN_STATES_NS="ESTABLISHED|SYN_SENT|SYN_RECV|FIN_WAIT1|FIN_WAIT2|TIME_WAIT|CLOSE_WAIT|LAST_ACK|CLOSING"

# Monitor bandwidth usage per ip and slows down data transfer rate/s if
# the BANDWIDTH_CONTROL_LIMIT is exceeded. (Requires iftop and tc)
BANDWIDTH_CONTROL=false

# The data transfer rate/s that triggers a rate drop to the speed
# defined in BANDWIDTH_DROP_RATE, can be expressed in mbit or kbit.
BANDWIDTH_CONTROL_LIMIT="1896kbit"

# When the maximum data transfer rate defined in BANDWIDTH_CONTROL_LIMIT
# is reached, the speed of the transfer will be reduced to this value
# for the amount of seconds specified in BANDWIDTH_DROP_PERIOD.
BANDWIDTH_DROP_RATE="512kbit"

# The amount of time in seconds to keep a client transfer at the speed
# defined on BANDWIDTH_DROP_RATE.
BANDWIDTH_DROP_PERIOD=600

# If true, takes into consideration only the data received from
# client and not the data sent by server to client.
BANDWIDTH_ONLY_INCOMING=true

[jgmdev]

Does the machine has ipv6 enabled?

[Akshay-Hegde]

Yes. Its enabled, what's the use of only_incoming=true, does it count connections which are in waiting state also ?, instead of blocking once connected count exceeds some number can we block in waiting state ?

[jgmdev]

The feature is to only count connections that are sending data to server, but not those where the server sends data to a client.

[Akshay-Hegde]

Alright can you show one example with apache benchmark provided block_incoming=true

What I noticed is, if I set all default value, and run ab tool on test site which has google analytics, its blocking client IP along with google IP, which means client already used server resource ( 200 status code in apache log ).

On May 29, 2019 07:39, "Jefferson González" notifications@github.com wrote:

The feature is to only count connections that are sending data to server, but not those where the server sends data to a client.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jgmdev/ddos-deflate/issues/50?email_source=notifications&email_token=ABY6MLESC4I2TAIVRDVOCNLPXXQXHA5CNFSM4GCYIQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWN6IXQ#issuecomment-496755806, or mute the thread https://github.com/notifications/unsubscribe-auth/ABY6MLE5GBRJP3TCHJA63NDPXXQXHANCNFSM4GCYIQBQ .

[jgmdev]

Personally, I don't use that feature, it was implemented on this pull request #24, maybe something broke with recent changes or it just works as it is, have to take some time to test it. About google analytics getting blocked, isn't that supposed to get executed client side and not server side, which means it shouldn't get blocked because what google analytics does is count the current document.href from client computer and send it to google servers. Also google analytics is javascript code, so basically the apache benchmark tool should not trigger any javascript, unless there is some server side google analytics I don't know about. In any case you can whitelist a domain or ip range using the corresponding ignore.* file.

[Akshay-Hegde]

Yes, I whitelisted, I am using mod_page speed module, in that google analytics used. Please let me know if you need more inputs.

On May 29, 2019 20:56, "Jefferson González" notifications@github.com wrote:

Personally, I don't use that feature, it was implemented on this pull request #24 https://github.com/jgmdev/ddos-deflate/pull/24, maybe something broke with recent changes or it just works as it is, have to take some time to test it. About google analytics getting blocked, isn't that supposed to get executed client side and not server side, which means it shouldn't get blocked because what google analytics does is count the current document.href from client computer and send it to google servers. Also google analytics is javascript code, so basically the apache benchmark tool should not trigger any javascript, unless there is some server side google analytics I don't know about. In any case you can whitelist a domain or ip range using the corresponding ignore.* file.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jgmdev/ddos-deflate/issues/50?email_source=notifications&email_token=ABY6MLDCPDT6OBDQVHSBXGLPX2ODPA5CNFSM4GCYIQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWPWMPY#issuecomment-496985663, or mute the thread https://github.com/notifications/unsubscribe-auth/ABY6MLBK5KKTW7OHNW2TV6TPX2ODPANCNFSM4GCYIQBQ .