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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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
--- SBBSecho 3.01-Linux
* Origin: Dock Sud BBS - http://bbs.docksud.com.ar (4:902/26)

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)

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)

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)

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)

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)

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)

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)

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)

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)