• Unwanted connections to port 23.

    From Ignatius@1:340/800 to All on Mon Jun 12 00:54:18 2017
    I've since recently put my board back on port 23... and I now recall why I
    took it off of it. I keep getting all of these connections from hackers, I
    take it. Anyone know of a way to filter these bad connections?

    I've tried Janis' iptables suggestion, but it isn't working.

    Thanks,
    Joseph



    * Origin: catch twenty two >>> >> > (1:340/800)
  • From mark lewis@1:3634/12.73 to Ignatius on Mon Jun 12 04:35:52 2017

    On 2017 Jun 12 00:54:18, you wrote to All:

    I've since recently put my board back on port 23... and I now recall
    why I took it off of it. I keep getting all of these connections from hackers, I take it.

    they are not hackers... at best they are skiddies but in reality, it is the MIRAI botnets trying to see if your system is a vulnerable IoT (Internet of Things) device like an IP Camera or a DVR or smart TV and similar... anything that has default login credentials hardcoded in it...

    Anyone know of a way to filter these bad connections?

    there is none, really... you have to let them connect and then dump them based on the data they shove at you without waiting for any prompts... yes, that's right... they do not look for and respond to any sort of login prompts... they just start spewing their login stuff followed by the shell commands to fire off
    busybox...

    I've tried Janis' iptables suggestion, but it isn't working.

    intrusion detection systems are the only things i've seen that come close but the connection and attempted login still has to take place... the *ONLY* other option is to get off of port 23 and the other few that MIRAI specifically targets... that includes the default SSH port as well...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... WANTED: Meaningful overnight relationship.
    ---
    * Origin: (1:3634/12.73)
  • From j b l@1:154/700 to mark lewis on Mon Jun 12 06:24:08 2017
    Re: Unwanted connections to port 23.
    By: mark lewis to Ignatius on Mon Jun 12 2017 04:35 am


    intrusion detection systems are the only things i've seen that come close but the connection and attempted login still has to take place... the *ONLY* other option is to get off of port 23 and the other few that MIRAI specifically targets... that includes the default SSH port as well...

    I've just come across a utility, called "PSAD", it is a port scanning utility.. if the "danger level" meets a certain threshold, it will automatically block the offending IP address. Pretty cool. I'm still testing it out at the moment, but this may be what i've been looking for.

    Thanks,
    Joseph
    --- SBBSecho 3.00-Linux
    * Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
  • From Joe Bruchis@1:3828/12 to j b l on Mon Jun 12 09:59:30 2017
    j b l wrote in a message to mark lewis:

    Re: Unwanted connections to port 23.
    By: mark lewis to Ignatius on Mon Jun 12 2017 04:35 am


    intrusion detection systems are the only things i've seen that
    come close
    but the connection and attempted login still has to take place... the *ONLY* other option is to get off of port 23 and the other few
    that MIRAI
    specifically targets... that includes the default SSH port as well...

    I've just come across a utility, called "PSAD", it is a port
    scanning utility.. if the "danger level" meets a certain
    threshold, it will automatically block the offending IP address.
    Pretty cool. I'm still testing it out at the moment, but this may
    be what i've been looking for.

    I have minimized these attempts with the following entries in sbbs.ini:

    LoginAttemptDelay = 50000
    LoginAttemptThrottle = 50000
    LoginAttemptHackThreshold = 3
    LoginAttemptBanThreshold = 3

    Assume a bot attempts a login as Root. Root does not exist in the user files. The 50000 value will pause the next login prompt 45 seconds before another login name can be entered. This is usually enough time for the bot to move on to its next victim. The downside is, if a real user accidentally places a typo in their login name, they will have to wait 45 seconds before they are prompted
    for their login name again. That can be remedied with a warning screen prior to
    the login prompt, letting your users know that because of automated hacking bots, failed login attempts will be paused 45 seconds before the next login attempt will be accepted.

    It works well here.

    Regards,

    Joe
    --- timEd/386 1.10+
    * Origin: Fire on the Bayou BBS - bayouflames.ddns.net (1:3828/12)
  • From mark lewis@1:3634/12.73 to j b l on Mon Jun 12 11:30:10 2017

    On 2017 Jun 12 06:24:08, you wrote to me:

    intrusion detection systems are the only things i've seen that come
    close but the connection and attempted login still has to take
    place... the *ONLY* other option is to get off of port 23 and the
    other few that MIRAI specifically targets... that includes the
    default SSH port as well...

    I've just come across a utility, called "PSAD", it is a port scanning utility.. if the "danger level" meets a certain threshold, it will automatically block the offending IP address. Pretty cool. I'm still testing it out at the moment, but this may be what i've been looking
    for.

    i can't say that i've ever heard of it but these bots are not port scanning... they're connecting and spewing their login stream... if there's nothing there to connect to, they cannot spew and they move on to the next IP address they've
    been directed to look at...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
    ... 56. Admit it when you're wrong.
    ---
    * Origin: (1:3634/12.73)
  • From Chad Adams@1:130/210 to All on Fri Jun 16 21:42:12 2017
    Or use a BBS that maintains its own dnsbl and blocking ability! :)

    On 05:30 12/06 , mark lewis wrote:

    On 2017 Jun 12 06:24:08, you wrote to me:

    intrusion detection systems are the only things i've seen that come
    close but the connection and attempted login still has to take
    place... the *ONLY* other option is to get off of port 23 and the
    other few that MIRAI specifically targets... that includes the
    default SSH port as well...

    I've just come across a utility, called "PSAD", it is a port scanning utility.. if the "danger level" meets a certain threshold, it will automatically block the offending IP address. Pretty cool. I'm still testing it out at the moment, but this may be what i've been looking
    for.

    i can't say that i've ever heard of it but these bots are not port scanning... >they're connecting and spewing their login stream... if there's nothing there >to connect to, they cannot spew and they move on to the next IP address they've
    been directed to look at...

    )\/(ark

    Always Mount a Scratch Monkey
    Do you manage your own servers? If you are not running an IDS/IPS yer doin' it >wrong...
    ... 56. Admit it when you're wrong.
    ---
    * Origin: (1:3634/12.73)


    --
    yrNews Usenet Reader for iOS
    http://appstore.com/yrNewsUsenetReader

    --- Mystic BBS/NNTP v1.12 A33 (Linux/64)
    * Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (1:130/210)
  • From Jon Watson@1:249/207 to Ignatius on Thu Aug 10 12:37:12 2017
    Hi,

    I've tried Janis' iptables suggestion, but it isn't working.

    What didn't work about it? Seems the only real variable in there is the nic (eth0 in Janis' example).

    --- Mystic BBS v1.10 (Linux)
    * Origin: TheHeartOfGoldBBS.ca (1:249/207)
  • From Fernando Toledo@4:902/26 to Ignatius on Thu Sep 7 10:39:36 2017
    El 11/06/17 a las 21:54, Ignatius escribió:
    I've since recently put my board back on port 23... and I now recall why I took it off of it. I keep getting all of these connections from hackers, I take it. Anyone know of a way to filter these bad connections?

    I've tried Janis' iptables suggestion, but it isn't working.

    Thanks,
    Joseph



    try fail2ban
    --- SBBSecho 3.01-Linux
    * Origin: Dock Sud BBS - http://bbs.docksud.com.ar (4:902/26)
  • From Joacim Melin@2:201/120 to Fernando Toledo on Thu Sep 7 22:06:06 2017
    4.9.2
    El 11/06/17 a las 21:54, Ignatius escribió:
    I've since recently put my board back on port 23... and I now recall why I >> took it off of it. I keep getting all of these connections from hackers, I >> take it. Anyone know of a way to filter these bad connections? >>
    I've tried Janis' iptables suggestion, but it isn't working. >>
    Thanks,
    Joseph



    try fail2ban

    Have a look at this:

    https://github.com/punktniklas/NiKom/tree/master/Extras/Botcheck


    --- NiKom v2.3.1
    * Origin: Delta City (deltacity.se, Vallentuna, Sweden) (2:201/120.0)
  • From Janis Kracht@1:261/38 to Ignatius on Tue Oct 24 13:06:34 2017
    Hi Joseph,

    I've since recently put my board back on port 23... and I now recall why I took it off of it. I keep getting all of these connections from hackers, I take it. Anyone know of a way to filter these bad connections?

    I've tried Janis' iptables suggestion, but it isn't working.

    The first thing I do after a reboot (which happens rarely) is turn off iptables
    since ubuntu starts if right off the bat everytime automatically:

    iptables -F
    iptables -X

    The above two commands do that. Once I've turned it off, I restart it with my own parameters in the two lines below:

    For my web server which I run on port 8080:

    1)sudo iptables -I INPUT -p tcp --dport 8080 -i eth0 -m state --state NEW -m recent --set [all on one line]

    2)sudo iptables -I INPUT -p tcp --dport 8080 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP [all on one line]

    I could use the same commands for my telnet server which runs on port 2030, so to include the telnet port I would change "dport 8080" with dport 2030 in the lines above. If you are using port 23, you would change dport to 23 above.

    Finally, I issue the command:
    sudo iptables -L
    to check that I've got the iptables command that I want:

    bbs@filegate:~$ sudo iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    DROP tcp -- anywhere anywhere tcp dpt:http-alt state NEW recent: UPDATE seconds: 60 hit_count: 2 name: DEFAULT side: source
    tcp -- anywhere anywhere tcp
    dpt:http-alt state NEW recent: SET name: DEFAULT side: source

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    The above two commands keep jokers from killing my servers after two connections in 60 seconds :)

    Hope this helps,
    Janis

    --- BBBS/Li6 v4.10 Toy-3
    * Origin: Prism bbs (1:261/38)
  • From Janis Kracht@1:261/38 to Ignatious on Tue Oct 24 13:20:36 2017
    Hi,

    I've since recently put my board back on port 23... and I now recall why I took it off of it. I keep getting all of these connections from hackers, I take it. Anyone know of a way to filter these bad connections?

    I've tried Janis' iptables suggestion, but it isn't working.

    The first thing I do after a reboot (which happens rarely) is turn off iptables
    since ubuntu starts if right off the bat everytime automatically:

    iptables -F
    iptables -X

    The above two commands do that. Once I've turned it off, I restart it with my own parameters in the two lines below:

    For my web server which I run on port 8080:

    1)sudo iptables -I INPUT -p tcp --dport 8080 -i eth0 -m state --state NEW -m recent --set [all on one line]

    2)sudo iptables -I INPUT -p tcp --dport 8080 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 2 -j DROP [all on one line]

    I could use the same commands for my telnet server which runs on port 2030, so to include the telnet port I would change "dport 8080" with dport 2030 in the lines above. If you are using port 23, you would change dport to 23 above.

    Finally, I issue the command:
    sudo iptables -L
    to check that I've got the iptables command that I want:

    bbs@filegate:~$ sudo iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    DROP tcp -- anywhere anywhere tcp dpt:http-alt state NEW recent: UPDATE seconds: 60 hit_count: 2 name: DEFAULT side: source
    tcp -- anywhere anywhere tcp
    dpt:http-alt state NEW recent: SET name: DEFAULT side: source

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    The above two commands keep jokers from killing my servers after two connections in 60 seconds :)

    Hope this helps,
    Janis

    --- BBBS/Li6 v4.10 Toy-3
    * Origin: Prism bbs (1:261/38)
  • From Phil Kimble@1:128/2 to Janis Kracht on Sun Oct 29 10:21:20 2017


    I've since recently put my board back on port 23... and I now recall
    why I took it off of it. I keep getting all of these connections from
    hackers, I take it. Anyone know of a way to filter these bad
    connections?

    I've tried Janis' iptables suggestion, but it isn't working.

    Have a look at fail2ban www.fail2ban.org claims to be a "poor man's ids".

    I installed it from the yum repos on CentOS7 & configured it for 3 attempts.
    If you fail to login for 3 attempts you are banned for 15 minutes. All activity is logged. Luckily I was smart enough to setup several local accounts <Thx Janis>
    so when I forget the admin password I was still able to reset the timer for that
    acount via sudo...

    I like it lots!



    --- Msged/LNX 6.1.2
    * Origin: Bayhaus.net - Colorado Springs - Serving the FrontRange (1:128/2)
  • From Janis Kracht@1:261/38 to Phil Kimble on Thu Nov 2 14:02:56 2017
    Hi Phil!

    I've tried Janis' iptables suggestion, but it isn't working.

    Have a look at fail2ban www.fail2ban.org claims to be a "poor man's ids".

    Nah, my system is fine using iptables. IIRC fail2ban uses iptables, right?

    I installed it from the yum repos on CentOS7 & configured it for 3 attempts.
    If you fail to login for 3 attempts you are banned for 15 minutes. All activit
    is logged. Luckily I was smart enough to setup several local accounts <Thx Janis>
    so when I forget the admin password I was still able to reset the timer for that
    acount via sudo...

    I like it lots!

    Great :)

    Take care,
    Janis

    --- BBBS/Li6 v4.10 Toy-3
    * Origin: Prism bbs (1:261/38)
  • From Richard Menedetter@2:310/31 to Janis Kracht on Thu Nov 2 20:13:42 2017
    Hi Janis!

    02 Nov 2017 14:02, from Janis Kracht -> Phil Kimble:

    Have a look at fail2ban www.fail2ban.org claims to be a "poor man's
    ids".
    Nah, my system is fine using iptables. IIRC fail2ban uses iptables,
    right?

    Yes.
    It can issue any command, but in the default config it will block via iptables.

    CU, Ricsi

    --- GoldED+/LNX
    * Origin: The Boy Scouts have adult leadership. The Army doesn't. (2:310/31)