Forums

Resolved
1 votes
This is a question in regards to the following post:
https://www.clearos.com/clearfoundation/social/community/how-to-easily-block-whole-country-s-with-iptables#10382

I have ipset configured, I can do ipset list coutnry-list and it will list all the networks (cidr format).

I am adding the following rule to my firewall:
iptables -A COUNTRY_BLOCK -j LOG --log-level 4 --log-prefix "COUNTRY_BLOCK: "
iptables -A COUNTRY_BLOCK -j DROP
iptables -I INPUT -m set --match-set country-list src -m state --state NEW -j COUNTRY_BLOCK

I can see the rule added to the top of my INPUT chains;
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere match-set snortsam_INGRESS src
COUNTRY_BLOCK all -- anywhere anywhere match-set country-list src state NEW

I can see in my log file, things getting blocked;

Apr 12 12:18:04 gateway kernel: COUNTRY_BLOCK: IN=em2 OUT= MAC=c8:1f:66:ba:6d:08:50:c5:8d:d7:8d:51:08:00 SRC=5.188.9.25 DST=74.142.240.163 LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=32750 PROTO=TCP SPT=52654 DPT=43867 WINDOW=1024 RES=0x00 SYN URGP=0

However, it seems like some things are slipping through, and I'm not 100% sure why.

we have multiple virtual interfaces (ie: em1:0) and 1 to 1 nat rules setup, we will use FTP as an example. We have a public ip on em1:0 that has a 1 to 1 nat to our internal FTP server. I have China blocked, I can do; ipset test country-list 182.61.33.244 and get; 182.61.33.244 is in set country-list.

However, we can look at the FTP server connections and see someone from that IP hammering us trying to get it.

I can't figure out why. I've tried adding a rule like: iptables -I INPUT -d ourpublicip -m set --match-set country-list src -m state --state NEW -j COUNTRY_BLOCK to no avail. I've tried iptables -I INPUT -i em1:0 ... iptables -I INPUT -i em1+ etc etc etc to no avail.

I think it has something to do with the way ipset is matching maybe? I don't know. Maybe it's because of the virtual interfaces, though I do see BLOCKS on our other ip's etc.

Any ideas? I've tried everything I can think of, and pretty sure I might be missing something simple?

Thanks all :)

~Gary
Thursday, April 12 2018, 04:24 PM
Share this post:
Responses (6)
  • Accepted Answer

    Friday, April 13 2018, 04:52 PM - #Permalink
    Resolved
    0 votes
    What I do is make use of a feature/bug in ClearOS (actually I don't but you can). If you turn off SMTP authentication, you can still authenticate on port 465 with SMTPS. What I do then, is for all my mobile devices is open incoming tcp:465 and configure the e-mail clients to send on port 465. You can cheat and internally use Trusted Networks and ordinary SMTP on tcp:25 but it is less secure.

    Then I have severely clamped down on port 25. Any attempt at relaying is immediately blocked with fail2ban. Also you can tweak the smtp rule in Attack Detector (a front end for f2b) to be more aggressive. I've added a couple more jails.

    You can then country block on 465 as it will only be used by your users.

    The reason I say I don't use it is because I am a purist. Although it is common SMTPS on tcp:465 was never ratified as a standard. Instead the ratified standard uses STARTTLS on tcp:587 and I have set this up in postfix and use that instead, but the approach is the same.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, April 13 2018, 04:28 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    For incoming traffic it would be a "! --dport 25" rather than sport and note the double "-". Even the Chinese can register .com sites so you can't rely on .cn.


    Ahh, yes .. I forgot it had two -'s ... heh.

    Debating on not blocking port 25 ... Not that we do business with anyone outside of the country, it's hard to know where people might have a mail sever setting.. And if someone doesn't get an email, then yeah.

    I think I may open port 25 ...
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 12 2018, 08:24 PM - #Permalink
    Resolved
    1 votes
    For incoming traffic it would be a "! --dport 25" rather than sport and note the double "-". Even the Chinese can register .com sites so you can't rely on .cn.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 12 2018, 07:01 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Ah yes. I don't have anything on my LAN open to the internet so I don't block the FORWARD chain. If you have internal services exposed it is a good idea to protect them as well. Once you have your basic country list then it is just down to your firewall rules. Be careful of blocking you mailserver with country blocks. If you have a motherboard problem the likelihood is that support will be from China (but if you use Clearcenter's MX Backup you can get away with blocking China as you'll still receive replies via the MX Backup servers. Naughty. I only use it as a failsafe with aggressive Fail2ban blocks).


    Yes, was thinking about that. If anything I can add a ! -sport 25 or something to the rule. Or I'll use my personal email address, hahah :D
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 12 2018, 06:31 PM - #Permalink
    Resolved
    0 votes
    Ah yes. I don't have anything on my LAN open to the internet so I don't block the FORWARD chain. If you have internal services exposed it is a good idea to protect them as well. Once you have your basic country list then it is just down to your firewall rules. Be careful of blocking you mailserver with country blocks. If you have a motherboard problem the likelihood is that support will be from China (but if you use Clearcenter's MX Backup you can get away with blocking China as you'll still receive replies via the MX Backup servers. Naughty. I only use it as a failsafe with aggressive Fail2ban blocks).
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 12 2018, 06:05 PM - #Permalink
    Resolved
    0 votes
    I fixed it :D

    It was 1 to 1 causing the issue. Lets say my Mail Server is on 10.10.1.1 and my public IP is 99.99.1.1 ... if I have 1 to 1 NAT setup to forward port 25 on 99.99.1.1 to 10.10.1.1 then the packets get translated and don't match SRC on the INPUT chain. Instead they get match on the FORWARD chain. I had to add:

    $IPTABLES -I FORWARD -m set --match-set country-list src -m state --state NEW -j COUNTRY_BLOCK

    to my /etc/clearos/firewall.d/20-fwrules

    It's blocking incoming countries now to my FTP servers and Mail servers now :D
    The reply is currently minimized Show
Your Reply