net

[o11c]

Address = unix path or ipv4 or ipv6
ipv4,ipv6 = dns name or numberic address
dns address may have multiple results, expand vectorwise, but compress maskwise
unix path has max 108 characters.

Matcher = Address (exact) or Address + int (bits for IPv4 and IPv6, does this even make sense for unix paths?) or Address + numeric address
but does anyone care about noncontiguous subnets?

[Frost]

I don't quite follow all of your post, but everything uses (and often assumes) CIDR subnetting, so non-contiguous subnets can be ignored.

In fact, those pedants who try to use non-contiguous subnets are loathed by network admins and vendors alike, and are threatened with violence in return. I say this from personal experience as just such a pedant.

[o11c]

I figured that was probably so ...
The other thing is what do do about matching paths (which includes ttys as a sort of fake socket). I don't feel like doing a full-blown regex, but it might be useful to be able to match files in /tmp/, in /dev/pts/, /dev/tty*, and match /dev/tty *without* /dev/tty*

Edit: hm ... I want to get rid of the deny,alllow vs allow,deny vs mutual-failure ...

The easiest thing (least processing per connection) would be to only allow one kind of list: either allow all addresses by default and use a blacklist, or deny all addresses by default and use a whitelist ... the latter is generally useful for main player connections, but makes sense for tmwa-admin connections.

Is it acceptable to say "If you need more complex rules, use a proper firewall"? I'd vote for fully removing the undoubtedly-inefficient filtering, but that would require root access to block IPs. Unless you wrote a setuid program ...

Hmm ... Now that I think of it, I could avoid the linear traversal by using a RangeSet ... and that would even allow arbitrary allow/deny chains at parse time ...

[Freeyorp101]

Is it acceptable to say "If you need more complex rules, use a proper firewall"? I'd vote for fully removing the undoubtedly-inefficient filtering, but that would require root access to block IPs. Unless you wrote a setuid program ...

The current system is used to block tor exit nodes and also for blocking repeat offenders. The system shouldn't be removed unless there is a direct replacement, and I do not think that it would be reasonable to require a setuid program as a substitute.


---Freeyorp

[Frost]

Is this about how to implement things like @block as currently used in tmwAthena? I'm not familiar with the tA code, so I apologize if I'm missing the point.

If so, I suggest keeping such access control within the application itself.
First, it's standard security practice to have "application admins" who do not have root access.
Second, I don't think we can assume that everyone who sets up a tA server can rattle off commands like (assuming Ubuntu*):

iptables -N TMWDROP
iptables -A TMWDROP -j LOG
iptables -A TMWDROP -j DROP
iptables-save > /etc/network/iptables.rules
echo iptables \< /etc/network/iptables.rules > /etc/network/if.pre.d/iptables
chmod 750 /etc/network/if.pre.d/iptables
just to set it up, then
iptables -I INPUT 4 -i eth0 -p tcp -s <evil.ip.addr> -j TMWDROP
iptables-save > /etc/network/iptables.rules
to block each offending host.

Setuid commands are a common vector for privilege escalation attacks. From a security standpoint, that's not an option.

*These commands are approximate; I'm not really familiar with Ubuntu.

[o11c]

Is this about how to implement things like @block as currently used in tmwAthena? I'm not familiar with the tA code, so I apologize if I'm missing the point.

No, @block works at the account level, not the character level.

<snip>

Is it acceptable to say "If you need more complex rules, use a proper firewall"? I'd vote for fully removing the undoubtedly-inefficient filtering, but that would require root access to block IPs. Unless you wrote a setuid program ...

The current system is used to block tor exit nodes and also for blocking repeat offenders. The system shouldn't be removed unless there is a direct replacement, and I do not think that it would be reasonable to require a setuid program as a substitute.
---Freeyorp

Well, thanks for the information ... Still, my range_set implementation looks like it will work out great so far (I've implement add_single, remove_single, and add_range; still need to implement remove_range and test *_range)

Ignoring the ladmin list which is separate, is the whitelist used at all? I.e. to allow a single IP from a blocked range, or to only allow IPs from a certain range but block them later.

Currently, tmwAthena operates like this:

Code: Select all

// You are allowed if both lists are empty, or
// mode\ in list-> both    allow   deny    none
// allow,deny      Y       Y       N       N
// deny,allow      N       Y       N       Y
// mutual-failure  N       Y       N       N

My planned implementation would remove the "lists" and parse in order. So there is no possibility of "both" and "none", there is only "in the set" and "not in the set". It would probably make sense to have the set be an allow list, internally ...

So, every line in this is meaningful:

Code: Select all

allow all
deny 192.168.0.0/16
allow 192.168.1.0/24
deny 192.168.1.100

Whereas the "deny" in following would be pretty useless:

Code: Select all

deny 192.168.0.0/16
allow all

Also, I've been thinking about what was said about per-account IP whitelisting ... Well, skipping the blacklist, at least; it wouldn't be for specific IPs.

It would certainly be easier to be able to block as soon as the connection happens, but I can see a way to delay it until auth. In fact, that's where the current code does it, not that that's meaningful since I've redoing the socket code ...

Does it make sense to be able to add IP blocks after the server starts, e.g. via ladmin or GM commands?

I was thinking of chdir'ing to the save/ dir and then trying to chroot(".") (so the sysadmin can choose to 'setcap cap_sys_chroot+ep tmwa-*' - the first line of code will be to die if you are root), which would make conf/ inaccessible to writing (although I think writing to conf/ is a mistake anyway ... that's why I moved the GM file to save/, and once I write a better 'make install' target that knows about /etc or /usr/local/etc (don't worry, there will still be a $HOME install)) ... This would also preclude inotify+reload of conf files, although the only tool that I think that should really be used for is tmwa-monitor, of which I have only thoughts (such as "it should be startable from /etc/init.d" and be able to spawn whatever worlds it needs to, and be able to reload its config file and kill/spawn if there are changes). Keeping in mind what has been said about notes in the GM file, I'll add a field that can be set/read with tmwa-admin ... although I guess 'cat' is still good for reading.