i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for call.
i have to manually kick the ghosts at least once a day (2-5 ghost nodes
in 12h).
any workaround to this, except delete chat1-5.dat from data directory
with cron like once every two hours? running mystic/x64 here.
to proof to that i'm not making shit up:
http://ascii.graphics/mysticmis.png
my blocked ip filelist is now over 300k.
seems that part of the problem is that the country blocking does not
work.
nodespy sees the ghost users "logging in" but they dont appear in the WFC screen. Im starting to wonder if the WFC differs from daemon mode in that sense?
I set up a system password that the telnet scanners fail all the time (prompt that says "type bbs to access the bbs" and expects bbs there.
now it seems that the ghost nodes dont appear.
the country blocking doesnt stick to logs at all, i dont have errors related to iplocation.bin in data/ or for the country ban textfile that matter either.
-Antti
i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for cal i have to manually kick the ghosts at least once a day (2-5 ghost nod in 12h).
any workaround to this, except delete chat1-5.dat from data directory with cron like once every two hours? running mystic/x64 here.
to proof to that i'm not making shit up:
http://ascii.graphics/mysticmis.png
my blocked ip filelist is now over 300k.
i have a problem with busy nodes with a37 prealpha. nodespy shows the lines are busy but mystic's mis says that they're all waiting for call.
i have to manually kick the ghosts at least once a day (2-5 ghost nodes
in 12h).
bughunting:
i noticed that using a system password prompt (like just type BBS to continue or so) does help. the scanners get stuck there and are kicked
out and a ghost node "logging in" mode is not created.
My proposal is this, and I'm hoping g00r00 sees it - additionally, I
think we should consider this for all BBSes moving forward, and try to surface these types of conversations outside the scope of being mystic only:
We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
answering services. We can put a 5 second timer (sysop configurable)
that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.
I think you can do this with startup.mps in a few lines of code if you want to. Its designed for oddball stuff like that :P I could probably whip something up in a few minutes for you.
Although I am confused by the hung nodes. If you have hung nodes there
is a bigger problem. Did you disable inactivity timeout? Some of them will sit there all day if you turn off the mechanism to time them out.
I DDOS MIS on Linux with a 50 node BBS that gets pushed to over 500,000 connections without a single leak, crash or ghost node. I also haven't had an unexplained ghost user in a very long time on my own BBS (unless something crashes when I'm developing which is explainable)... But I
also run on non-standard ports so it doesn't get beat on. Those two scenarios do not seem to produce stuck nodes for me for some reason.
I personally think the best idea is to just identify and resolve the issue! :)
My proposal is this, and I'm hoping g00r00 sees it - additionally, I think we should consider this for all BBSes moving forward, and try to surface these types of conversations outside the scope of being mystic only:
We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
answering services. We can put a 5 second timer (sysop configurable)
that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.
I think you can do this with startup.mps in a few lines of code if you want to.
Its designed for oddball stuff like that :P I could probably whip something up
in a few minutes for you.
Although I am confused by the hung nodes. If you have hung nodes there is a >bigger problem. Did you disable inactivity timeout? Some of them will sit >there all day if you turn off the mechanism to time them out.
I DDOS MIS on Linux with a 50 node BBS that gets pushed to over 500,000 >connections without a single leak, crash or ghost node. I also haven't had an >unexplained ghost user in a very long time on my own BBS (unless something >crashes when I'm developing which is explainable)... But I also run on >non-standard ports so it doesn't get beat on. Those two scenarios do not seem >to produce stuck nodes for me for some reason.
I need to put a BBS up on a laptop and just let it sit for a while.
I personally think the best idea is to just identify and resolve the issue! :)
--- Mystic BBS v1.12 A39 2018/01/04 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)
After country blocking and implementing IP blocking and various other options available in mystic -cfg, I don't have this issue. But initially
I did quite a bit. But, I also enabled a system password, so it could be
a false negative...I recall having pretty significant problems with hung nodes, with all default timeout settings.
Are you talking about the current version when you talk about these
nodes or was this with earlier versions that had known issues? I know
for a bit you were still using an older version and a copy of MIS that
had known issues.
I am going to get the latest copy of A39 installed on Linux/64 Ubuntu today and open it up to get hit by the bots. I usually also run a
System Password, so it may just be that I always had the "perfect combination" of settings to not see this issue on my own BBS.
I may also open the HTTP server just to try to get the load to be a
little higher on MIS as well, but I don't know if people scan HTTP in
the same way as telnet.
I may also open the HTTP server just to try to get the load to be a little higher on MIS as well, but I don't know if people scan HTTP in the same way as telnet.
They do scan for http, but they scan for endpoints, whereas with telnet they just try to login with BS credentials.
Mystic has an http server? :D
I had no idea. I don't see it in the list. I'm just using standard old nginx. :P
We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
answering services. We can put a 5 second timer (sysop configurable)
that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.
Please, before someone chimes in with some reason why we don't need more security, this isn't an argument for security. IOT botnets aren't targeting telnet bulletin boards, they just don't know how to
disambiguate a vulnerable server from a telnet BBS. So, we should step
up our game in finding ways to block these things from tying up our
nodes.
I think you can do this with startup.mps in a few lines of code if you
Although I am confused by the hung nodes. If you have hung nodes there
is a bigger problem. Did you disable inactivity timeout? Some of them will sit there all day if you turn off the mechanism to time them out.
connections without a single leak, crash or ghost node. I also haven't had an unexplained ghost user in a very long time on my own BBS (unless something crashes when I'm developing which is explainable)... But I
also run on non-standard ports so it doesn't get beat on. Those two scenarios do not seem to produce stuck nodes for me for some reason.
Are you talking about the current version when you talk about these
nodes or was this with earlier versions that had known issues? I know
for a bit you were still using an older version and a copy of MIS that
had known issues.
We should have a sysop-configurable option to enable a login "Press <escape> twice to continue" akin to old FrontDoor and Intermail
answering services. We can put a 5 second timer (sysop configurable)
that will just kick a user after the five seconds elapse. Ta-da, no more hung nodes.
the hung nodes -thing is also something mystic itself should take care of. i >dont know why it doesn't. if i have the time today, i'll set up a recorder >for some few hundred megs of traffic to see how mystic behaves (or tries to >behave or doesnt) when trying to break up the connection. the timeout values >that are set in the config clearly do not work.
but yes, the "press escape twice" thing is a good suggestion. i wonder if it >could be done with a a simple MPX as well (with my skills no way, but..)
Please, before someone chimes in with some reason why we don't need more security, this isn't an argument for security. IOT botnets aren't targeting telnet bulletin boards, they just don't know how to disambiguate a vulnerable server from a telnet BBS. So, we should step
up our game in finding ways to block these things from tying up our nodes.
hey, just run your telnet in another port! ..
im guessing also that the telnet scanning folks do not even know about the >bbs scene, and if they knew they wouldnt care haha.
|08\ |07H7|08 of |07Blocktronics/dIVINE sTYLERS!/aCCESSiON/TRSi/Break!Ascii >|08\ |07Haciend bbs sysop |08(|15telnet://haciend.com|08)|07
--- Mystic BBS v1.12 A37 2017/12/23 (Linux/64)
* Origin: Haciend.com | Scandinavian demoscene bbssince 1996 (21:1/155)
the hung nodes -thing is also something mystic itself should take care
of. i dont know why it doesn't. if i have the time today, i'll set up a recorder for some few hundred megs of traffic to see how mystic behaves (or tries to behave or doesnt) when trying to break up the connection.
the timeout values that are set in the config clearly do not work.
I need to find a way to get a stuck node for me to be able to fix it,
and for whatever reason I just cannot seem to do it. Anything you can figure out would be very appreciated.
I left a Linux/64 system up all weekend on 23 with no blocking and
Nodespy up with auto-snoop. Just like the last time I did this test for A38, there were zero stuck nodes, zero crashes, no problems at all.
It sounds like MIS is detecting the connection reset, but its just
unable to stop the node process for some reason. I wonder what the node process could be doing? Are you able ps -A and see the stuck node and strace it?
I'll see if I can clear out my iptables block list and then put it up again this weekend. Part of the problem is that I was running it with
an IPBlock event last time I had it up (a few weeks ago), so I ended up auto-blocking a TON of the botnet with iptables.
This past weekend I barely got hit compared to usual. Figures the one time I WANT them to spam the shit out of me, they don't lol.
Sysop: | sneaky |
---|---|
Location: | Ashburton,NZ |
Users: | 31 |
Nodes: | 8 (0 / 8) |
Uptime: | 131:58:47 |
Calls: | 2,073 |
Files: | 11,136 |
Messages: | 947,527 |