• Alternative(s) to ipset on OpenVZ

    From Joaquim Homrighausen@2:20/4609 to IPTABLES phreaks :) on Wed Dec 6 16:41:08 2017
    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)
  • From Alexey Vissarionov@2:5020/545 to Joaquim Homrighausen on Wed Dec 6 23:02:00 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Alexey Vissarionov on Sun Dec 10 19:11:10 2017
    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)
  • From Nelgin@endofthelinebbs.com to Joaquim Homrighausen on Mon Dec 11 22:42:27 2017
    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.
  • From Stephen Walsh@3:633/280 to Joaquim Homrighausen on Tue Dec 12 13:01:57 2017
    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)
  • From Alexey Vissarionov@2:5020/545 to Stephen Walsh on Tue Dec 12 09:50:50 2017
    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)
  • From Alexey Vissarionov@2:5020/545 to Nelgin on Tue Dec 12 09:55:50 2017
    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)
  • From Benny Pedersen@2:230/0 to Nelgin on Thu Dec 14 17:42:38 2017
    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)
  • From Benny Pedersen@2:230/0 to Stephen Walsh on Thu Dec 14 17:45:02 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Nelgin on Mon Dec 18 21:32:10 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Stephen Walsh on Mon Dec 18 21:36:26 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Alexey Vissarionov on Mon Dec 18 21:37:46 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Alexey Vissarionov on Mon Dec 18 21:40:18 2017
    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)
  • From Alexey Vissarionov@2:5020/545 to Joaquim Homrighausen on Tue Dec 19 07:00:00 2017
    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)
  • From Joaquim Homrighausen@2:20/4609 to Alexey Vissarionov on Tue Dec 19 13:39:16 2017
    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)
  • From Nelgin@endofthelinebbs.com to Alexey Vissarionov on Wed Dec 20 19:30:49 2017
    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.
  • From Alexey Vissarionov@2:5020/545 to Nelgin on Thu Dec 21 07:26:00 2017
    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)
  • From Nelgin@endofthelinebbs.com to Alexey Vissarionov on Thu Dec 21 18:49:32 2017
    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.
  • From Static@1:249/400 to Alexey Vissarionov on Thu Dec 21 22:08:46 2017
    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)
  • From Static@1:249/400 to Nelgin on Thu Dec 21 22:10:22 2017
    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)