Firewall defects

[Arthur Demchenkov]

1) echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

DOESN'T WORK

Here's the description of why:

​http://forum.openvz.org/index.php?t=msg&goto=3144

Or just check kernel documentation: networking/ip-sysctl.txt

Probably the best thing we can do is adding this in rc.iptables:

echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

2) Same issue exists with rp_filter

This should be added to rc.iptables:

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

3) accept_redirects - same issue like with send_redirects (but only for non-routers, with routers current config works fine).

This should be added to rc.iptables:

echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects

4) Comment "Don¹t send Redirect Messages" - "Don¹t" -> "Don't", should be fixed

[bdubbs@…]

Replying to Spinal:

1) echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

DOESN'T WORK Probably the best thing we can do is adding this in rc.iptables: echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

It looks like we should add a default everyplace we have an all line, but I think the issue is not really relevant in most cases. It seems that it would only apply when adding a wifi card after the system is up and the firewall code has run.

3) accept_redirects - same issue like with send_redirects (but only for non-routers, with routers current config works fine).

OK.

4) Comment "Don¹t send Redirect Messages" - "Don¹t" -> "Don't", should be fixed

According to svn, I did that, but I have no idea how it was done. That's a 0xB9 when it should be a 0x27.

[Arthur Demchenkov]

Replying to bdubbs@…:

Replying to Spinal:

1) echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

DOESN'T WORK Probably the best thing we can do is adding this in rc.iptables: echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

It looks like we should add a default everyplace we have an all line, but I think the issue is not really relevant in most cases. It seems that it would only apply when adding a wifi card after the system is up and the firewall code has run.

It means only one thing. Read docs. Please :-)

We don't need to add default everyplace with "all" line.

I repeat, read docs... (The references are in the ticket itself).

If you don't want to read docs, just believe me. I know what I say.

And this... "I think the issue is not really relevant in most cases."... This is really hard matter. You think? That's all? No need in checking anything, just because you think? Really funny.

Bdubbs, I really respect you. I know you work hard on the book. But all that things... It's not just you.

--

P.S. There's one more issue with firewall. Here it is:

iptables -I INPUT -p tcp -m state --state INVALID \
  -j LOG --log-prefix "FIREWALL:INVALID"
iptables -I INPUT -p tcp -m state --state INVALID -j DROP

It inserts DROP BEFORE (!) LOG. Therefore we never get something about invalid packets in the log. The solution is to substitude "iptables -I INPUT -p tcp -m state --state INVALID -j DROP" with "iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP".

P.P.S. Bdubbs, don't resent. ;-)

[Arthur Demchenkov]

One more issue:

iptables -I INPUT -p tcp -m state --state INVALID \
  -j LOG --log-prefix "FIREWALL:INVALID"

It loggs packets like this:

Jan 28 22:03:10 localhost kernel: FIREWALL:INVALIDIN=br0 OUT= MAC=...

It's probably better to substitude "FIREWALL:INVALID" with "FIREWALL:INVALID ", don't you think?

"FIREWALL:FORWARD" needs also to be substituded with "FIREWALL:FORWARD ".

[Randy McMurchy]

Modified milestone from 6.4 to 6.5

[(none)]

Milestone 6.5 deleted

[Randy McMurchy]

Updated milestone to 6.7

[bdubbs@…]

Fixed at revision #9351. Sorry it took so long.

[bdubbs@…]

Milestone 6.7 deleted