Re: PF rules to block out every IP from a given country

2022-12-07 Thread Frank Habicht

Hi,

On 07/12/2022 18:36, Peter N. M. Hansteen wrote:
...> and can now be found at 
https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --

as it says in the script itself, a trivial hack.

And I might add, it comes with *NO* warranties of any kind.


I think instead of :
grep allocated
in the two important lines, it should be :
egrep '(allocated)|(assigned)'

coz both can go to countries.

Frank



Re: PF rules to block out every IP from a given country

2022-12-07 Thread Stuart Henderson
On 2022-12-07, Peter N. M. Hansteen  wrote:
> On Wed, Dec 07, 2022 at 10:28:27AM +1100, Damian McGuckin wrote:
>> 
>> Has anybody created rules such as this and if so, do you have an example?
>
> As others have already indicated, the PF way to do anything like this would be
> to generate a list of addresses and networks you want to address (block in 
> this case),
> feed that list into a table and make the table the criteria for a blocking 
> rule.
>
> I remembered that a few years back I was asked to do something along those 
> lines,
> I forget the exact reason why, but anyway I decided that the most reasonable 
> way
> to determine which IP addresses or ranges belong to a certain country would be
> to fetch the most up to date data from the things RIPE publish. 
>
> My tiny writeup which in fact contains the entire script for massaging RIPE's
> data into something you can feed into a PF table survived a couple of job 
> changes
> and can now be found at https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --
> as it says in the script itself, a trivial hack. 

# 16777216 -> /8 (Not actually found in RIPE data but with ARIN who knows)

btw there are /8's in the RIPE file now. Also prefix lengths smaller than
/26, even down to single addresses, so the subst will need some tweaks to
cover those.

> It is for example quite conceivable that an organization with premises in more
> than one country might want to split their allocations not strictly according
> to national borders.

And other specialities like anycast addresses, and as it's user-supplied
data it can't be completely relied upon. It changes often too; people using
this will want to arrange to keep it updated; allocations do change and
can move between countries (and, these days, even between regions).

It's likely that the output can be shrunk further by passing it through
aggregate6 (in ports).

-- 
Please keep replies on the mailing list.



Re: PF rules to block out every IP from a given country

2022-12-07 Thread Peter N. M. Hansteen
On Wed, Dec 07, 2022 at 10:28:27AM +1100, Damian McGuckin wrote:
> 
> Has anybody created rules such as this and if so, do you have an example?

As others have already indicated, the PF way to do anything like this would be
to generate a list of addresses and networks you want to address (block in this 
case),
feed that list into a table and make the table the criteria for a blocking rule.

I remembered that a few years back I was asked to do something along those 
lines,
I forget the exact reason why, but anyway I decided that the most reasonable way
to determine which IP addresses or ranges belong to a certain country would be
to fetch the most up to date data from the things RIPE publish. 

My tiny writeup which in fact contains the entire script for massaging RIPE's
data into something you can feed into a PF table survived a couple of job 
changes
and can now be found at https://nxdomain.no/~peter/ripe2cidr_country.sh.txt --
as it says in the script itself, a trivial hack. 

And I might add, it comes with *NO* warranties of any kind. 

It is for example quite conceivable that an organization with premises in more
than one country might want to split their allocations not strictly according
to national borders.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: PF rules to block out every IP from a given country

2022-12-07 Thread Muhammad Muntaza
On Wed, 7 Dec 2022 at 08.55 Damian McGuckin  wrote:

>
> Has anybody created rules such as this and if so, do you have an example?
>
> Stay safe - Damian
>

Check this Example:

https://www.muntaza.id/pf/2020/02/03/pf-firewall-bagian-kedua.html

I write in Indonesia, you can use Google Translate to read it.


Thanks,

Muhammad Muntaza bin Hatta



>


Re: PF rules to block out every IP from a given country

2022-12-06 Thread Craig Schulz
Take a look at PF-Badhost.

Here is a decent write-up:

https://undeadly.org/cgi?action=article;sid=20210119113425

Craig

> On Dec 6, 2022, at 18:28, Damian McGuckin  wrote:
> 
> 
> Has anybody created rules such as this and if so, do you have an example?
> 
> Stay safe - Damian
> 
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer
> 



signature.asc
Description: Message signed with OpenPGP


Re: PF rules to block out every IP from a given country

2022-12-06 Thread All
Considering you solved the issue with getting all IPs
for a given country correctly (and perhaps updating it sometimes):
1. Dump all IP addresses/ranges into a file (eg. blocked.ips)
2. add table  file  /path/to/blocked.ips
add "persist" if you want.
3. create rule to block all incoming connections from  

Alternatively, you can just create a file with IPs you allow, 
create table and write rules to allow connections from IPs
in that file. 

On Wednesday, December 7, 2022 at 09:44:34 a.m. GMT+9, Damian McGuckin 
 wrote: 






Has anybody created rules such as this and if so, do you have an example?

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer