You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lonnie A. <li...@lo...> - 2021-12-13 15:13:01
|
Hi Ramesh,
I don't use nano myself ('vi' commands are involuntary to me), though I have replicated your findings.
Even if you make a text change in nano and ^X ...
--
Save modified buffer? (Answering "No" will DISCARD changes.) N
--
nano will *still* write out the original file!
I would be open to a patch to nano (2.7.5) to fix this awful behavior.
There is a -v (--view) option to nano (View mode (read-only)) which solves the problem.
pbx4 ~ # nano -v /etc/shells
Possibly create a bash alias "view"
pbx4 ~ # alias view='nano -v'
would support nano read-only mode
pbx4 ~ # view /etc/shells
BTW Ramesh, I seem to recall you appreciate "classic" software, the 'ne' editor is much better than nano (IMHO) and 'ne' originated for the Amiga, a Copyright going back to 1992 in the source. 30 years of good stuff, and still maintained. Included by default in AstLinux.
ne, the nice editor
https://ne.di.unimi.it/
Lonnie
> On Dec 13, 2021, at 7:57 AM, Ramesh GK <ram...@ho...> wrote:
>
> Hi Lonnie,
>
> Thanks for checking. you are correct. If i open the file in /mnt/asturo/etc/shells then no corresponding file is getting created in /mnt/asturw but if I open the file /etc/shells then a corresponding file is getting created in /mnt/asturw as it is an overlay of /mnt/asturo for /etc.
>
> i tried to do the same tests that you have done below and figured out the issue. Looks like the issue is occuring because of nano. I use nano for file review or editing mostly. whenever I open the file in nano and close it without making any modifications, it is still trying to save the file i guess. that was the reason a corresponding entry is getting created in /mnt/asturw.
>
> Thanks
> Ramesh GK
> From: Lonnie Abelbeck <li...@lo...>
> Sent: Sunday, December 12, 2021 6:30 PM
> To: AstLinux Developers Mailing List <ast...@li...>
> Subject: Re: [Astlinux-devel] Duplicated files in ASTURW
>
> Hi Ramesh,
>
> >> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
>
>
> I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
>
> On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
>
> For example:
>
> pbx4 ~ # ls -l /etc/shells
> -rw-r--r-- 1 root root 38 Apr 6 2020 /etc/shells
> pbx4 ~ # ls -l /mnt/asturo/etc/shells
> -rw-r--r-- 1 root root 38 Apr 6 2020 /mnt/asturo/etc/shells
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> Then "cat /etc/shells"
>
> pbx4 ~ # cat /etc/shells
>
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> Note it is not copied to /mnt/asturw
>
> Also, use an editor and quit without writing ...
>
> pbx4 ~ # vi /etc/shells
> Enter-> :q
>
> pbx4 ~ # ne /etc/shells
> Enter-> <ESC>q or CTL-q
>
> pbx4 ~ # ls -l /mnt/asturw/etc/shells
> ls: /mnt/asturw/etc/shells: No such file or directory
>
> So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
>
> Lonnie
>
>
> > On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
> >
> > Hi,
> >
> > A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
> >
> > When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
> >
> > I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
> >
> > /etc/init.d/misc
> > cleanup_asturw() {
> > local dir1=/mnt/asturo
> > local dir2=/mnt/asturw
> >
> > for newfile in $(find $dir2 -type f); do
> > if [ -e "${newfile/${dir2}/${dir1}}" ]; then
> > file=${newfile/${dir2}/${dir1}}
> > if cmp -s "$file" "$newfile" ; then
> > # echo "Cleaning up -> $newfile"
> > rm -f $newfile
> > fi
> > fi
> > done
> > }
> >
> > mhtgw ~ # stat /etc/common_functions.sh
> > File: /etc/common_functions.sh
> > Size: 4038 Blocks: 8 IO Block: 1024 regular file
> > Device: 12h/18d Inode: 34824 Links: 1
> > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:52:40.000000000
> >
> > mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
> > File: /mnt/asturo/etc/common_functions.sh
> > Size: 4038 Blocks: 8 IO Block: 4096 regular file
> > Device: ch/12d Inode: 3360 Links: 1
> > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:47:12.000000000
> >
> > mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
> > File: /mnt/asturw/etc/common_functions.sh
> > Size: 4038 Blocks: 8 IO Block: 1024 regular file
> > Device: 802h/2050d Inode: 34824 Links: 1
> > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> > Access: 2021-12-12 04:51:16.000000000
> > Modify: 2021-12-12 04:51:16.000000000
> > Change: 2021-12-12 20:52:40.000000000
> >
> > Any thoughts or ideas are greatly appreciated
> >
> > Thanks
> > Ramesh GK
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&reserved=0
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&reserved=0
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Ramesh GK <ram...@ho...> - 2021-12-13 13:57:34
|
Hi Lonnie,
Thanks for checking. you are correct. If i open the file in /mnt/asturo/etc/shells then no corresponding file is getting created in /mnt/asturw but if I open the file /etc/shells then a corresponding file is getting created in /mnt/asturw as it is an overlay of /mnt/asturo for /etc.
i tried to do the same tests that you have done below and figured out the issue. Looks like the issue is occuring because of nano. I use nano for file review or editing mostly. whenever I open the file in nano and close it without making any modifications, it is still trying to save the file i guess. that was the reason a corresponding entry is getting created in /mnt/asturw.
Thanks
Ramesh GK
________________________________
From: Lonnie Abelbeck <li...@lo...>
Sent: Sunday, December 12, 2021 6:30 PM
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] Duplicated files in ASTURW
Hi Ramesh,
>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
For example:
pbx4 ~ # ls -l /etc/shells
-rw-r--r-- 1 root root 38 Apr 6 2020 /etc/shells
pbx4 ~ # ls -l /mnt/asturo/etc/shells
-rw-r--r-- 1 root root 38 Apr 6 2020 /mnt/asturo/etc/shells
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
Then "cat /etc/shells"
pbx4 ~ # cat /etc/shells
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
Note it is not copied to /mnt/asturw
Also, use an editor and quit without writing ...
pbx4 ~ # vi /etc/shells
Enter-> :q
pbx4 ~ # ne /etc/shells
Enter-> <ESC>q or CTL-q
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
Lonnie
> On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
>
> Hi,
>
> A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
>
> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
>
> I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
>
> /etc/init.d/misc
> cleanup_asturw() {
> local dir1=/mnt/asturo
> local dir2=/mnt/asturw
>
> for newfile in $(find $dir2 -type f); do
> if [ -e "${newfile/${dir2}/${dir1}}" ]; then
> file=${newfile/${dir2}/${dir1}}
> if cmp -s "$file" "$newfile" ; then
> # echo "Cleaning up -> $newfile"
> rm -f $newfile
> fi
> fi
> done
> }
>
> mhtgw ~ # stat /etc/common_functions.sh
> File: /etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 1024 regular file
> Device: 12h/18d Inode: 34824 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:52:40.000000000
>
> mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
> File: /mnt/asturo/etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 4096 regular file
> Device: ch/12d Inode: 3360 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:47:12.000000000
>
> mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
> File: /mnt/asturw/etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 1024 regular file
> Device: 802h/2050d Inode: 34824 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:52:40.000000000
>
> Any thoughts or ideas are greatly appreciated
>
> Thanks
> Ramesh GK
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&reserved=0
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fastlinux-devel&data=04%7C01%7C%7C9db4a4d4f17a4f87777a08d9bdc77ac1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637749486727083129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Q4hXhcdxsh8KAFWU3ff9vnN1EzLSu2O%2F8VEYQztaWs%3D&reserved=0
|
|
From: Lonnie A. <li...@lo...> - 2021-12-12 23:30:57
|
Hi Ramesh,
>> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw.
I'm not sure what "open any file" means ... if you open a file on /mnt/asturo read-only then no file should be written to /mnt/asturw.
On the other hand, if you open a file on /mnt/asturo and change the contents, timestamp or write to it, then a corresponding change to /mnt/asturw will occur.
For example:
pbx4 ~ # ls -l /etc/shells
-rw-r--r-- 1 root root 38 Apr 6 2020 /etc/shells
pbx4 ~ # ls -l /mnt/asturo/etc/shells
-rw-r--r-- 1 root root 38 Apr 6 2020 /mnt/asturo/etc/shells
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
Then "cat /etc/shells"
pbx4 ~ # cat /etc/shells
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
Note it is not copied to /mnt/asturw
Also, use an editor and quit without writing ...
pbx4 ~ # vi /etc/shells
Enter-> :q
pbx4 ~ # ne /etc/shells
Enter-> <ESC>q or CTL-q
pbx4 ~ # ls -l /mnt/asturw/etc/shells
ls: /mnt/asturw/etc/shells: No such file or directory
So in summary, try to understand why the /mnt/asturo files are getting written to when you don't want them to.
Lonnie
> On Dec 12, 2021, at 3:13 PM, Ramesh GK <ram...@ho...> wrote:
>
> Hi,
>
> A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
>
> When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
>
> I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
>
> /etc/init.d/misc
> cleanup_asturw() {
> local dir1=/mnt/asturo
> local dir2=/mnt/asturw
>
> for newfile in $(find $dir2 -type f); do
> if [ -e "${newfile/${dir2}/${dir1}}" ]; then
> file=${newfile/${dir2}/${dir1}}
> if cmp -s "$file" "$newfile" ; then
> # echo "Cleaning up -> $newfile"
> rm -f $newfile
> fi
> fi
> done
> }
>
> mhtgw ~ # stat /etc/common_functions.sh
> File: /etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 1024 regular file
> Device: 12h/18d Inode: 34824 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:52:40.000000000
>
> mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
> File: /mnt/asturo/etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 4096 regular file
> Device: ch/12d Inode: 3360 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:47:12.000000000
>
> mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
> File: /mnt/asturw/etc/common_functions.sh
> Size: 4038 Blocks: 8 IO Block: 1024 regular file
> Device: 802h/2050d Inode: 34824 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2021-12-12 04:51:16.000000000
> Modify: 2021-12-12 04:51:16.000000000
> Change: 2021-12-12 20:52:40.000000000
>
> Any thoughts or ideas are greatly appreciated
>
> Thanks
> Ramesh GK
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Ramesh GK <ram...@ho...> - 2021-12-12 21:13:36
|
Hi,
A while back I reached out of using AstLinux as a Home Gateway Appliance. I am working on the same and observed a weird issue. I migrated the entire build system to buildroot-2017.02.11 and the packages merged between (buildroot and AstLinux) and fixed all (mostly) issues. Happy to share the code base but it is still in beta with a working firmware image as I have not tested the Asterisk components.
When I startup the firmware image and open any file in /mnt/asturo (/etc or /stat) that does not have a link to /tmp, it creates a duplicate file in /mnt/asturw. This should not pose a problem if both files are same however when the firmware image is updated. the file in /mnt/asturo is newer than the file in /mnt/asturw which became stale as it was kept back with the assumption that the file contents have changed but it was in fact the file attributes that got changed.
I could not able to find a cleaner approach and thought of checking if there is any clean way of making sure that the files do not become stale. for now I put in a temporary fix that seem to be working which checks on startup and shutdown if the files between /mnt/asturo and /mnt/asturw are same and if yes then remove the files from /mnt/asturw so they do not become stale.
/etc/init.d/misc
cleanup_asturw() {
local dir1=/mnt/asturo
local dir2=/mnt/asturw
for newfile in $(find $dir2 -type f); do
if [ -e "${newfile/${dir2}/${dir1}}" ]; then
file=${newfile/${dir2}/${dir1}}
if cmp -s "$file" "$newfile" ; then
# echo "Cleaning up -> $newfile"
rm -f $newfile
fi
fi
done
}
mhtgw ~ # stat /etc/common_functions.sh
File: /etc/common_functions.sh
Size: 4038 Blocks: 8 IO Block: 1024 regular file
Device: 12h/18d Inode: 34824 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-12-12 04:51:16.000000000
Modify: 2021-12-12 04:51:16.000000000
Change: 2021-12-12 20:52:40.000000000
mhtgw ~ # stat /mnt/asturo/etc/common_functions.sh
File: /mnt/asturo/etc/common_functions.sh
Size: 4038 Blocks: 8 IO Block: 4096 regular file
Device: ch/12d Inode: 3360 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-12-12 04:51:16.000000000
Modify: 2021-12-12 04:51:16.000000000
Change: 2021-12-12 20:47:12.000000000
mhtgw ~ # stat /mnt/asturw/etc/common_functions.sh
File: /mnt/asturw/etc/common_functions.sh
Size: 4038 Blocks: 8 IO Block: 1024 regular file
Device: 802h/2050d Inode: 34824 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-12-12 04:51:16.000000000
Modify: 2021-12-12 04:51:16.000000000
Change: 2021-12-12 20:52:40.000000000
Any thoughts or ideas are greatly appreciated
Thanks
Ramesh GK
|
|
From: Lonnie A. <li...@lo...> - 2021-11-02 15:57:55
|
Announcing AstLinux Release: 1.4.4 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.4 Highlights: * Asterisk Versions: 13.38.3, 16.21.1 * Added SIP threats blocklist 'apiban', requires an API Key in /mnt/kd/apiban.conf via https://apiban.org/ * Traffic Shaping, add CAKE support, both "Network -> Firewall -> Traffic Shaping" and "Network -> WAN Failover" * 2.5G ethernet support for Intel i225 (igc) and Realtek RTL8125 (r8125) NICs * '13se' version now uses Asterisk 13.38.3, "Security Fixes Only" version for Asterisk 13 * Linux Kernel 4.19.208, security and bug fixes * RUNNIX, version bump to runnix-0.6.5 * OpenSSL, version bump to 1.1.1l, security fixes * LibreTLS, version bump to 3.4.1 * WireGuard VPN, module 1.0.20210606 (no change), tools 1.0.20210914 (version bump) * libcurl (curl) version bump to 7.79.1 * arnofw (AIF), reload-blocklist-netset script, add support for 'apiban' * acme-client, version bump to 2.9.0 * Monit, version bump to 5.29.0 * prosody, version bump to 0.11.10 * vnStat, version bump to 2.8 * zabbix, version bump to 4.0.35 * Asterisk '13se' (stable edition) version 13.38.3 is the latest Asterisk 13.x "Security Fixes Only" version, built --without-pjproject * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.4/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2021-11-02 15:38:24
|
Announcing AstLinux Release: 1.4.4 More Info: AstLinux Project https://www.astlinux-project.org/ AstLinux 1.4.3 Highlights: * Asterisk Versions: 13.38.3, 16.21.1 * Added SIP threats blocklist 'apiban', requires an API Key in /mnt/kd/apiban.conf via https://apiban.org/ * Traffic Shaping, add CAKE support, both "Network -> Firewall -> Traffic Shaping" and "Network -> WAN Failover" * 2.5G ethernet support for Intel i225 (igc) and Realtek RTL8125 (r8125) NICs * '13se' version now uses Asterisk 13.38.3, "Security Fixes Only" version for Asterisk 13 * Linux Kernel 4.19.208, security and bug fixes * RUNNIX, version bump to runnix-0.6.5 * OpenSSL, version bump to 1.1.1l, security fixes * LibreTLS, version bump to 3.4.1 * WireGuard VPN, module 1.0.20210606 (no change), tools 1.0.20210914 (version bump) * libcurl (curl) version bump to 7.79.1 * arnofw (AIF), reload-blocklist-netset script, add support for 'apiban' * acme-client, version bump to 2.9.0 * Monit, version bump to 5.29.0 * prosody, version bump to 0.11.10 * vnStat, version bump to 2.8 * zabbix, version bump to 4.0.35 * Asterisk '13se' (stable edition) version 13.38.3 is the latest Asterisk 13.x "Security Fixes Only" version, built --without-pjproject * Package upgrades providing important security and bug fixes Full ChangeLog: https://raw.githubusercontent.com/astlinux-project/astlinux/1.4.4/docs/ChangeLog.txt All users are encouraged to upgrade, read the ChangeLog for the details. AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2021-10-23 13:19:34
|
Announcing AstLinux Pre-Release: astlinux-1.4-5283-f45591 Release Candidate1 pre-1.4.4, please report any issues, ASAP. Key new features: -- Added SIP threats blocklist 'apiban', requires an API Key in /mnt/kd/apiban.conf via https://apiban.org/ -- Traffic Shaping, add CAKE support, both "Network -> Firewall -> Traffic Shaping" and "Network -> WAN Failover" -- 2.5G ethernet support for Intel i225 (igc) and Realtek RTL8125 (r8125) NICs -- '13se' version now uses Asterisk 13.38.3, "Security Fixes Only" version for Asterisk 13 ** The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 4.19.208 (version bump), security and bug fixes -- ixgbe, enable the Intel 10-Gigabit Ethernet Network Driver -- igc, backport from linux-5.4.148, Intel i225 2.5-Gigabit Ethernet Network Driver -- r8125, version 9.006.04, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver -- igb, version bump to 5.8.5, Intel 1.0-Gigabit Ethernet Network Driver -- OpenSSL, version bump to 1.1.1l, security fixes: CVE-2021-3711, CVE-2021-3712 -- libcurl (curl) version bump to 7.79.1, several security fixes -- prosody, version bump to 0.11.10, security fix: CVE-2021-37601 -- arnofw (AIF), reload-blocklist-netset script, add support for 'apiban' Note: 'apiban' requires an API Key in /mnt/kd/apiban.conf via https://apiban.org/ More info: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists -- acme-client, version bump to 2.9.0 -- Monit, version bump to 5.29.0 -- zabbix, version bump to 4.0.35 -- vnStat, version bump to 2.8 -- Asterisk 13.38.3 ('13se' version bump) Latest Asterisk 13.x "Security Fixes Only" version, built --without-pjproject -- Asterisk 13.38.3 (version bump) and 16.21.1 (version bump) New Asterisk 16 applications: WaitForCondition, Reload, StoreDTMF, SendMF New Asterisk 16 functions: FRAME_DROP, SAYFILES, SCRAMBLE -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2021-10-22 14:41:52
|
Update, The APIBAN folks have added a new ipset API [1]. This greatly simplifies things, no gathering JSON elements 250 IPs at a time, instead it is a simple text download (with a valid apikey). Also the ban list can be retrieved with one HTTPS session, not N+1 for each 250 IPs. Re-add 'apiban' support to reload-blocklist-netset using new ipset API https://github.com/astlinux-project/astlinux/commit/ab9127a6d86809caaeb903004b39a616deced5a5 The previous apiban-netset PHP script is now removed. If you have an AstLinux 1.4.3 or earlier system, you could copy the latest 'reload-blocklist-netset' to /mnt/kd/bin/ and reference it from crontab. No helper PHP script needed. reload-blocklist-netset: https://github.com/astlinux-project/astlinux/blob/master/package/arnofw/reload-blocklist-netset BTW, we will shortly be offering a AstLinux 1.4.4 pre-release including this feature. Lonnie [1] https://apiban.org/doc.html > On Oct 15, 2021, at 2:25 PM, Lonnie Abelbeck <li...@lo...> wrote: > > APIBAN support has been added to what will be AstLinux 1.4.4 > > https://github.com/astlinux-project/astlinux/commit/5f2b315f302805cf73218a1dcf332f130abc328d > > Updated Docs: > https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists > > Thanks for the suggestion, we can test to see how it works. > > Lonnie > >> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote: >> >> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >> I assume that banned IP addresses could just be pulled into a netset list? >> >> https://apiban.org/doc.html >> https://www.securevoip.io/48-hours-with-apiban/ >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Michael K. <mic...@ip...> - 2021-10-15 21:39:05
|
Thanks Lonnie. That was quick.
Regards
Michael Knill
On 16/10/21, 6:25 am, "Lonnie Abelbeck" <li...@lo...> wrote:
APIBAN support has been added to what will be AstLinux 1.4.4
https://github.com/astlinux-project/astlinux/commit/5f2b315f302805cf73218a1dcf332f130abc328d
Updated Docs:
https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists
Thanks for the suggestion, we can test to see how it works.
Lonnie
> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote:
>
> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
> I assume that banned IP addresses could just be pulled into a netset list?
>
> https://apiban.org/doc.html
> https://www.securevoip.io/48-hours-with-apiban/
>
> Regards
>
> Michael Knill
> Managing Director
>
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>
> <image001.png>
> Smarter Business Communications
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2021-10-15 19:25:26
|
APIBAN support has been added to what will be AstLinux 1.4.4 https://github.com/astlinux-project/astlinux/commit/5f2b315f302805cf73218a1dcf332f130abc328d Updated Docs: https://doc.astlinux-project.org/userdoc:tt_firewall_external_block_list#updating_netset_blocklists Thanks for the suggestion, we can test to see how it works. Lonnie > On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote: > > APIBAN looks very interesting. There will be a session on it at Astricon this year as well. > I assume that banned IP addresses could just be pulled into a netset list? > > https://apiban.org/doc.html > https://www.securevoip.io/48-hours-with-apiban/ > > Regards > > Michael Knill > Managing Director > > D: +61 2 6189 1360 > P: +61 2 6140 4656 > E: mic...@ip... > W: ipcsolutions.com.au > > <image001.png> > Smarter Business Communications > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2021-10-15 15:34:26
|
Sent from a mobile device. Michael Keuter > Am 15.10.2021 um 17:17 schrieb Lonnie Abelbeck <li...@lo...>: > > Hi Michael, > >>> The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). >> >> Update: I forgot - the other point is: for the other netsets there is timespan of an hour set before you can update again. >> For apiban this limit is 11 connects in 2 minutes! Not that I need it that often :-). > > FYI, it currently takes 3 "connects" to download the full list, as the list grows it will take more ... N+1 connects for each 250 set of IPs. Thanks for clarifying, didn‘t know that. > Testing with apiban-netset this morning it went a couple hours before the results changed. If a person is sharing the same apiban.conf across different boxes, the reload-blocklist-netset crontabs should be staggered by at least 2+ minutes, 5 to be safe. I did it exactly with 5 minutes :-). > I tested the '11 connects in 2 minutes" rate limiting, and it is exactly that. > > >>> "reload-blocklist-netset /mnt/kd/blocklists apiban" > > Good point. Being able to selectively update 'apiban' is an interesting idea. Using an AGE=600 (10 minutes) will keep it from accidentally updating too often. Yes, 10 minutes is fine. > Lonnie > > > >>> On Oct 15, 2021, at 9:37 AM, Michael Keuter <li...@mk...> wrote: >>> >>> >>> >>>> Am 15.10.2021 um 16:33 schrieb Michael Keuter <li...@mk...>: >>> >>> >>> >>>> Am 15.10.2021 um 16:20 schrieb Lonnie Abelbeck <li...@lo...>: >>>> >>>> OK, but if your concern is that "this is not for everyone IMHO" if it were under 'asterisk' apiban-netset would only be called if /mnt/kd/apiban.conf exists (without the key apiban doesn't work). >>>> >>>> The difference would be: >>>> >>>> 'asterisk.netset' -> blocklist_de_sip.ipset + apiban-netset (if apiban.conf exists) >>>> >>>> or >>>> >>>> 'asterisk.netset' -> blocklist_de_sip.ipset >>>> >>>> 'apiban.netset' -> apiban-netset (error if apiban.conf does not exists) >>>> >>>> >>>> I'm thinking keeping it under 'asterisk' is the least work for users. But I have no firm opinion either way. >>> >>> My main reason is the possibility to update it separate from the other netsets more often. >>> >>> "reload-blocklist-netset /mnt/kd/blocklists apiban" >>> >>> The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). >> >> Update: I forgot - the other point is: for the other netsets there is timespan of an hour set before you can update again. >> For apiban this limit is 11 connects in 2 minutes! Not that I need it that often :-). >> >>>> Lonnie >>>> >>>> >>>> >>>>> On Oct 15, 2021, at 9:01 AM, Michael Keuter <li...@mk...> wrote: >>>>> >>>>> I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. >>>>> On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. >>>>> >>>>> ---- >>>>> ## update blocklists >>>>> 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 >>>>> ## Test apiban >>>>> 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload >>>>> ---- >>>>> >>>>>> Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: >>>>>> >>>>>> Thanks Michael for testing. >>>>>> >>>>>> Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. >>>>>> >>>>>> If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>>> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >>>>>>> >>>>>>> Hi Lonnie, >>>>>>> >>>>>>> thanks for your work! >>>>>>> The script works fine and the blocked addresses seem to be very precise. >>>>>>> >>>>>>> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >>>>>>> >>>>>>>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>>>>>>> >>>>>>>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>>>>>>> >>>>>>>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>>>>>>> >>>>>>>> Remove the trailing .php and make apiban-netset executable. >>>>>>>> >>>>>>>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>>>>>>> >>>>>>>> We can decide if we want this in production AstLinux. >>>>>>>> >>>>>>>> Lonnie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>>>>>>> >>>>>>>>> Michael, thanks for bringing APIBAN to our attention. >>>>>>>>> >>>>>>>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>>>>>>> >>>>>>>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>>>>>>> >>>>>>>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>>>>>>> >>>>>>>>> Possibly there are other sip/asterisk related blocklists? >>>>>>>>> >>>>>>>>> Lonnie >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>>>>>>> >>>>>>>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>>>>>>> Should be pretty easy to do! >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Michael Knill >>>>>>>>>> >>>>>>>>>> From: Michael Keuter <li...@mk...> >>>>>>>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>>>>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>>>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>>>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>>>>>>> >>>>>>>>>> Quite interesting thread about apiban: >>>>>>>>>> >>>>>>>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>>>>>>> >>>>>>>>>> Sent from a mobile device. >>>>>>>>>> >>>>>>>>>> Michael Keuter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>>>>>>> >>>>>>>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>>>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>>>>>>> >>>>>>>>>>> https://apiban.org/doc.html >>>>>>>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Michael Knill >>>>>>>>>>> Managing Director >>>>>>>>>>> >>>>>>>>>>> D: +61 2 6189 1360 >>>>>>>>>>> P: +61 2 6140 4656 >>>>>>>>>>> E: mic...@ip... >>>>>>>>>>> W: ipcsolutions.com.au >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <image001.png> >>>>>>>>>>> Smarter Business Communications >>>>>>>>>>> >>> >>> >>> Michael >>> >>> http://www.mksolutions.info >> >> >> Michael >> >> http://www.mksolutions.info >> >> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Lonnie A. <li...@lo...> - 2021-10-15 15:17:19
|
Hi Michael, >> The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). > > Update: I forgot - the other point is: for the other netsets there is timespan of an hour set before you can update again. > For apiban this limit is 11 connects in 2 minutes! Not that I need it that often :-). FYI, it currently takes 3 "connects" to download the full list, as the list grows it will take more ... N+1 connects for each 250 set of IPs. Testing with apiban-netset this morning it went a couple hours before the results changed. If a person is sharing the same apiban.conf across different boxes, the reload-blocklist-netset crontabs should be staggered by at least 2+ minutes, 5 to be safe. I tested the '11 connects in 2 minutes" rate limiting, and it is exactly that. >> "reload-blocklist-netset /mnt/kd/blocklists apiban" Good point. Being able to selectively update 'apiban' is an interesting idea. Using an AGE=600 (10 minutes) will keep it from accidentally updating too often. Lonnie > On Oct 15, 2021, at 9:37 AM, Michael Keuter <li...@mk...> wrote: > > > >> Am 15.10.2021 um 16:33 schrieb Michael Keuter <li...@mk...>: >> >> >> >>> Am 15.10.2021 um 16:20 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> OK, but if your concern is that "this is not for everyone IMHO" if it were under 'asterisk' apiban-netset would only be called if /mnt/kd/apiban.conf exists (without the key apiban doesn't work). >>> >>> The difference would be: >>> >>> 'asterisk.netset' -> blocklist_de_sip.ipset + apiban-netset (if apiban.conf exists) >>> >>> or >>> >>> 'asterisk.netset' -> blocklist_de_sip.ipset >>> >>> 'apiban.netset' -> apiban-netset (error if apiban.conf does not exists) >>> >>> >>> I'm thinking keeping it under 'asterisk' is the least work for users. But I have no firm opinion either way. >> >> My main reason is the possibility to update it separate from the other netsets more often. >> >> "reload-blocklist-netset /mnt/kd/blocklists apiban" >> >> The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). > > Update: I forgot - the other point is: for the other netsets there is timespan of an hour set before you can update again. > For apiban this limit is 11 connects in 2 minutes! Not that I need it that often :-). > >>> Lonnie >>> >>> >>> >>>> On Oct 15, 2021, at 9:01 AM, Michael Keuter <li...@mk...> wrote: >>>> >>>> I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. >>>> On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. >>>> >>>> ---- >>>> ## update blocklists >>>> 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 >>>> ## Test apiban >>>> 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload >>>> ---- >>>> >>>>> Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: >>>>> >>>>> Thanks Michael for testing. >>>>> >>>>> Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. >>>>> >>>>> If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? >>>>> >>>>> Lonnie >>>>> >>>>> >>>>>> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >>>>>> >>>>>> Hi Lonnie, >>>>>> >>>>>> thanks for your work! >>>>>> The script works fine and the blocked addresses seem to be very precise. >>>>>> >>>>>> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >>>>>> >>>>>>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>>>>>> >>>>>>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>>>>>> >>>>>>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>>>>>> >>>>>>> Remove the trailing .php and make apiban-netset executable. >>>>>>> >>>>>>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>>>>>> >>>>>>> We can decide if we want this in production AstLinux. >>>>>>> >>>>>>> Lonnie >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>>>>>> >>>>>>>> Michael, thanks for bringing APIBAN to our attention. >>>>>>>> >>>>>>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>>>>>> >>>>>>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>>>>>> >>>>>>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>>>>>> >>>>>>>> Possibly there are other sip/asterisk related blocklists? >>>>>>>> >>>>>>>> Lonnie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>>>>>> >>>>>>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>>>>>> Should be pretty easy to do! >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Michael Knill >>>>>>>>> >>>>>>>>> From: Michael Keuter <li...@mk...> >>>>>>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>>>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>>>>>> >>>>>>>>> Quite interesting thread about apiban: >>>>>>>>> >>>>>>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>>>>>> >>>>>>>>> Sent from a mobile device. >>>>>>>>> >>>>>>>>> Michael Keuter >>>>>>>>> >>>>>>>>> >>>>>>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>>>>>> >>>>>>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>>>>>> >>>>>>>>>> https://apiban.org/doc.html >>>>>>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Michael Knill >>>>>>>>>> Managing Director >>>>>>>>>> >>>>>>>>>> D: +61 2 6189 1360 >>>>>>>>>> P: +61 2 6140 4656 >>>>>>>>>> E: mic...@ip... >>>>>>>>>> W: ipcsolutions.com.au >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <image001.png> >>>>>>>>>> Smarter Business Communications >>>>>>>>>> >> >> >> Michael >> >> http://www.mksolutions.info > > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Michael K. <li...@mk...> - 2021-10-15 14:38:04
|
> Am 15.10.2021 um 16:33 schrieb Michael Keuter <li...@mk...>: > > > >> Am 15.10.2021 um 16:20 schrieb Lonnie Abelbeck <li...@lo...>: >> >> OK, but if your concern is that "this is not for everyone IMHO" if it were under 'asterisk' apiban-netset would only be called if /mnt/kd/apiban.conf exists (without the key apiban doesn't work). >> >> The difference would be: >> >> 'asterisk.netset' -> blocklist_de_sip.ipset + apiban-netset (if apiban.conf exists) >> >> or >> >> 'asterisk.netset' -> blocklist_de_sip.ipset >> >> 'apiban.netset' -> apiban-netset (error if apiban.conf does not exists) >> >> >> I'm thinking keeping it under 'asterisk' is the least work for users. But I have no firm opinion either way. > > My main reason is the possibility to update it separate from the other netsets more often. > > "reload-blocklist-netset /mnt/kd/blocklists apiban" > > The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). Update: I forgot - the other point is: for the other netsets there is timespan of an hour set before you can update again. For apiban this limit is 11 connects in 2 minutes! Not that I need it that often :-). >> Lonnie >> >> >> >>> On Oct 15, 2021, at 9:01 AM, Michael Keuter <li...@mk...> wrote: >>> >>> I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. >>> On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. >>> >>> ---- >>> ## update blocklists >>> 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 >>> ## Test apiban >>> 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload >>> ---- >>> >>>> Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: >>>> >>>> Thanks Michael for testing. >>>> >>>> Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. >>>> >>>> If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? >>>> >>>> Lonnie >>>> >>>> >>>>> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >>>>> >>>>> Hi Lonnie, >>>>> >>>>> thanks for your work! >>>>> The script works fine and the blocked addresses seem to be very precise. >>>>> >>>>> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >>>>> >>>>>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>>>>> >>>>>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>>>>> >>>>>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>>>>> >>>>>> Remove the trailing .php and make apiban-netset executable. >>>>>> >>>>>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>>>>> >>>>>> We can decide if we want this in production AstLinux. >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>>>>> >>>>>>> Michael, thanks for bringing APIBAN to our attention. >>>>>>> >>>>>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>>>>> >>>>>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>>>>> >>>>>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>>>>> >>>>>>> Possibly there are other sip/asterisk related blocklists? >>>>>>> >>>>>>> Lonnie >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>>>>> >>>>>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>>>>> Should be pretty easy to do! >>>>>>>> >>>>>>>> Regards >>>>>>>> Michael Knill >>>>>>>> >>>>>>>> From: Michael Keuter <li...@mk...> >>>>>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>>>>> >>>>>>>> Quite interesting thread about apiban: >>>>>>>> >>>>>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>>>>> >>>>>>>> Sent from a mobile device. >>>>>>>> >>>>>>>> Michael Keuter >>>>>>>> >>>>>>>> >>>>>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>>>>> >>>>>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>>>>> >>>>>>>>> https://apiban.org/doc.html >>>>>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Michael Knill >>>>>>>>> Managing Director >>>>>>>>> >>>>>>>>> D: +61 2 6189 1360 >>>>>>>>> P: +61 2 6140 4656 >>>>>>>>> E: mic...@ip... >>>>>>>>> W: ipcsolutions.com.au >>>>>>>>> >>>>>>>>> >>>>>>>>> <image001.png> >>>>>>>>> Smarter Business Communications >>>>>>>>> > > > Michael > > http://www.mksolutions.info Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2021-10-15 14:33:17
|
> Am 15.10.2021 um 16:20 schrieb Lonnie Abelbeck <li...@lo...>: > > OK, but if your concern is that "this is not for everyone IMHO" if it were under 'asterisk' apiban-netset would only be called if /mnt/kd/apiban.conf exists (without the key apiban doesn't work). > > The difference would be: > > 'asterisk.netset' -> blocklist_de_sip.ipset + apiban-netset (if apiban.conf exists) > > or > > 'asterisk.netset' -> blocklist_de_sip.ipset > > 'apiban.netset' -> apiban-netset (error if apiban.conf does not exists) > > > I'm thinking keeping it under 'asterisk' is the least work for users. But I have no firm opinion either way. My main reason is the possibility to update it separate from the other netsets more often. "reload-blocklist-netset /mnt/kd/blocklists apiban" The user has to configure a cronjob anyway, so it's not more work to add "apiban" to that line (if they even know about it) :-). > Lonnie > > > >> On Oct 15, 2021, at 9:01 AM, Michael Keuter <li...@mk...> wrote: >> >> I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. >> On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. >> >> ---- >> ## update blocklists >> 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 >> ## Test apiban >> 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload >> ---- >> >>> Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> Thanks Michael for testing. >>> >>> Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. >>> >>> If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? >>> >>> Lonnie >>> >>> >>>> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >>>> >>>> Hi Lonnie, >>>> >>>> thanks for your work! >>>> The script works fine and the blocked addresses seem to be very precise. >>>> >>>> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >>>> >>>>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>>>> >>>>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>>>> >>>>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>>>> >>>>> Remove the trailing .php and make apiban-netset executable. >>>>> >>>>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>>>> >>>>> We can decide if we want this in production AstLinux. >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>> >>>>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>>>> >>>>>> Michael, thanks for bringing APIBAN to our attention. >>>>>> >>>>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>>>> >>>>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>>>> >>>>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>>>> >>>>>> Possibly there are other sip/asterisk related blocklists? >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>>>> >>>>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>>>> Should be pretty easy to do! >>>>>>> >>>>>>> Regards >>>>>>> Michael Knill >>>>>>> >>>>>>> From: Michael Keuter <li...@mk...> >>>>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>>>> >>>>>>> Quite interesting thread about apiban: >>>>>>> >>>>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>>>> >>>>>>> Sent from a mobile device. >>>>>>> >>>>>>> Michael Keuter >>>>>>> >>>>>>> >>>>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>>>> >>>>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>>>> >>>>>>>> https://apiban.org/doc.html >>>>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Michael Knill >>>>>>>> Managing Director >>>>>>>> >>>>>>>> D: +61 2 6189 1360 >>>>>>>> P: +61 2 6140 4656 >>>>>>>> E: mic...@ip... >>>>>>>> W: ipcsolutions.com.au >>>>>>>> >>>>>>>> >>>>>>>> <image001.png> >>>>>>>> Smarter Business Communications >>>>>>>> Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2021-10-15 14:21:04
|
OK, but if your concern is that "this is not for everyone IMHO" if it were under 'asterisk' apiban-netset would only be called if /mnt/kd/apiban.conf exists (without the key apiban doesn't work). The difference would be: 'asterisk.netset' -> blocklist_de_sip.ipset + apiban-netset (if apiban.conf exists) or 'asterisk.netset' -> blocklist_de_sip.ipset 'apiban.netset' -> apiban-netset (error if apiban.conf does not exists) I'm thinking keeping it under 'asterisk' is the least work for users. But I have no firm opinion either way. Lonnie > On Oct 15, 2021, at 9:01 AM, Michael Keuter <li...@mk...> wrote: > > I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. > On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. > > ---- > ## update blocklists > 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 > ## Test apiban > 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload > ---- > >> Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: >> >> Thanks Michael for testing. >> >> Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. >> >> If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? >> >> Lonnie >> >> >>> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >>> >>> Hi Lonnie, >>> >>> thanks for your work! >>> The script works fine and the blocked addresses seem to be very precise. >>> >>> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >>> >>>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>>> >>>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>>> >>>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>>> >>>> Remove the trailing .php and make apiban-netset executable. >>>> >>>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>>> >>>> We can decide if we want this in production AstLinux. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> >>>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>>> >>>>> Michael, thanks for bringing APIBAN to our attention. >>>>> >>>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>>> >>>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>>> >>>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>>> >>>>> Possibly there are other sip/asterisk related blocklists? >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>>> Should be pretty easy to do! >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> From: Michael Keuter <li...@mk...> >>>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>>> >>>>>> Quite interesting thread about apiban: >>>>>> >>>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>>> >>>>>> Sent from a mobile device. >>>>>> >>>>>> Michael Keuter >>>>>> >>>>>> >>>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>>> >>>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>>> >>>>>>> https://apiban.org/doc.html >>>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Michael Knill >>>>>>> Managing Director >>>>>>> >>>>>>> D: +61 2 6189 1360 >>>>>>> P: +61 2 6140 4656 >>>>>>> E: mic...@ip... >>>>>>> W: ipcsolutions.com.au >>>>>>> >>>>>>> >>>>>>> <image001.png> >>>>>>> Smarter Business Communications >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Astlinux-devel mailing list >>>>>>> Ast...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>>>> _______________________________________________ >>>>>> Astlinux-devel mailing list >>>>>> Ast...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Astlinux-devel mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >>> Michael >>> >>> http://www.mksolutions.info >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Michael K. <li...@mk...> - 2021-10-15 14:01:39
|
I would prefer to keep it separated as "apiban.netset" (and an additional "apiban" parameter for "reload-blocklist-netset"), cause this is not for everyone IMHO. On those systems where I want it, I will update it more often (let's say hourly) compared to the 2 times per day update of the other netsets. E.g. ---- ## update blocklists 45 03,15 * * * reload-blocklist-netset /mnt/kd/blocklists firehol_level1 firehol_webclient asterisk custom >/dev/null 2>&1 ## Test apiban 07 * * * * /mnt/kd/bin/apiban-netset > /mnt/kd/blocklists/apiban.netset; arno-iptables-firewall force-reload ---- > Am 15.10.2021 um 15:09 schrieb Lonnie Abelbeck <li...@lo...>: > > Thanks Michael for testing. > > Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. > > If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? > > Lonnie > > >> On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: >> >> Hi Lonnie, >> >> thanks for your work! >> The script works fine and the blocked addresses seem to be very precise. >> >> I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. >> >>> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >>> >>> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >>> >>> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >>> >>> Remove the trailing .php and make apiban-netset executable. >>> >>> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >>> >>> We can decide if we want this in production AstLinux. >>> >>> Lonnie >>> >>> >>> >>> >>>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>>> >>>> Michael, thanks for bringing APIBAN to our attention. >>>> >>>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>>> >>>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>>> >>>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>>> >>>> Possibly there are other sip/asterisk related blocklists? >>>> >>>> Lonnie >>>> >>>> >>>> >>>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>>> Should be pretty easy to do! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> From: Michael Keuter <li...@mk...> >>>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>>> Date: Thursday, 14 October 2021 at 9:41 am >>>>> To: AstLinux Developers Mailing List <ast...@li...> >>>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>>> >>>>> Quite interesting thread about apiban: >>>>> >>>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>>> >>>>> Sent from a mobile device. >>>>> >>>>> Michael Keuter >>>>> >>>>> >>>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>>> >>>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>>> >>>>>> https://apiban.org/doc.html >>>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>>> >>>>>> Regards >>>>>> >>>>>> Michael Knill >>>>>> Managing Director >>>>>> >>>>>> D: +61 2 6189 1360 >>>>>> P: +61 2 6140 4656 >>>>>> E: mic...@ip... >>>>>> W: ipcsolutions.com.au >>>>>> >>>>>> >>>>>> <image001.png> >>>>>> Smarter Business Communications >>>>>> >>>>>> _______________________________________________ >>>>>> Astlinux-devel mailing list >>>>>> Ast...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>>> _______________________________________________ >>>>> Astlinux-devel mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> Michael >> >> http://www.mksolutions.info >> >> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel Michael http://www.mksolutions.info |
|
From: Lonnie A. <li...@lo...> - 2021-10-15 13:09:15
|
Thanks Michael for testing. Yes, the 'apiban' IPs seem high quality, seemingly aged after 7 days or so, and regularly updated. If we were to incorporate apiban-netset into the reload-blocklist-netset script, should it be a new 'apiban' type or include it as part of the existing 'asterisk' type? Lonnie > On Oct 15, 2021, at 4:49 AM, Michael Keuter <li...@mk...> wrote: > > Hi Lonnie, > > thanks for your work! > The script works fine and the blocked addresses seem to be very precise. > > I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. > >> Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: >> >> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. >> >> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 >> >> Remove the trailing .php and make apiban-netset executable. >> >> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. >> >> We can decide if we want this in production AstLinux. >> >> Lonnie >> >> >> >> >>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >>> >>> Michael, thanks for bringing APIBAN to our attention. >>> >>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >>> >>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >>> >>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >>> >>> Possibly there are other sip/asterisk related blocklists? >>> >>> Lonnie >>> >>> >>> >>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>>> Should be pretty easy to do! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> From: Michael Keuter <li...@mk...> >>>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>>> Date: Thursday, 14 October 2021 at 9:41 am >>>> To: AstLinux Developers Mailing List <ast...@li...> >>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>>> >>>> Quite interesting thread about apiban: >>>> >>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>>> >>>> Sent from a mobile device. >>>> >>>> Michael Keuter >>>> >>>> >>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>>> >>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>>> I assume that banned IP addresses could just be pulled into a netset list? >>>>> >>>>> https://apiban.org/doc.html >>>>> https://www.securevoip.io/48-hours-with-apiban/ >>>>> >>>>> Regards >>>>> >>>>> Michael Knill >>>>> Managing Director >>>>> >>>>> D: +61 2 6189 1360 >>>>> P: +61 2 6140 4656 >>>>> E: mic...@ip... >>>>> W: ipcsolutions.com.au >>>>> >>>>> >>>>> <image001.png> >>>>> Smarter Business Communications >>>>> >>>>> _______________________________________________ >>>>> Astlinux-devel mailing list >>>>> Ast...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> >>> >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Michael K. <li...@mk...> - 2021-10-15 09:49:25
|
Hi Lonnie, thanks for your work! The script works fine and the blocked addresses seem to be very precise. I verified a few of the addresses, that I saw in sngrep, and all addresses were already included in the apiban.netset. > Am 15.10.2021 um 00:26 schrieb Lonnie Abelbeck <li...@lo...>: > > I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. > > https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 > > Remove the trailing .php and make apiban-netset executable. > > You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. > > We can decide if we want this in production AstLinux. > > Lonnie > > > > >> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >> >> Michael, thanks for bringing APIBAN to our attention. >> >> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >> >> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >> >> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >> >> Possibly there are other sip/asterisk related blocklists? >> >> Lonnie >> >> >> >>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>> Should be pretty easy to do! >>> >>> Regards >>> Michael Knill >>> >>> From: Michael Keuter <li...@mk...> >>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>> Date: Thursday, 14 October 2021 at 9:41 am >>> To: AstLinux Developers Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>> >>> Quite interesting thread about apiban: >>> >>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>> >>> Sent from a mobile device. >>> >>> Michael Keuter >>> >>> >>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>> >>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>> I assume that banned IP addresses could just be pulled into a netset list? >>>> >>>> https://apiban.org/doc.html >>>> https://www.securevoip.io/48-hours-with-apiban/ >>>> >>>> Regards >>>> >>>> Michael Knill >>>> Managing Director >>>> >>>> D: +61 2 6189 1360 >>>> P: +61 2 6140 4656 >>>> E: mic...@ip... >>>> W: ipcsolutions.com.au >>>> >>>> >>>> <image001.png> >>>> Smarter Business Communications >>>> >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2021-10-15 00:58:34
|
Thanks for the heads up. We would be putting it into that release so all good.
Regards
Michael Knill
On 15/10/21, 11:57 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Hey Michael,
BTW, The PHP script uses the curl module, which was first added into AstLinux 1.4.3 (I thought it was earlier) ... so keep that in mind when testing.
Lonnie
> On Oct 14, 2021, at 7:52 PM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie. Will give it a try.
>
> Regards
> Michael Knill
>
> On 15/10/21, 9:27 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout.
>
> https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4
>
> Remove the trailing .php and make apiban-netset executable.
>
> You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'.
>
> We can decide if we want this in production AstLinux.
>
> Lonnie
>
>
>
>
>> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>
>> Michael, thanks for bringing APIBAN to our attention.
>>
>> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated.
>>
>> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem.
>>
>> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle.
>>
>> Possibly there are other sip/asterisk related blocklists?
>>
>> Lonnie
>>
>>
>>
>>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote:
>>>
>>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux.
>>> Should be pretty easy to do!
>>>
>>> Regards
>>> Michael Knill
>>>
>>> From: Michael Keuter <li...@mk...>
>>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>>> Date: Thursday, 14 October 2021 at 9:41 am
>>> To: AstLinux Developers Mailing List <ast...@li...>
>>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux
>>>
>>> Quite interesting thread about apiban:
>>>
>>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11
>>>
>>> Sent from a mobile device.
>>>
>>> Michael Keuter
>>>
>>>
>>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>:
>>>>
>>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
>>>> I assume that banned IP addresses could just be pulled into a netset list?
>>>>
>>>> https://apiban.org/doc.html
>>>> https://www.securevoip.io/48-hours-with-apiban/
>>>>
>>>> Regards
>>>>
>>>> Michael Knill
>>>> Managing Director
>>>>
>>>> D: +61 2 6189 1360
>>>> P: +61 2 6140 4656
>>>> E: mic...@ip...
>>>> W: ipcsolutions.com.au
>>>>
>>>>
>>>> <image001.png>
>>>> Smarter Business Communications
>>>>
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>
>>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2021-10-15 00:57:08
|
Hey Michael, BTW, The PHP script uses the curl module, which was first added into AstLinux 1.4.3 (I thought it was earlier) ... so keep that in mind when testing. Lonnie > On Oct 14, 2021, at 7:52 PM, Michael Knill <mic...@ip...> wrote: > > Thanks Lonnie. Will give it a try. > > Regards > Michael Knill > > On 15/10/21, 9:27 am, "Lonnie Abelbeck" <li...@lo...> wrote: > > I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. > > https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 > > Remove the trailing .php and make apiban-netset executable. > > You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. > > We can decide if we want this in production AstLinux. > > Lonnie > > > > >> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: >> >> Michael, thanks for bringing APIBAN to our attention. >> >> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. >> >> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. >> >> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. >> >> Possibly there are other sip/asterisk related blocklists? >> >> Lonnie >> >> >> >>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >>> >>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >>> Should be pretty easy to do! >>> >>> Regards >>> Michael Knill >>> >>> From: Michael Keuter <li...@mk...> >>> Reply to: AstLinux Developers Mailing List <ast...@li...> >>> Date: Thursday, 14 October 2021 at 9:41 am >>> To: AstLinux Developers Mailing List <ast...@li...> >>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >>> >>> Quite interesting thread about apiban: >>> >>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >>> >>> Sent from a mobile device. >>> >>> Michael Keuter >>> >>> >>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>>> >>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>>> I assume that banned IP addresses could just be pulled into a netset list? >>>> >>>> https://apiban.org/doc.html >>>> https://www.securevoip.io/48-hours-with-apiban/ >>>> >>>> Regards >>>> >>>> Michael Knill >>>> Managing Director >>>> >>>> D: +61 2 6189 1360 >>>> P: +61 2 6140 4656 >>>> E: mic...@ip... >>>> W: ipcsolutions.com.au >>>> >>>> >>>> <image001.png> >>>> Smarter Business Communications >>>> >>>> _______________________________________________ >>>> Astlinux-devel mailing list >>>> Ast...@li... >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> >> > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <mic...@ip...> - 2021-10-15 00:52:56
|
Thanks Lonnie. Will give it a try.
Regards
Michael Knill
On 15/10/21, 9:27 am, "Lonnie Abelbeck" <li...@lo...> wrote:
I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout.
https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4
Remove the trailing .php and make apiban-netset executable.
You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'.
We can decide if we want this in production AstLinux.
Lonnie
> On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
> Michael, thanks for bringing APIBAN to our attention.
>
> I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated.
>
> The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem.
>
> So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle.
>
> Possibly there are other sip/asterisk related blocklists?
>
> Lonnie
>
>
>
>> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote:
>>
>> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux.
>> Should be pretty easy to do!
>>
>> Regards
>> Michael Knill
>>
>> From: Michael Keuter <li...@mk...>
>> Reply to: AstLinux Developers Mailing List <ast...@li...>
>> Date: Thursday, 14 October 2021 at 9:41 am
>> To: AstLinux Developers Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux
>>
>> Quite interesting thread about apiban:
>>
>> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11
>>
>> Sent from a mobile device.
>>
>> Michael Keuter
>>
>>
>>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>:
>>>
>>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
>>> I assume that banned IP addresses could just be pulled into a netset list?
>>>
>>> https://apiban.org/doc.html
>>> https://www.securevoip.io/48-hours-with-apiban/
>>>
>>> Regards
>>>
>>> Michael Knill
>>> Managing Director
>>>
>>> D: +61 2 6189 1360
>>> P: +61 2 6140 4656
>>> E: mic...@ip...
>>> W: ipcsolutions.com.au
>>>
>>>
>>> <image001.png>
>>> Smarter Business Communications
>>>
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2021-10-15 00:17:38
|
Yes we actually modified the Firewall Tab so it automatically creates the rules in the whitelist when you restarted the firewall!
May use it one day!
Regards
Michael Knill
On 14/10/21, 10:07 am, "Lonnie Abelbeck" <li...@lo...> wrote:
I define a "/mnt/kd/blocklists/whitelist.netset" for anything important, so a bad IP (intentional or not) in a .netset does not effect production operation.
Lonnie
> On Oct 13, 2021, at 5:58 PM, Michael Knill <mic...@ip...> wrote:
>
> Security maybe. Prevent the list from being poisoned?
> Its one of the bigger concerns I have with netset and why I have not implemented it yet.
>
> Regards
> Michael Knill
>
> On 14/10/21, 9:46 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Interesting, why an API (key) rather than a .netset file updated twice a day or so?
>
> Their database could be easily incorporated into AstLinux if it were a downloadable .netset file.
>
> Possibly they are looking at charging to use it, hence the API key?
>
> Possibly I'm missing something.
>
> Thanks for sharing Michael.
>
> Lonnie
>
>
>> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote:
>>
>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
>> I assume that banned IP addresses could just be pulled into a netset list?
>>
>> https://apiban.org/doc.html
>> https://www.securevoip.io/48-hours-with-apiban/
>>
>> Regards
>>
>> Michael Knill
>> Managing Director
>>
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>
>> <image001.png>
>> Smarter Business Communications
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2021-10-15 00:16:02
|
Hi Michael
Yes we were going to use it for incoming geoblocking but the lists were just not accurate enough for Australia. The main reason was because we needed to open up access for our mobile softphone so I was concerned but it hasn't been a problem so far.
Regards
Michael Knill
On 14/10/21, 10:04 am, "Michael Keuter" <li...@mk...> wrote:
Michael,
there is also a „whitelist.netset“ where you can whitelist over all netsets.
I use the netsets on all my customers (mostly for outbound blocking) together with a whitelist of common addresses and had no issues so far. Though I have SIP only allowed for their VoIP providers.
Sent from a mobile device.
Michael Keuter
> Am 14.10.2021 um 00:58 schrieb Michael Knill <mic...@ip...>:
>
> Security maybe. Prevent the list from being poisoned?
> Its one of the bigger concerns I have with netset and why I have not implemented it yet.
>
> Regards
> Michael Knill
>
> On 14/10/21, 9:46 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Interesting, why an API (key) rather than a .netset file updated twice a day or so?
>
> Their database could be easily incorporated into AstLinux if it were a downloadable .netset file.
>
> Possibly they are looking at charging to use it, hence the API key?
>
> Possibly I'm missing something.
>
> Thanks for sharing Michael.
>
> Lonnie
>
>
>> On Oct 13, 2021, at 4:23 PM, Michael Knill <mic...@ip...> wrote:
>>
>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well.
>> I assume that banned IP addresses could just be pulled into a netset list?
>>
>> https://apiban.org/doc.html
>> https://www.securevoip.io/48-hours-with-apiban/
>>
>> Regards
>>
>> Michael Knill
>> Managing Director
>>
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>
>> <image001.png>
>> Smarter Business Communications
>>
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2021-10-14 22:26:56
|
I wrote a PHP script that retrieves all the APIBAN 'banned' IPs and runs them through iprange to generate a .netset file as stdout. https://gist.github.com/abelbeck/28bdea0d45be8bfcbf65bb34e57fd4d4 Remove the trailing .php and make apiban-netset executable. You must have an APIBAN Key, and place it by itself (no leading/trailing text) in '/mnt/kd/apiban.conf'. We can decide if we want this in production AstLinux. Lonnie > On Oct 14, 2021, at 9:27 AM, Lonnie Abelbeck <li...@lo...> wrote: > > Michael, thanks for bringing APIBAN to our attention. > > I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. > > The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. > > So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. > > Possibly there are other sip/asterisk related blocklists? > > Lonnie > > > >> On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: >> >> Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. >> Should be pretty easy to do! >> >> Regards >> Michael Knill >> >> From: Michael Keuter <li...@mk...> >> Reply to: AstLinux Developers Mailing List <ast...@li...> >> Date: Thursday, 14 October 2021 at 9:41 am >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux >> >> Quite interesting thread about apiban: >> >> https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 >> >> Sent from a mobile device. >> >> Michael Keuter >> >> >>> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >>> >>> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >>> I assume that banned IP addresses could just be pulled into a netset list? >>> >>> https://apiban.org/doc.html >>> https://www.securevoip.io/48-hours-with-apiban/ >>> >>> Regards >>> >>> Michael Knill >>> Managing Director >>> >>> D: +61 2 6189 1360 >>> P: +61 2 6140 4656 >>> E: mic...@ip... >>> W: ipcsolutions.com.au >>> >>> >>> <image001.png> >>> Smarter Business Communications >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
|
From: Lonnie A. <li...@lo...> - 2021-10-14 14:27:40
|
Michael, thanks for bringing APIBAN to our attention. I re-looked at our /usr/sbin/reload-blocklist-netset script and the 'asterisk' URLs, turns out only "blocklist_de_sip.ipset" is actively updated. The 'voipbl' URL has only grown over time, no IPs have been removed, which makes false positives a problem. So, the APIBAN list may have a place, but requiring an access key and not a straight .ipset/.netset file download is a hurdle. Possibly there are other sip/asterisk related blocklists? Lonnie > On Oct 13, 2021, at 5:55 PM, Michael Knill <mic...@ip...> wrote: > > Yep it needs to go into a netset list aggregated with iprange. Note their client does actually work on Astlinux. > Should be pretty easy to do! > > Regards > Michael Knill > > From: Michael Keuter <li...@mk...> > Reply to: AstLinux Developers Mailing List <ast...@li...> > Date: Thursday, 14 October 2021 at 9:41 am > To: AstLinux Developers Mailing List <ast...@li...> > Subject: Re: [Astlinux-devel] Using APIBAN in Astlinux > > Quite interesting thread about apiban: > > https://community.freepbx.org/t/integrating-apiban-org-with-freepbx/69422/11 > > Sent from a mobile device. > > Michael Keuter > > >> Am 13.10.2021 um 23:24 schrieb Michael Knill <mic...@ip...>: >> >> APIBAN looks very interesting. There will be a session on it at Astricon this year as well. >> I assume that banned IP addresses could just be pulled into a netset list? >> >> https://apiban.org/doc.html >> https://www.securevoip.io/48-hours-with-apiban/ >> >> Regards >> >> Michael Knill >> Managing Director >> >> D: +61 2 6189 1360 >> P: +61 2 6140 4656 >> E: mic...@ip... >> W: ipcsolutions.com.au >> >> >> <image001.png> >> Smarter Business Communications >> >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |