advice on grsecurity use to solve remote access use issues..

[sk8low]

First some background information. I have a large amount of servers, around one thousand of them, that are geographically dispearsed and on different providers networks. They are firewalled off with the exception of a few jump hosts that are allowed to connect over ssh, four of them to be exact. A few people have access to the jump hosts in order to run scripts that reload the services being provided by the remote servers. They also have the ability to ssh out to the servers and sudo to root and do work. I want to try to prevent someone from making a mistake and taking out all the servers at once or the possibility that someone might actually want to do that on purpose. I have been brainstorming on ways to do this. Limiting only two of the jump hosts to a set of servers so they would have to have access to both sets and dividing the team that works on things. I also thought about trying to limit the amount connections to the remote servers over time. Some sort of time based acl. What I want in the end is the ability to run automated commands across all the servers but at the same time prevent them from taking out the service. If one of the commands that you want them to be able run in an automated fassion has the ability to take out the service if ran across all the hosts at once how can you safely limit that or limit them from sshing to the boxes and rebooting it with sudo reboot. I was hoping some people might have some creative ways or just blatantly obvious uses for grsecurity's acl's or socket restrictions that would work. Any ideas?

[zakalwe]

Why not create some central management console/web app on the jump hosts that enforces your policy of rate limiting potentially dangerous operations etc. Have the grsec rbac deny all other means of doing the operations except through the management app. That way you can enforce any policy you want, with different levels of trust and privileges. You'd have to close off all the ways of accessing the other hosts of course (ssh forwarding etc).

[brant]

You can set up rate-based firewall rules with iptables. Time-based access can be granted by other means (/etc/login.defs maybe). There is also an owner module for iptables, which matches connections to users. grsecurity's RBAC system is pretty static once it's in place. Application of RBAC would help to ensure that your privileged users only have access to what they specifically need, and can greatly tighten system security. This goes for all other running processes as well. Socket restrictions can deny any of the following, which is based upon groups you set up:

server sockets
client sockets
all sockets

It might be advisable to deny server sockets, but this will prevent things like `nslookup` from being run. Client socket denials will prevent users from connecting at all. ;)

[brant]

correction: Denial of client sockets will disallow users from making outgoing connections, whoops. This can also be controlled by RBAC.