• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Any ConfigServer Security & Firewall (CSF) Experts Out There?

yavuz

Well-known member
#1
Hello,

I have my own dedicated server and using WHM as a control panel solution. I'm also been using CSF as a firewall protection.

For quite a while CSF locks me out when I use some of the services at once, like when I read my mail, connect to ssh and ftp.... Lately regular users are being locked out as well. Until now I managed to flush all the blocks by connecting from my mobile phone's internet connection.

There are a lot of thread out there on google when you search it but couldn't find a permanent solution.

Hope there is a solution,

Thanks.
 

MattW

Well-known member
#2
In your CSF config, what do you have configured in this section:

Code:
###############################################################################
# SECTION:Connection Tracking
###############################################################################
# Connection Tracking. This option enables tracking of all connections from IP
# addresses to the server. If the total number of connections is greater than
# this value then the offending IP address is blocked. This can be used to help
# prevent some types of DOS attack.
#
# Care should be taken with this option. It's entirely possible that you will
# see false-positives. Some protocols can be connection hungry, e.g. FTP, IMAPD
# and HTTP so it could be quite easy to trigger, especially with a lot of
# closed connections in TIME_WAIT. However, for a server that is prone to DOS
# attacks this may be very useful. A reasonable setting for this option might
# be around 300.
#
# To disable this feature, set this to 0
 

yavuz

Well-known member
#3
Code:
###############################################################################
# SECTION:Connection Tracking
###############################################################################
# Connection Tracking. This option enables tracking of all connections from IP
# addresses to the server. If the total number of connections is greater than
# this value then the offending IP address is blocked. This can be used to help
# prevent some types of DOS attack.
#
# Care should be taken with this option. It's entirely possible that you will
# see false-positives. Some protocols can be connection hungry, e.g. FTP, IMAPD
# and HTTP so it could be quite easy to trigger, especially with a lot of
# closed connections in TIME_WAIT. However, for a server that is prone to DOS
# attacks this may be very useful. A reasonable setting for this option might
# be around 300.
#
# To disable this feature, set this to 0
CT_LIMIT = Default: 0 [0 or 10-1000]

# Connection Tracking interval. Set this to the the number of seconds between
# connection tracking scans
CT_INTERVAL = Default: 30 [10-3600]

# Send an email alert if an IP address is blocked due to connection tracking
CT_EMAIL_ALERT = Default: 1 [0-1]

# If you want to make IP blocks permanent then set this to 1, otherwise blocks
# will be temporary and will be cleared after CT_BLOCK_TIME seconds
CT_PERMANENT = Default: 0 [0-1]

# If you opt for temporary IP blocks for CT, then the following is the interval
# in seconds that the IP will remained blocked for (e.g. 1800 = 30 mins)
CT_BLOCK_TIME = Default: 1800 [300-86400]

# If you don't want to count the TIME_WAIT state against the connection count
# then set the following to "1"
CT_SKIP_TIME_WAIT = Default: 0 [0-1]

# If you only want to count specific states (e.g. SYN_RECV) then add the states
# to the following as a comma separated list. E.g. "SYN_RECV,TIME_WAIT"
#
# Leave this option empty to count all states against CT_LIMIT
CT_STATES =

# If you only want to count specific ports (e.g. 80,443) then add the ports
# to the following as a comma separated list. E.g. "80,443"
#
# Leave this option empty to count all ports against CT_LIMIT
CT_PORTS =

###############################################################################
 

MattW

Well-known member
#4
Hmm, it's not that blocking you out them, as
CT_LIMIT = Default: 0 [0 or 10-1000] disables it.

Do you have anything else installed such as DDOS Deflate ?
 

yavuz

Well-known member
#7
When your IP gets blocked, are you getting a notification from CSF telling you the IP and reason?
No, It just happen. I'm getting no notification.

Also a interesting thing; For instance when I post a thread with a title that contains "Kill" in it, server locks me out :D
 

yavuz

Well-known member
#11
Check the values of CONNLIMIT and SYNFLOOD
They both are untouched, default:

Code:
###############################################################################
# SECTION:Port Flood Settings
###############################################################################
# Enable SYN Flood Protection. This option configures iptables to offer some
# protection from tcp SYN packet DOS attempts. You should set the RATE so that
# false-positives are kept to a minimum otherwise visitors may see connection
# issues (check /var/log/messages for *SYNFLOOD Blocked*). See the iptables
# man page for the correct --limit rate syntax
#
# Note: This option should ONLY be enabled if you know you are under a SYN
# flood attack as it will slow down all new connections from any IP address to
# the server if triggered
SYNFLOOD = Default: 0 [0-1]
SYNFLOOD_RATE =
SYNFLOOD_BURST =

# Connection Limit Protection. This option configures iptables to offer more
# protection from DOS attacks against specific ports. It can also be used as a
# way to simply limit resource usage by IP address to specific server services.
# This option limits the number of concurrent new connections per IP address
# that can be made to specific ports
#
# This feature does not work on servers that do not have the iptables module
# xt_connlimit loaded. Typically, this will be with MONOLITHIC kernels. VPS
# server admins should check with their VPS host provider that the iptables
# module is included
#
# For further information and syntax refer to the Connection Limit Protection
# section of the csf readme.txt
#
# Note: Run /etc/csf/csftest.pl to check whether this option will function on
# this server
CONNLIMIT =

# Port Flood Protection. This option configures iptables to offer protection
# from DOS attacks against specific ports. This option limits the number of
# new connections per time interval that can be made to specific ports
#
# This feature does not work on servers that do not have the iptables module
# ipt_recent loaded. Typically, this will be with MONOLITHIC kernels. VPS
# server admins should check with their VPS host provider that the iptables
# module is included
#
# For further information and syntax refer to the Port Flood Protection
# section of the csf readme.txt
#
# Note: Run /etc/csf/csftest.pl to check whether this option will function on
# this server
PORTFLOOD =

# Outgoing UDP Flood Protection. This option limits outbound UDP packet floods.
# These typically originate from exploit scripts uploaded through vulnerable
# web scripts. Care should be taken on servers that use services that utilise
# high levels of UDP outbound traffic, such as SNMP, so you may need to alter
# the UDPFLOOD_LIMIT and UDPFLOOD_BURST options to suit your environment
#
# We recommend enabling User ID Tracking (UID_INTERVAL) with this feature
UDPFLOOD = Default: 0 [0-1]
UDPFLOOD_LIMIT =
UDPFLOOD_BURST =

# This is a list of usernames that should not be rate limited, such as "named"
# to prevent bind traffic from being limited.
#
# Note: root (UID:0) is always allowed
UDPFLOOD_ALLOWUSER =
What should those be & is acceptable in your opinion?
 

MattW

Well-known member
#12
They both are untouched, default:

Code:
###############################################################################
# SECTION:Port Flood Settings
###############################################################################
# Enable SYN Flood Protection. This option configures iptables to offer some
# protection from tcp SYN packet DOS attempts. You should set the RATE so that
# false-positives are kept to a minimum otherwise visitors may see connection
# issues (check /var/log/messages for *SYNFLOOD Blocked*). See the iptables
# man page for the correct --limit rate syntax
#
# Note: This option should ONLY be enabled if you know you are under a SYN
# flood attack as it will slow down all new connections from any IP address to
# the server if triggered
SYNFLOOD = Default: 0 [0-1]
SYNFLOOD_RATE =
SYNFLOOD_BURST =

# Connection Limit Protection. This option configures iptables to offer more
# protection from DOS attacks against specific ports. It can also be used as a
# way to simply limit resource usage by IP address to specific server services.
# This option limits the number of concurrent new connections per IP address
# that can be made to specific ports
#
# This feature does not work on servers that do not have the iptables module
# xt_connlimit loaded. Typically, this will be with MONOLITHIC kernels. VPS
# server admins should check with their VPS host provider that the iptables
# module is included
#
# For further information and syntax refer to the Connection Limit Protection
# section of the csf readme.txt
#
# Note: Run /etc/csf/csftest.pl to check whether this option will function on
# this server
CONNLIMIT =

# Port Flood Protection. This option configures iptables to offer protection
# from DOS attacks against specific ports. This option limits the number of
# new connections per time interval that can be made to specific ports
#
# This feature does not work on servers that do not have the iptables module
# ipt_recent loaded. Typically, this will be with MONOLITHIC kernels. VPS
# server admins should check with their VPS host provider that the iptables
# module is included
#
# For further information and syntax refer to the Port Flood Protection
# section of the csf readme.txt
#
# Note: Run /etc/csf/csftest.pl to check whether this option will function on
# this server
PORTFLOOD =

# Outgoing UDP Flood Protection. This option limits outbound UDP packet floods.
# These typically originate from exploit scripts uploaded through vulnerable
# web scripts. Care should be taken on servers that use services that utilise
# high levels of UDP outbound traffic, such as SNMP, so you may need to alter
# the UDPFLOOD_LIMIT and UDPFLOOD_BURST options to suit your environment
#
# We recommend enabling User ID Tracking (UID_INTERVAL) with this feature
UDPFLOOD = Default: 0 [0-1]
UDPFLOOD_LIMIT =
UDPFLOOD_BURST =

# This is a list of usernames that should not be rate limited, such as "named"
# to prevent bind traffic from being limited.
#
# Note: root (UID:0) is always allowed
UDPFLOOD_ALLOWUSER =
What should those be & is acceptable in your opinion?
They are disabled as well, so it's not going to be those blocking your connections.

Is there anything in the mod_security logs to suggest that it's mod_security that is triggering the blocks?
 

estranged

Well-known member
#13
PS_INTERVAL is the last thing comes to my mind. If it is also already disabled, We can have a look if you upload your /etc/csf/csf.conf here. You may also want to add your IP to allow list.
 

yavuz

Well-known member
#14
Here are some snapshots I made from the logs. It seem that /js/audentio/uix/jquery.cookie.js HTTP/1.1 is quite popular mod_security labeling a lot of "WEB_ATTACK/XSS"

Note: For your information, I have anonymized my websites name by writing mywebsite.com
 

Attachments

yavuz

Well-known member
#16
PS_INTERVAL is the last thing comes to my mind. If it is also already disabled, We can have a look if you upload your /etc/csf/csf.conf here. You may also want to add your IP to allow list.
that one is also default. I've attacked my csf.conf to the message. Appearantly it was too long.
 

Attachments

MattW

Well-known member
#18
Well why would you want to stop people from accessing a file needed by a theme? The whole point of mod_security is you need to fine tune it to your own site needs if you have it installed.

I can't comment on why it's picking that particular file, but @Audentio would have put it into the theme for a reason.
 

estranged

Well-known member
#19
CT_LIMIT is set to 400 in this file. This setting can trigger false positives especially if keep alive is disabled in your httpd.conf. It can still trigger if you use many services at the same time. Especially ftp clients are connection hungry.

Personally I prefer disabling LF_MODSEC option in CSF due to the high number of false positives and high rate of logging.

I also keep PS_INTERVAL disabled as I have seen it also causes lots of false positives and have no real benefit.
 

MattW

Well-known member
#20
CT_LIMIT is set to 400 in this file. This setting can trigger false positives especially if keep alive is disabled in your httpd.conf. It can still trigger if you use many services at the same time. Especially ftp clients are connection hungry.

Personally I prefer disabling LF_MODSEC option in CSF due to the high number of false positives and high rate of logging.

I also keep PS_INTERVAL disabled as I have seen it also causes lots of false positives and have no real benefit.
The CT_LIMIT value wasn't showing in this post, as this was my initial thought.

I've also seen FTP connections with dodgy FTP software cause CT_LIMIT to kick in as each file is downloaded in a new connection, so you can quickly ramp up a few hundred connections to the server.

Code:
###############################################################################
# SECTION:Connection Tracking
###############################################################################
# Connection Tracking. This option enables tracking of all connections from IP
# addresses to the server. If the total number of connections is greater than
# this value then the offending IP address is blocked. This can be used to help
# prevent some types of DOS attack.
#
# Care should be taken with this option. It's entirely possible that you will
# see false-positives. Some protocols can be connection hungry, e.g. FTP, IMAPD
# and HTTP so it could be quite easy to trigger, especially with a lot of
# closed connections in TIME_WAIT. However, for a server that is prone to DOS
# attacks this may be very useful. A reasonable setting for this option might
# be around 300.
#
# To disable this feature, set this to 0
CT_LIMIT = Default: 0 [0 or 10-1000]

# Connection Tracking interval. Set this to the the number of seconds between
# connection tracking scans
CT_INTERVAL = Default: 30 [10-3600]

# Send an email alert if an IP address is blocked due to connection tracking
CT_EMAIL_ALERT = Default: 1 [0-1]

# If you want to make IP blocks permanent then set this to 1, otherwise blocks
# will be temporary and will be cleared after CT_BLOCK_TIME seconds
CT_PERMANENT = Default: 0 [0-1]

# If you opt for temporary IP blocks for CT, then the following is the interval
# in seconds that the IP will remained blocked for (e.g. 1800 = 30 mins)
CT_BLOCK_TIME = Default: 1800 [300-86400]

# If you don't want to count the TIME_WAIT state against the connection count
# then set the following to "1"
CT_SKIP_TIME_WAIT = Default: 0 [0-1]

# If you only want to count specific states (e.g. SYN_RECV) then add the states
# to the following as a comma separated list. E.g. "SYN_RECV,TIME_WAIT"
#
# Leave this option empty to count all states against CT_LIMIT
CT_STATES =

# If you only want to count specific ports (e.g. 80,443) then add the ports
# to the following as a comma separated list. E.g. "80,443"
#
# Leave this option empty to count all ports against CT_LIMIT
CT_PORTS =

###############################################################################