Lorenzo Martignoni <[EMAIL PROTECTED]> writes: close 336105 thanks
> * Jari Aalto <[EMAIL PROTECTED]>: > | > Package: shorewall | > Version: 2.4.5-1 | > Severity: important | > | > It appears that once a DNAT rule has been done, it persists even | > accross 'restart' or 'force-reload'. This is a serious security hole, | > because the old rules should not be there any more if chnages has been | > done to the /etc/shorewall/rules file. | > | > HOW TO REPRODUCE | > ================ | > | > Have A and B host in local network, access it from external host | > C. The connection happens to A, which forwards port 2222 to B's 22. | > | > C => ( A -> [2022:dnat:22] -> B ) | > | > a) initial settings in /etc/shorewall/rules | > | > ACCEPT net fw tcp 2022 | > DNAT net loc:192.168.1.2:22 tcp 2222 > ^^^^ > Why 2222 and not 2022? > | > - Connect to A, which should forward to B. | > - Complete login to B with ssh. | > | > b) change the above settings to following: | > | > ACCEPT net fw tcp 2222 | > DNAT net loc:192.168.1.2:22 tcp 2222 | > | > - Restart shorewall: /etc/init.d/shorewall restart | > - Connect to A, but *using* previous forward, port 2022. | > | > => You're forwarded to B. | > | > Confirm that the previous rule still exists: | > | > iptables -L | grep 2022 > > Hello, > > in cooperation with the upstream author we have tried to reproduce the > bug you reported but we weren't able to connect th the ssh server using > the old DNAT rules. > > Could you send me a copy of your /etc/shorewall/* of the two > configurations and the output of shorewall status with the old DNAT > rule and with the new one? Hi, I can't seem to reproduce it either. But when I reported the bug I tried it over an over and couldn't figure out why it kept remembering the connection. This may have to do with reboot; or solar flares to that matter. Consider this bug closed Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
