Does anyone know of an alternative to ipset for blocking IP ranges of entire countries, that works with OpenVZ containers?




-joho

---
* Origin: code.code.code (2:20/4609)

Good ${greeting_time}, Joaquim!

06 Dec 2017 16:41:08, you wrote to IPTABLES phreaks :):

Does anyone know of an alternative to ipset for blocking IP
ranges of entire countries, that works with OpenVZ containers?

If you want to do exactly that, simply use CIDR notation with -s parameter.

However, if you need (just a guess) to protect SSH against bruteforcing the passwords, that's normally performed a bit differently.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Does anyone know of an alternative to ipset for blocking IP
ranges of entire countries, that works with OpenVZ containers?

If you want to do exactly that, simply use CIDR notation with -s parameter.

Using IPTABLES ... or did you mean with ipset? I can't use ipset in this specific case, and listing thousands of nets using IPTABLES is usually a bad idea.

However, if you need (just a guess) to protect SSH against
bruteforcing the passwords, that's normally performed a bit
differently.

I prefer using F2B, it works quite well if you up blocking time to something like 24-48 hours.



-joho

---
* Origin: code.code.code (2:20/4609)

On Wed, 6 Dec 2017 16:41:08 +0200, "Joaquim Homrighausen" <joaquim.homrighausen@2:20/4609> wrote:

Does anyone know of an alternative to ipset for blocking IP ranges of entire >countries, that works with OpenVZ containers?

I wish...

I use fail2ban. OpenVZ containers have limited memory and you can soon
fill it up with an all the subnets. With fail2ban you can block the
offenders easily. I have a "permaban" chain for those repeat
offenders.
--- SBBSecho 3.03-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)

Hello Joaquim!

10 Dec 17 19:11, you wrote to Alexey Vissarionov:

If you want to do exactly that, simply use CIDR notation with -s
parameter.

Using IPTABLES ... or did you mean with ipset? I can't use ipset in
this specific case, and listing thousands of nets using IPTABLES is usually a bad idea.

Will this work?


https://github.com/tlhackque/BlockCountries


Stephen


--- GoldED+/LNX 1.1.5-b20161221
* Origin: Dragon's Lair ---:- dragon.vk3heg.net -:--- (3:633/280)

Good ${greeting_time}, Stephen!

12 Dec 2017 09:00:00, you wrote to Joaquim Homrighausen:

If you want to do exactly that, simply use CIDR notation with -s
parameter.

Using IPTABLES ... or did you mean with ipset? I can't use ipset in
this specific case, and listing thousands of nets using IPTABLES is
usually a bad idea.

Will this work?
https://github.com/tlhackque/BlockCountries

This never works, as there would always be at least one trojaned computer in your own country...

Limiting the number of connections per minute does that (SSH protection) best. Especially being combined with key-only authentification (if you choose proper algorithms, of course).


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... that's why I really dislike fools.
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Good ${greeting_time}, Nelgin!

11 Dec 2017 22:42:26, you wrote to Joaquim Homrighausen:

Does anyone know of an alternative to ipset for blocking IP ranges
of entire countries, that works with OpenVZ containers?

I wish... I use fail2ban.

Very dangerous thing... However, it makes some fun to use it against the admin^Widiot who installed it :-)

OpenVZ containers have limited memory

Netfilter rules are count as separate resourses. Look at the source or in BC.

and you can soon fill it up with an all the subnets. With fail2ban
you can block the offenders easily. I have a "permaban" chain for
those repeat offenders.

Being a security expert, I know (and use; and, obviously, recommend) better method: limit the number of connections per minute to 2 or 3, thus making any and all bruteforce attacks time-ineffective.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... that's why I really dislike fools.
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Hello Nelgin!

11 Dec 2017 22:42, Nelgin wrote to Joaquim Homrighausen:

I wish...

if you have static ip at home for fidonet, then use that static ip to allow ssh
from only, then you solved it with basicly whitelist not blacklist world of kids :)

I use fail2ban. OpenVZ containers have limited memory and you can soon
fill it up with an all the subnets. With fail2ban you can block the offenders easily. I have a "permaban" chain for those repeat
offenders.

fail2ban missing ipv6


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.14.4-gentoo (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Stephen!

12 Dec 2017 13:01, Stephen Walsh wrote to Joaquim Homrighausen:

https://github.com/tlhackque/BlockCountries

if there is low memory no


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.2.0 (Linux/4.14.4-gentoo (i686))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Does anyone know of an alternative to ipset for blocking IP ranges
of entire countries, that works with OpenVZ containers?

I wish...

I use fail2ban. OpenVZ containers have limited memory and you can
soon fill it up with an all the subnets. With fail2ban you can block
the offenders easily. I have a "permaban" chain for those repeat
offenders.

Well, you can have some nicely sized containers if you want, but putting 500 000 drops (or rejects if you like them better) in an IPTABLE chain is perhaps not a wise thing for anyone, thus the need for ipset.

Permaban is a good idea, until an IP range is re-assigned to someone else of course :), but then again, I think it's better to err on the inclusive side in this case.

It annoys me that ISPs don't have this as a service, and I'm quite surprised they don't actually. I can understand the fact that they don't want to subscribe to something like Cyren or similar, but they could quite easily do it
on their own.


-joho

---
* Origin: code.code.code (2:20/4609)

If you want to do exactly that, simply use CIDR notation with -s
parameter.

Using IPTABLES ... or did you mean with ipset? I can't use ipset in
this specific case, and listing thousands of nets using IPTABLES is
usually a bad idea.

Will this work?
https://github.com/tlhackque/BlockCountries

For my purposes it might. I hadn't seen this one. Thanks!


-joho

---
* Origin: code.code.code (2:20/4609)

This never works, as there would always be at least one trojaned
computer in your own country...

It may not be a complete solution, but it might help.

Limiting the number of connections per minute does that (SSH
protection) best. Especially being combined with key-only
authentification (if you choose proper algorithms, of course).

fail2ban (and similar) does a pretty good job of keeping muppets at bay, as does rate limiting, indeed.


-joho

---
* Origin: code.code.code (2:20/4609)

Very dangerous thing... However, it makes some fun to use it
against the admin^Widiot who installed it :-)

I'm curious ... why is fail2ban dangerous?

Being a security expert, I know (and use; and, obviously,
recommend) better method: limit the number of connections per
minute to 2 or 3, thus making any and all bruteforce attacks time-ineffective.

I don't see why these are mutually exclusive ... but maybe I'm not an expert enough. If you use key-only authentication for SSH (for example), it makes perfect sense to add someone to a ban list for 15-600 minutes if they fail 3 times (for example).

I quite often legitimately connect with 2-3-4 SSH sessions to the same server within a few minutes, but they don't fail of course :)



-joho

---
* Origin: code.code.code (2:20/4609)

Good ${greeting_time}, Joaquim!

18 Dec 2017 21:40:18, you wrote to me:

Very dangerous thing... However, it makes some fun to
use it against the admin^Widiot who installed it :-)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm curious ... why is fail2ban dangerous?

Didn't you read the message before answering it?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

Being a security expert, I know (and use; and, obviously,
recommend) better method: limit the number of connections per
minute to 2 or 3, thus making any and all bruteforce attacks
time-ineffective.

I don't see why these are mutually exclusive ... but maybe I'm
not an expert enough. If you use key-only authentication for SSH

Don't you?

(for example), it makes perfect sense to add someone to a ban
list for 15-600 minutes if they fail 3 times (for example).

Now imagine someone had tricked your funny stupid fail2ban to ban _you_...

I quite often legitimately connect with 2-3-4 SSH sessions to the
same server within a few minutes, but they don't fail of course :)

I guess you simply don't know about screen.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... :wq!
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Didn't you read the message before answering it?

Of course I did.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

Thanks for pointing that out.

I don't see why these are mutually exclusive ... but maybe I'm
not an expert enough. If you use key-only authentication for SSH

Don't you?

That's what I said.

(for example), it makes perfect sense to add someone to a ban
list for 15-600 minutes if they fail 3 times (for example).

Now imagine someone had tricked your funny stupid fail2ban to ban
_you_...

Yes, imagine that.

I quite often legitimately connect with 2-3-4 SSH sessions to the
same server within a few minutes, but they don't fail of course :)

I guess you simply don't know about screen.

Oh but I do. I don't know what in my above text led you to that conclusion.



-joho

---
* Origin: code.code.code (2:20/4609)

On Tue, 19 Dec 2017 07:00:00 +0300, "Alexey Vissarionov" <alexey.vissarionov@2:5020/545> wrote:

Good ${greeting_time}, Joaquim!

18 Dec 2017 21:40:18, you wrote to me:

Very dangerous thing... However, it makes some fun to
use it against the admin^Widiot who installed it :-)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm curious ... why is fail2ban dangerous?

Didn't you read the message before answering it?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

Is it an accident that you omitted to say that there were only 3 CVE announcements since CVE-2012-5642 and those were over 4 years ago or
are you just scaremongering?


The only options you offer are to block CIDR (which can be done
manully after fail2ban picks up some common CIDRS worth blocking) and
rate limiting which fail2ban does by way of blocking anyway.
--- SBBSecho 3.03-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)

Good ${greeting_time}, Nelgin!

20 Dec 2017 19:30:48, you wrote to me:

Very dangerous thing... However, it makes some fun to
use it against the admin^Widiot who installed it :-)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm curious ... why is fail2ban dangerous?

Didn't you read the message before answering it?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is it an accident that you omitted to say that there were only 3 CVE announcements since CVE-2012-5642 and those were over 4 years ago or
are you just scaremongering?

P.S.: OMFG... I was about to answer to PoS without a realname...

--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-cmlxxvii-mmxlviii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

On Thu, 21 Dec 2017 07:26:00 +0300, "Alexey Vissarionov" <alexey.vissarionov@2:5020/545> wrote:

Good ${greeting_time}, Nelgin!

20 Dec 2017 19:30:48, you wrote to me:

Very dangerous thing... However, it makes some fun to
use it against the admin^Widiot who installed it :-)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm curious ... why is fail2ban dangerous?

Didn't you read the message before answering it?

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is it an accident that you omitted to say that there were only 3 CVE announcements since CVE-2012-5642 and those were over 4 years ago or
are you just scaremongering?

P.S.: OMFG... I was about to answer to PoS without a realname...

PoS yourself, mate.
--- SBBSecho 3.03-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)

On 12/19/17, Alexey Vissarionov said the following...

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642
and some others discovered since that.

There's a total of three CVE entries since 2012, two of which are the same issue in two different conf files, and all the CVEs dating back to 2006 are good examples of why you must always sanitize user input.

You'll never succeed in getting an admin banned from their own server no
matter how bad their regex skills are when they've whitelisted themselves, though.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (1:249/400)

On 12/21/17, Nelgin said the following...

P.S.: OMFG... I was about to answer to PoS without a realname...

PoS yourself, mate.

Saw that, thought I had the echo misconfigured somehow and checked the
elist... but sure enough: RESTrictions: {None on record}

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (1:249/400)