I was going over the docs wrt banning with iptables

In most Linux installations iptables wi

ll be owned by root, and thus MIS>will not have access to us
e the command. You will need to chown iptables so>the BBS us
er can access it, or chmod it so all users can use it.
This won't actually work. The issue is r
oot access to the kernel netfilterinterface, not
the iptables program. Most distributions don'
t even botherprotecting the iptables binary from unprivi
leged users. They can't actually do
anything with it. They can run it from /sbin
/ owned or not, make a copy ownedby th
emselves in their home directory and run it there or even compile the
irown copy and run it.You
'd need to either chmod the iptables binary setuid root
(not recommended)or give the bbs user
sudo permission to it and have them run it that way. Û²±°mysticbbs@guybrush²±²ÛÛ²±° Thu
Dec 21 10:31:19pm~ $ ls /sbin/iptables /usr/sbin/i
pset -l-rwxr-xr-x 1 mysticbbs mysticbbs 60704 Sep 12 02:01 /sbin/iptables-rwxr-xr-x 1 mysticbbs mysticbbs 26
560 Sep 27 17:27 /usr/sbin/ipsetÛ²±°
mysticbbs@guybrush²±²ÛÛ²±° Thu Dec 21 10:31:
27pm~ $ /usr/sbin/ipset create test hash:ip
ipset v6.34: Kernel error received: Operation not permittedÛ ²±°mysticbbs@guybrush²±²ÛÛ²±° Thu
Dec 21 10:31:43pm~ $ /sbin/iptables -I INPUT -s 104
.43.195.251 -j DROPiptables v1.6.1: can't initialize iptable
s table `filter': Permission denied (you must be root)Perhap
s iptables or your kernel needs to be upgraded.
--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

You'd need to either chmod the iptables binary setuid root (not recommende or give the bbs user sudo permission to it and have them run it that way.

Okay, I must have chmodded it and forgot what I did. It is working on my system without sudo but when I set it up I wasn't really thinking about security at the time.

So it sounds like to me the recommended way to do it then would be to configure the bbs user to be able to sudo iptables without a password? I'll have to make a Wiki section on this stuff along with how to remove IP addresses in your iptables as well.

--- Mystic BBS v1.12 A37 2017/12/21 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/22/17, g00r00 said the following...

So it sounds like to me the recommended way to do it then would be to configure the bbs user to be able to sudo iptables without a password?

You should also be able to pipe a password to sudo using the -S switch to
have it read from stdin, should you not want it to operate passwordless.
eg: echo "mypassword" | sudo iptables -I INPUT -s 104.93.81.50 -j DROP

Sudo is probably the way to go short of having an external root-level service like fail2ban monitor the logs or some custom output file.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 12/22/17, Static said the following...

eg: echo "mypassword" | sudo iptables -I INPUT -s 104.93.81.50 -j DROP

And of course I forget the actual switch:
echo "mypassword" | sudo -S iptables -I INPUT -s 104.93.81.50 -j DROP

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 12/22/17, Static said the following...

On 12/22/17, Static said the following...

eg: echo "mypassword" | sudo iptables -I INPUT -s 104.93.81.50 -j DRO

And of course I forget the actual switch:
echo "mypassword" | sudo -S iptables -I INPUT -s 104.93.81.50 -j DROP

Gonna give this a try, been unable to use the new ip block.

Cheers/Thanks!
Pequito

--- Mystic BBS v1.12 A37 2017/12/21 (Linux/64)
* Origin: Twinkle BBS # (21:1/126)

On 12/22/17, Static said the following...

And of course I forget the actual switch:
echo "mypassword" | sudo -S iptables -I INPUT -s 104.93.81.50 -j DROP

Well that works nicely! .. but I think I have the event configured wrong or
one of the other parameters wrong in mystic-cfg. Using @IP@ instead of a specific IP. It is currently autobanning and adding iptable DROPs for every connection... including myself..haha.

-=Pepper=-

--- Mystic BBS v1.12 A37 2017/12/13 (Raspberry Pi/32)
* Origin: Cosmik Debris BBS | Little Falls,NY (21:1/187)

g00r00 wrote to Static <=-

So it sounds like to me the recommended way to do it then would be to configure the bbs user to be able to sudo iptables without a password?

That would be the way I would do it.


... Please no deja vu; I don't want to go through that again.
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)

Static wrote to g00r00 <=-

On 12/22/17, g00r00 said the following...

So it sounds like to me the recommended way to do it then would be to configure the bbs user to be able to sudo iptables without a password?

You should also be able to pipe a password to sudo using the -S switch
to have it read from stdin, should you not want it to operate passwordless. eg: echo "mypassword" | sudo iptables -I INPUT -s 104.93.81.50 -j DROP

Have to be careful that can't be easily read on your system, otherwise you might be giving a sensitive password away. :)


... COMMAND: A suggestion made to a computer.
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)

On 12/23/17, Pepper said the following...

Well that works nicely! .. but I think I have the event configured wrong or one of the other parameters wrong in mystic-cfg. Using @IP@ instead
of a specific IP. It is currently autobanning and adding iptable DROPs
for every connection... including myself..haha.

Ouch. The "IP Blocked" event type should only fire if Mystic actually bans
an IP or blocks a connection from an IP in its blacklist. I only used a specific IP as an example of how the command would be used from the command line.

I think the pertinent event settings would look something like this:
Active: Yes
Event Type: IP Blocked
Shell: echo "mypassword" | sudo -S /sbin/iptables -I INPUT -s @IP@ -j DROP

Or if you're using ipset your shell command would be more like:
Shell: echo "mypassword" | sudo -S /usr/sbin/ipset add blacklist @IP@

Or your own shell script that takes @IP@ as an argument.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 12/23/17, Tony Langdon said the following...

Have to be careful that can't be easily read on your system, otherwise
you might be giving a sensitive password away. :)

True, but at least if someone finds a way to execute arbitrary commands as
the mystic user they have to find the user's password before they can ban 0.0.0.0/0.

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

Static wrote to vk3jed <=-

On 12/23/17, Tony Langdon said the following...

Have to be careful that can't be easily read on your system, otherwise
you might be giving a sensitive password away. :)

True, but at least if someone finds a way to execute arbitrary commands
as the mystic user they have to find the user's password before they
can ban 0.0.0.0/0.

Good point. :)


... Drink Canada Dry! Maybe you can't, but it's fun trying!
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)

On 12/23/17, Static said the following...

Ouch. The "IP Blocked" event type should only fire if Mystic actually
bans an IP or blocks a connection from an IP in its blacklist. I only

Yep, I was using the iptables version. It seems to be running on every connection to the BBS and automatically banning everyone.
I have to spend a few minutes going through some of the parameters it uses
for banning.. number of connections / time .. etc.
When the Event is enabled it adds the iptables rule *and* adds the IP to the blacklist.txt file. When the Event is not enabled it does neither.

-=Pepper=-

--- Mystic BBS v1.12 A37 2017/12/13 (Raspberry Pi/32)
* Origin: Cosmik Debris BBS | Little Falls,NY (21:1/187)

On 12/23/17, Pepper said the following...

When the Event is enabled it adds the iptables rule *and* adds the IP
to the blacklist.txt file. When the Event is not enabled it does neither.

That definitely shouldn't be the case. The IP Blocked event shouldn't activate at all on a benign connection. How many connections are you allowing over how much time on your servers before blocking?

--- Mystic BBS v1.12 A36 2017/12/03 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 12/24/17, Static said the following...

That definitely shouldn't be the case. The IP Blocked event shouldn't activate at all on a benign connection. How many connections are you allowing over how much time on your servers before blocking?

4 connections in 120 sec and Dupe is 1.
I added my IP to the whitelist and of course that stopped me from getting banned.
I'll keep an eye on things, as I've made a load of changes back and forth to see if it's still happening for other connections.

-=Pepper=-

--- Mystic BBS v1.12 A37 2017/12/13 (Raspberry Pi/32)
* Origin: Cosmik Debris BBS | Little Falls,NY (21:1/187)