net
Forum rules
This forum houses many years of development, tracing back to some of the earliest posts that exist on the board.
Its current use is for the continued development of the server and game it has always served: TMW Classic.
net
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?
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?
Former programmer for the TMWA server.
Re: net
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.
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.
You earn respect by how you live, not by what you demand.
-unknown
-unknown
Re: net
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 ...
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 ...
Former programmer for the TMWA server.
- Freeyorp101
- Archivist Prime
- Posts: 766
- Joined: 04 Nov 2008, 09:17
- Location: New Zealand
Re: net
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.o11c wrote: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 ...
---Freeyorp
(09:58:17) < tux9th> Freeyorp: your sig on the forums is kind of outdated
Re: net
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.
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.
You earn respect by how you live, not by what you demand.
-unknown
-unknown
Re: net
No, @block works at the account level, not the character level.Frost wrote: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.
Frost wrote:<snip>
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)Freeyorp101 wrote: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.o11c wrote: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 ...
---Freeyorp
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
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
Code: Select all
deny 192.168.0.0/16
allow all
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.
Former programmer for the TMWA server.