• Rejecting an incoming connection

    From Paul Hayton@3:770/100 to All on Thu May 20 19:59:44 2021
    Hi guys

    As some of you may know I run an othernet in Zone 21 and have a /999 test AKA that nodes who which to test their polling setup to my HUB can use when first setting up and before they apply and get their own node number.

    The problem I have at present is that someone has set up their BBS and is polling the HUB every 2 minutes using the test AKA. This is way too frequent, has been going on for weeks, and despite a netmail to that test system asking for the sysop to contact me to arrange their own node number, there's been no reply and no let up in polling frequency.

    I'm looking for a way for BinkD to reject the incoming connection based on something like SYS or ZYZ info presented. Is such a thing possible using a
    perl script or similar?

    Note I am not a perl guru so any suggested fix you have I'd appreciate a bit
    of hand holding to implement it.

    Also of note, setting such a block up is not my preferred choice but I have exhausted options to contact the unknown sysop and want to ensure the test
    AKA is available for others to send/recieve packets from also... with a polling frequency of 2 mins the offending system gives no one else a look in.

    Thanks for your thoughts / guidance.

    Best, Paul

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Quinn@3:640/1384 to Paul Hayton on Thu May 20 18:22:20 2021
    Hi! Paul,

    On 20 May 2021, Paul Hayton said the following...

    I'm looking for a way for BinkD to reject the incoming connection based
    on something like SYS or ZYZ info presented. Is such a thing possible using a perl script or similar?

    I see in the binkD FAQ that there is a way to block a known IP. Check out
    the distro .CFG file. Good luck.

    Cheers,
    Paul.

    --- Mystic BBS v1.12 A46 2020/08/26 (Linux/32)
    * Origin: Quinn's Rock - stuck in a Linux VM, again! (3:640/1384)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Thu May 20 10:29:19 2021
    Hi Paul,

    On 2021-05-20 19:59:44, you wrote to All:

    As some of you may know I run an othernet in Zone 21 and have a /999
    test AKA that nodes who which to test their polling setup to my HUB
    can use when first setting up and before they apply and get their own
    node number.

    The problem I have at present is that someone has set up their BBS and
    is polling the HUB every 2 minutes using the test AKA. This is way too frequent, has been going on for weeks, and despite a netmail to that
    test system asking for the sysop to contact me to arrange their own
    node number, there's been no reply and no let up in polling frequency.

    I'm looking for a way for BinkD to reject the incoming connection
    based on something like SYS or ZYZ info presented. Is such a thing possible using a perl script or similar?

    Note I am not a perl guru so any suggested fix you have I'd appreciate
    a bit of hand holding to implement it.

    Also of note, setting such a block up is not my preferred choice but I have exhausted options to contact the unknown sysop and want to ensure
    the test AKA is available for others to send/recieve packets from
    also... with a polling frequency of 2 mins the offending system gives
    no one else a look in.

    Why not just block his IP (range) in your firewall? That would be the easy sollution...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Hayton@3:770/100 to Wilfred van Velzen on Thu May 20 21:19:13 2021
    On 20 May 2021 at 10:29a, Wilfred van Velzen pondered and said...

    Why not just block his IP (range) in your firewall? That would be the
    easy sollution...

    because I don't really know it, and I suspect other nodes may be part of that range... I started to do this using specific IPs but the node concerned
    changed IP each day etc. so it was a bit like playing whack a mole... hence
    the thinking about using sysop name or system name

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Paul Quinn on Thu May 20 21:19:32 2021
    On 20 May 2021 at 06:22p, Paul Quinn pondered and said...

    I see in the binkD FAQ that there is a way to block a known IP. Check
    out the distro .CFG file. Good luck.

    thanks, the IP seems to be dynamic so it's not so easy :(

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alexey Fayans@2:5030/1997 to Paul Hayton on Thu May 20 12:14:55 2021
    Hello Paul!

    On Thu, 20 May 2021 at 19:59 +1200, you wrote to All:

    Also of note, setting such a block up is not my preferred choice but I have exhausted options to contact the unknown sysop and want to ensure
    the test AKA is available for others to send/recieve packets from
    also... with a polling frequency of 2 mins the offending system gives
    no one else a look in.

    If your system can suffer from DoS because of a single person making single connection once in 2 minutes, imagine what happens, if someone will poll your system from a small botnet (like 100 servers) via random proxies making 10-100 connections per second each. Just for fun.

    By the way, binkd can handle multiple connections simultaneously, so I can't really imagine how a single node can cause DoS by polling your system every 2 minutes.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Thu May 20 11:30:12 2021
    Hi Paul,

    On 2021-05-20 21:19:13, you wrote to me:

    Why not just block his IP (range) in your firewall? That would be the
    easy sollution...

    because I don't really know it, and I suspect other nodes may be part of that range...

    It should be easy to check if your other links are in the same IP range...


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oli@2:280/464.47 to Paul Hayton on Thu May 20 12:52:40 2021
    Paul wrote (2021-05-20):

    I'm looking for a way for BinkD to reject the incoming connection based on something like SYS or ZYZ info presented. Is such a thing possible using a perl script or similar?

    Note I am not a perl guru so any suggested fix you have I'd appreciate a bit of hand holding to implement it.

    There is some documentation in doc/perlhooks.txt

    I think it should be possible to abort the session:

    6) after_handshake()
    - called after complete login information transferred
    - defined vars: session level 2
    - return non-empty string to abort session with that reason

    Session Data

    This variables are set for session hooks depending of their availability:

    1 2 3 <- session vars level (see hooks description)
    $sysname + + remote system name
    $sysop + + remote sysop



    Have you built binkd with perl support?

    ---
    * Origin: . (2:280/464.47)
  • From Oli@2:280/464.47 to Paul Hayton on Thu May 20 13:13:14 2021
    Works:

    + 13:06 [2106] call to 4095:1/2@testnet
    13:06 [2106] connected
    + 13:06 [2106] outgoing session with localhost:24554
    - 13:06 [2106] OPT CRAM-MD5-999cab24e1f847d0f6ffb387ad8bb2ee
    + 13:06 [2106] Remote requests MD mode
    - 13:06 [2106] SYS 🌺
    - 13:06 [2106] ZYZ Oli
    - 13:06 [2106] LOC â›…
    - 13:06 [2106] NDL IBNS
    - 13:06 [2106] TIME Thu, 20 May 2021 12:06:07 +0000
    - 13:06 [2106] VER binkd/1.1a-111/Linux binkp/1.1
    + 13:06 [2106] addr: 4095:1/2@testnet
    + 13:06 [2106] pwd protected session (MD5)
    - 13:06 [2106] session in CRYPT mode
    ? 13:06 [2106] aborted by Perl after_handshake(): Get lost!
    + 13:06 [2106] done (to 4095:1/2@testnet, failed, S/R: 0/0 (0/0 bytes))


    Script:
    sub after_handshake
    {
    if ($sysop eq "Oli") {
    return "Get lost!";
    }
    else
    {
    return 0
    }
    }


    Shorter version:

    sub after_handshake
    {
    return ($sysop eq "Oli" ? "Get lost!" : 0);
    }


    I don't code in Perl, maybe there are better ways to do it.

    ---
    * Origin: . (2:280/464.47)
  • From Dumas Walker@1:2320/105 to ALEXEY FAYANS on Thu May 20 10:45:00 2021
    By the way, binkd can handle multiple connections simultaneously, so I can't r
    lly imagine how a single node can cause DoS by polling your system every 2 min
    es.

    The issue is that the polling node is using the test node number, /999,
    instead of an assigned number. Anyone else who is trying to test a new connection, who does not somehow manage to get their polls all done in the 2-minute window, will have whatever response messages they were looking for picked up by the offending node.

    Paul -- if nothing else, maybe you could set up a second/new test node,
    like /9999, to allow others to test?

    Mike


    * SLMR 2.1a * I idiot-proof my programs, but along comes a bigger idiot
    --- SBBSecho 3.12-Linux
    * Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)
  • From Wilfred van Velzen@2:280/464 to Dumas Walker on Thu May 20 18:23:16 2021
    Hi Dumas,

    On 2021-05-20 10:45:00, you wrote to ALEXEY FAYANS:

    Paul -- if nothing else, maybe you could set up a second/new test
    node, like /9999, to allow others to test?

    What century do you live in? ;-)

    The times the new nodes were lining up by the dozens are long gone...

    Mike

    Or Dumas?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Paul Hayton@3:770/100 to Alexey Fayans on Fri May 21 13:10:39 2021
    On 20 May 2021 at 12:14p, Alexey Fayans pondered and said...

    If your system can suffer from DoS because of a single person making single connection once in 2 minutes, imagine what happens, if someone

    It's not a DoS issue. But thanks for the reply.

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Oli on Fri May 21 13:11:24 2021
    On 20 May 2021 at 01:13p, Oli pondered and said...

    Works:
    ? 13:06 [2106] aborted by Perl after_handshake(): Get lost!
    + 13:06 [2106] done (to 4095:1/2@testnet, failed, S/R: 0/0 (0/0 bytes))

    Thanks for the info, very helpful :)

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Dumas Walker on Fri May 21 13:12:10 2021
    On 20 May 2021 at 10:45a, Dumas Walker pondered and said...

    The issue is that the polling node is using the test node number, /999, instead of an assigned number. Anyone else who is trying to test a new connection, who does not somehow manage to get their polls all done in
    the 2-minute window, will have whatever response messages they were looking for picked up by the offending node.

    Correct Mike.

    Paul -- if nothing else, maybe you could set up a second/new test node, like /9999, to allow others to test?

    Thanks Mike... I'd like to keep it simple and just use /999 but appreciate
    the idea.

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Paul Hayton@3:770/100 to Wilfred van Velzen on Fri May 21 13:13:36 2021
    On 20 May 2021 at 06:23p, Wilfred van Velzen pondered and said...

    What century do you live in? ;-)
    The times the new nodes were lining up by the dozens are long gone...

    Seems a bit rough to respond in that fashion.... while it's not a long queue now having a /999 test address is proving to be useful on a week to week
    basis in Z21

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Tony Langdon@3:633/410 to Oli on Fri May 21 09:16:00 2021
    On 05-20-21 13:13, Oli wrote to Paul Hayton <=-


    Script:
    sub after_handshake
    {
    if ($sysop eq "Oli") {
    return "Get lost!";
    }
    else
    {
    return 0
    }
    }

    I like it. :)



    ... The families of one's friends are always a disappointment.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Paul Hayton@3:770/100 to Oli on Fri May 21 16:20:30 2021
    On 20 May 2021 at 12:52p, Oli pondered and said...

    Have you built binkd with perl support?

    Thanks for this info too :)

    Yes I have built with perl and can confirm this did the trick. Thank you for your help with one.

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Alexey Fayans@2:5030/1997 to Dumas Walker on Fri May 21 10:03:33 2021
    Hello Dumas!

    On Thu, 20 May 2021 at 10:45 -0400, you wrote to me:

    The issue is that the polling node is using the test node number,
    /999, instead of an assigned number. Anyone else who is trying to
    test a new connection, who does not somehow manage to get their polls
    all done in the 2-minute window, will have whatever response messages
    they were looking for picked up by the offending node.

    I still don't get it. The only problem that can happen is that /999 will be reported busy for a second or two once in every 2 minutes. If that's a big deal then a perl hook suggested by Oli might do the trick. I'm not sure, though, because this hook is fired after the handshake is made, so a busy flag may already be set, which means it doesn't really matter how exactly session will be terminated: via hook or normally.

    If by "messages they were looking for" you mean NOT binkp protocol messages but some netmail or echomail messages, then it's just a terrible design flaw and should be addressed in completely different way instead of trying to ban someone who is not doing anything harmful.


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Wilfred van Velzen@2:280/464 to Paul Hayton on Fri May 21 09:00:26 2021
    Hi Paul,

    On 2021-05-21 13:13:36, you wrote to me:

    What century do you live in? ;-)
    The times the new nodes were lining up by the dozens are long gone...

    Seems a bit rough to respond in that fashion.... while it's not a long queue now having a /999 test address is proving to be useful on a week to week basis in Z21

    Sure, but having 2 of those?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michiel van der Vlist@2:280/5555 to Alexey Fayans on Fri May 21 11:21:27 2021
    Hello Alexey,

    On Friday May 21 2021 10:03, you wrote to Dumas Walker:

    If by "messages they were looking for" you mean NOT binkp protocol messages but some netmail or echomail messages, then it's just a
    terrible design flaw and should be addressed in completely different
    way instead of trying to ban someone who is not doing anything
    harmful.

    I think you hit the nail right on the head. Using net/999 for all applicants is a basic flow because it will go wrong when there are two applicants at the same time. That flaw has always been there but in the POTS age it was very rare that two application windows overlapped and applicants did not poll every few minutes for the responce to an application.

    It is not really binkd related and I have no instant solution...


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Dumas Walker@1:2320/105 to WILFRED VAN VELZEN on Fri May 21 16:34:00 2021
    Paul -- if nothing else, maybe you could set up a second/new test
    node, like /9999, to allow others to test?

    What century do you live in? ;-)

    The times the new nodes were lining up by the dozens are long gone...

    He isn't talking about FIDO. The othernet in question actually does have
    nodes joining.


    * SLMR 2.1a * Maybe I should cut the power before I-- ZZZAAPPOWWWWWW
    --- SBBSecho 3.12-Linux
    * Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)