This isn't really required but it's my intention to implement these policies (or what we come to after some discussion). This is targeted _ONLY_ at this team and those with shell access to our servers. Its not my intention to roll it out to the larger community, though its certainly a good idea for people to read through it.
http://mmcgrath.fedorapeople.org/policy/
Give these a read and think on them some. There's quite a bit there. I understand that much of what is listed there is impossible to enforce, and I certainly don't think we'll be at the point where I'm removing people from groups who aren't following the policies but I'm hoping it won't come to that. For now though I'm thinking the honor system.
-Mike
On Sun, 11 Jan 2009, Mike McGrath wrote:
This isn't really required but it's my intention to implement these policies (or what we come to after some discussion). This is targeted _ONLY_ at this team and those with shell access to our servers. Its not my intention to roll it out to the larger community, though its certainly a good idea for people to read through it.
http://mmcgrath.fedorapeople.org/policy/
Give these a read and think on them some. There's quite a bit there. I understand that much of what is listed there is impossible to enforce, and I certainly don't think we'll be at the point where I'm removing people from groups who aren't following the policies but I'm hoping it won't come to that. For now though I'm thinking the honor system.
Just a reminder that we have a meeting today, I'd like to discuss this during that meeting.
-Mike
On Thu, Jan 15, 2009 at 9:35 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Sun, 11 Jan 2009, Mike McGrath wrote:
This isn't really required but it's my intention to implement these policies (or what we come to after some discussion). This is targeted _ONLY_ at this team and those with shell access to our servers. Its not my intention to roll it out to the larger community, though its certainly a good idea for people to read through it.
Mike, Take a look at Section 1.2. Host Network Security. There is a duplicate setting. The 4th setting is: net.ipv4.conf.all.accept_redirects = 0
This setting is duplicated in the 14th setting.
I'm guessing that the 4th setting should be removed.
Frank
On Thu, Jan 15, 2009 at 9:25 PM, Frank Chiulli frankc.fedora@gmail.com wrote:
On Thu, Jan 15, 2009 at 9:35 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Sun, 11 Jan 2009, Mike McGrath wrote:
This isn't really required but it's my intention to implement these policies (or what we come to after some discussion). This is targeted _ONLY_ at this team and those with shell access to our servers. Its not my intention to roll it out to the larger community, though its certainly a good idea for people to read through it.
Mike, Take a look at Section 1.2. Host Network Security. There is a duplicate setting. The 4th setting is: net.ipv4.conf.all.accept_redirects = 0
This setting is duplicated in the 14th setting.
I'm guessing that the 4th setting should be removed.
Frank
Mike, First let me say that the examples are a great addition to the page.
I was looking at the iptables sample configuration and had some questions. I compared your suggested configuration to my current configuration (Fedora 10). With the exception of the lines with '--tcp-flags' in your sample configuration, they're pretty close. I don't have those yet. The first three lines that start with '-A' in your sample are the same as mine except the order is different. Does the order make a difference?
Here are the lines from my file: -A INPUT -m state --state ESTABLISHED,RELATED -j accept -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT
Here are yours: -A INPUT -i lo -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT
Thanks, Frank
On Fri, 16 Jan 2009, Frank Chiulli wrote:
Mike, First let me say that the examples are a great addition to the page.
I was looking at the iptables sample configuration and had some questions. I compared your suggested configuration to my current configuration (Fedora 10). With the exception of the lines with '--tcp-flags' in your sample configuration, they're pretty close. I don't have those yet. The first three lines that start with '-A' in your sample are the same as mine except the order is different. Does the order make a difference?
Here are the lines from my file: -A INPUT -m state --state ESTABLISHED,RELATED -j accept -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT
Here are yours: -A INPUT -i lo -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT
The order isn't that important though I should really have established,related come first. The main reason for this is because IPTables runs like a list, any already approved content doesn't have to get checked against much of the list but instead is automatically approved.
This has security implications but for most setups its a good policy. I'll actually move that up now and refresh that page soon.
-Mike
On Sat, Jan 17, 2009 at 10:43 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Fri, 16 Jan 2009, Frank Chiulli wrote:
Mike, First let me say that the examples are a great addition to the page.
I was looking at the iptables sample configuration and had some questions. I compared your suggested configuration to my current configuration (Fedora 10). With the exception of the lines with '--tcp-flags' in your sample configuration, they're pretty close. I don't have those yet. The first three lines that start with '-A' in your sample are the same as mine except the order is different. Does the order make a difference?
Here are the lines from my file: -A INPUT -m state --state ESTABLISHED,RELATED -j accept -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT
Here are yours: -A INPUT -i lo -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT
The order isn't that important though I should really have established,related come first. The main reason for this is because IPTables runs like a list, any already approved content doesn't have to get checked against much of the list but instead is automatically approved.
It used to be that the state lookup might take more 'energy' than the general accept.. and some servers which threw mostly stuff over loopback in single packets would experience a higher load than others. That is probably an issue that is not as relevant today as it was in the past.. but the general rule was get easy decisions done quickly, do hard ones later (especially if you were in a very hostile/noisy network). I think that theory would need to be tested again as the iptables weight for dealing with state is different from when you found a higher CPU and some packet delay if you didn't just drop worm port traffic first and then dealt with state.
-
This has security implications but for most setups its a good policy. I'll actually move that up now and refresh that page soon.
infrastructure@lists.fedoraproject.org
-
Frank Chiulli -
Mike McGrath -
Stephen John Smoogen