| Summary: | Misconception in net-firewall/dynfw ipblock script | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tobias Klausmann (RETIRED) <klausman> |
| Component: | Vulnerabilities | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mr_bones_, pfeifer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
bug wranglers: no idea who's maintaining this package these days. adding mr_bones_ coz he's fix0red the ebuild, pfeifer coz he's leet with iptables no maintainer? Seems like it could be removed from portage if you ask me unless drobbins feels like picking it up again. I recommend firestarter for home firewalling needs. Tobias, I'd like to remove this package from portage -- I'll be putting into portage something called fwipsec, which *is* constantly maintained upstream. Unless you object strongly AND you want to maintain this package, please speak to me. I'm comfy with the package being deleted - I stumbled across it when browsing IBMs developer page and just had a peek. FWIW, I can re-code what I need for my own system. removed from portage. I have added net-firewall/fwipsec though, which is quite nice. |
The ipblock script from dynfw reads in part: #block outside IP address that's causing problems iptables $INSERT INPUT -s $1 -j DROP iptables $INSERT INPUT -p tcp -s $1 -j REJECT --reject-with tcp-reset iptables $INSERT OUTPUT -d $1 -j DROP iptables $INSERT OUTPUT -p tcp -d $1 -j REJECT --reject-with tcp-reset iptables $INSERT FORWARD -d $1 -j DROP iptables $INSERT FORWARD -p tcp -d $1 -j REJECT --reject-with tcp-reset echo "IP ${1} block ${2}." Now the lines 4 and 5 (those modifying the OUTPUT chain) cause a problem: They result in the TCP RST packets generated as a result of lines 2 and 3 to be discarded, resulting in the same behaviour as if the rules with the REJECT target weren't there. Consequently, the rules should be more precise, allowing TCP RST packets to said destination. I for one do not limit outgoing connections at all and have commented out lines 4 and 5, resulting in the desired behaviour. dynfw version: 1.0.1