1

This is about a cPanel server which, like most servers, is under constant attack from lands afar. Considering that I only host to clients in the US and Canada, there is less of a reason to allow full access to Asia and South America, among other areas.

Too many firewall rules can increase latency, or worse, crash your firewall. Still, due to the large amount of attacks every day, I've configured CSF to manage at most 7000 rules. Some days are lighter than others, but on the 1st, 671 IPs were blocked trying to access SMTP (669) and cPanel (2).

To try and get this under better control, I thought about only allowing web access to everyone, and blocking specific large blocks from accessing FTP or SMTP. So, here is what I've placed in the CSF pre-rules [/usr/local/csf/bin/csfpre.sh].

iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 21:25 -s 1.0.0.0/8 -j DROP iptables -A INPUT -p tcp --dport 21:25 -s 2.0.0.0/8 -j DROP iptables -A INPUT -p tcp --dport 21:25 -s 112.0.0.0/8 -j DROP iptables -A INPUT -p tcp --dport 21:25 -s 113.0.0.0/8 -j DROP iptables -A INPUT -p tcp --dport 21:25 -s 117.0.0.0/8 -j DROP iptables -A INPUT -p tcp --dport 21:25 -s 190.0.0.0/8 -j DROP

Now, I'm not entirely confident in my iptables skills, so I'd like opinions regarding this and certainly feedback if this is doing something bad.

I do realize that this would block a massive amount of potential good email and any web developers in those areas hired to work on sites hosted on the server. My thought is that it is far far less probable that any valid email will be coming from these IP ranges. Also, I chose blocks based on my counts of attacks.

Rather than load up the 6000-7000 actual IP blocks for Russia, for instance, I can reduce the firewall rules dramatically and keep it simple by only focusing on wholesale blocking entire Class A blocks.

I used this site to examine exactly which countries would be blocked: tcpiputils.com

Improve this question
1
  • Just a note, I have checked this and it worked as expected. I could view http and https traffic, but not access FTP. It doesn't interfere with CSF either - if I banned the IP in CSF, it was completely banned as to be expected. Commented Jul 25, 2015 at 0:46

2 Answers 2

Reset to default
0

Might this be better handled by spam software? 670 hosts per day is not a huge number of hosts. At that size, you might also consider just rate-limiting hosts, so that you allow everyone, but if someone repeatedly connects and tries to send spam, you block them. This can be accomplished by means of connection tracking. Mind you, connection tracking can go horribly wrong if you have millions of hosts contacting you, but it should be fine at 670/day. That would mean something like this (untested, sorry):

iptables -A INPUT -p tcp --dport 21:25 -i eth0 -m conntrack --ctstate NEW -m recent --update --seconds 300 --hitcount 20 -j DROP iptables -A INPUT -p tcp --dport 21:25 -i eth0 -m conntrack --ctstate NEW -m recent --set

(Of course, you might want to whitelist people who send you tons of email.)

Improve this answer
1
  • This is incoming hacker attacks trying to guess passwords to gain access to an account and then send spam from it. Each block is 5 attempts, so near 3,500 hacking attempts a day. They have gotten through on weak passwords in the past, so now I require strong passwords. I'm not so concerned with how many emails can be sent, rather, blocking login attempts from hackers. Commented Jul 25, 2015 at 0:38
0

Alright, I've not gotten any good responses and it took trial and error, as well as monitoring to determine what works to achieve this.

I found some things were said to be needed, so the example up above might not work on all systems because a full path should be used on the executables. Also, when specifying a range of ports, you need to add in --match multiport otherwise it will ignore the rule entirely. Lastly, I added in a shebang at the top to ensure that the script will be run correctly by shell.

So here is the final version:

/usr/local/csf/bin/csfpre.sh

#!/bin/sh /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT /sbin/iptables -A INPUT -p all -s 60.168.112.0/20 -j DROP /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26 -s 1.0.0.0/8 -j DROP /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26 -s 112.0.0.0/7 -j DROP /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26 -s 116.96.0.0/12 -j DROP /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26 -s 116.118.0.0/16 -j DROP /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26,110,465,587,995 -s 117.0.0.0/8 -j DROP

Now for the breakdown of what is going on on this cPanel server with CSF installed for a firewall.

  1. CSF allows adding custom rules that run in separate groups. All groups ultimately are run by iptables. First, csfpre.sh, then CSF, then csfpost.sh.

  2. Create a csfpre.sh file if it doesn't exist. You can put this in the /etc/ folder somewhere too, but it will always take the version in /usr/local/csf/bin/ with priority.

  3. Add the shebang at the top:

    #!/bin/sh

  4. My plan is to do some port blocking via csfpre.sh, but rather than have it run through all the rules, I have it first detect whether the connection is for a webpage visit. By checking this first, it reduces the latency/response time.

    Ports 80 and 443 are for HTTP and HTTPS protocols, before anything else, if the input is for either of those ports, ACCEPT and stop checking rules for this csfpre group:

     /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT

  5. Now, we could just block entirely all other ports except for 80 and 443 if the next line is as such:

     /sbin/iptables -A INPUT -p all -s 60.168.112.0/20 -j DROP

    Since all web traffic is accepted already, this will not block the website traffic for that range. If this line came first, then it would block all traffic, including web traffic. I don't want to block good users from viewing websites by blocking all an entire subnet they are in.

  6. If blocking is reduced to specific ports, then we can block a specific port, a range, a list, or a combination of these.

    To only block FTP:

     /sbin/iptables -A INPUT -p tcp --dport 21 -s 1.0.0.0/8 -j DROP

    FTP actually uses a few different ports to establish a connection, and there also is SFTP/SSH which standardly is port 22 so better to block a range by using the starting port separated by a colon and then the ending port:

     /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26 -s 1.0.0.0/8 -j DROP

    You must use the --match multiport if you are using a range or a list. Lists can have no more than 15 ports, and each port in a range counts against the 15 total ports.

    You can also block the standard SMTP email ports:

     /sbin/iptables -A INPUT -p tcp --match multiport --dport 110,465,587,995 -s 117.0.0.0/8 -j DROP

    And, you can indeed use ranges in your list to block the FTP and mail ports in one rule:

     /sbin/iptables -A INPUT -p tcp --match multiport --dport 21:26,110,465,587,995 -s 117.0.0.0/8 -j DROP

  7. Save your script, and restart the firewall.

  8. Let CSF and cpHulk block individual IP addresses as needed.

You can use your smartphone while not using your local connection to test with. Get the IP address of your phone, and be sure it is not the same as the computer you'll be working from. You can then run through all the scenarios, assuming you have the phone set up to check or send email through your server and an FTP program as well.

For the blocking, I've decided to restrict entire subnets from accessing FTP, and for some, SMTP. In order to whittle it down, I've analyzed all the incoming alerts and then compared the worst subnets with the countries listed on this website: http://www.tcpiputils.com/browse/ip-address

The end goal is to reduce the number of individual IPs being blocked by CSF. Blocking thousands of IPs can cause a latency issue, so by having some standard rules to block countries rife with malicious users reduces the need to manage such a large number of individual IPs.

To recalculate valid subnet ranges, use this tool: http://www.subnet-calculator.com/cidr.php

112.0.0.0/7 spans 112.0.0.0 to 113.255.255.255, but 111.0.0.0/7 is invalid blocking, so it would be 110.0.0.0 to 111.255.255.255. It's important that you verify your subnet ranges so that you don't wind up blocking the wrong IPs.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.