Good point. Full disclosure - I don't use ipdeny.com and haven't looked at their terms.If you do that (which is nice) you should add a sleep a bit in the outer loop or you are likely breaking the ipdeny.com rules.
Good point. Full disclosure - I don't use ipdeny.com and haven't looked at their terms.If you do that (which is nice) you should add a sleep a bit in the outer loop or you are likely breaking the ipdeny.com rules.
Then I further offer
#!/bin/bash
cd /tmp
wget -qO - http://www.ipdeny.com/ipblocks/data/countries/all-zones.tar.gz| tar zxf -
for i in is ru ps kp ua md nl fi
do /usr/sbin/ipset create -exist $i hash:net
for j in $(cat $i.zone); do echo "add -exist $i $j"; done
done|ipset restore
exit 0
Which runs faster , thanks @Jerry3716 , and doesn't clutter up /etc, (don't see the need to restart iptables or fail2ban , nor the use of wait)
grep "INPUT -j IPSPF" /etc/sysconfig/iptables
sed -i 's|-A INPUT -j ASIP|-A INPUT -j IPSPF\n-A INPUT -j ASIP|' /etc/sysconfig/iptables
service iptables restart
service fail2ban restart
/usr/sbin/ipset create -exist badguys hash:net
/usr/sbin/ipset -A badguys 62.210.29.135
/usr/sbin/ipset list badguys
-A IPSPF -m set --match-set badguys src -j DROP
# save the file and then...
service iptables restart
service fail2ban restart
What platform?ipset restore hung forever on my test server.
What platform?
OK, must be something with the provider. The 6.10 boxes tested here (all under vmware) seem fine before and after a fresh yum update.CentOS 6.10, Incredible PBX, SnowVPS KVM.
We don't bother with per-country sets and keep the iptables rules clean with one single block-most-of-the-world set. At this point I'd probably be better off with a whitelist, but if it ain't broke....
And with all this talk - a general comment just to reiterate - admins need to first be comfortable with their firewall rules without geoblocking present.
Security through obscurity is not real security. Many dismiss it completely, but IMO geoblocking improves the odds, eliminates a ton of junk in the logs and hopefully makes any real problems easier to spot.
Using whatever FQDN you’ve chosen for SIP registrations, we’ll add an entry to /etc/asterisk/sip_custom.conf that looks like this: domain=hk76dl34z.yourdomain.com. That will block all SIP registration attempts except from that domain. It will not block SIP invitations! The next step will be to add a new [from-sip-external] context to extensions_override_freepbx.conf. Inside that context, we’ll specify the FQDN used for public SIP URI connections to your server, e.g. sip.yourdomain.com. This will block SIP invitations except SIP URIs containing that domain name.
@w1ve: Your example failure is showing an IP address failure: xxx.xxx.xxx.xxx. Access by IP address is blocked. You have to use an FQDN and insert it in the two places documented in the tutorial.
Link up your team and customers Phone System Live Chat Video Conferencing
Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.
Check your inbox!
We’ve sent you an email. Click on the button in the email body to verify your email address – (if you can not find it, check your spam folder).
Upon verification you will be directed to the 3CX setup wizard.