Re: TCP SYN packets which have the FIN flag set.
TCP SYN The device does not seem to discard TCP SYN packets which have the FIN flag set. This security flaw may allow an attacker to bypass firewall rules. Risk Implication This device should be configured to discard TCP SYN packets which have the FIN flag set. RecommendationThis device should be configured to discard TCP SYN packets which have the FIN flag set Comment configurer le device to discard TCP SYN sur HP-UX ??? Merci de votre aide
Re: TCP SYN packets which have the FIN flag set.
On Mon, Nov 08, 2004 at 09:36:43AM +0100, Giacomo Mulas wrote: On Fri, 5 Nov 2004, George Georgalis wrote: and for anybody who is interested, I've found the limit function works well to manage logging and types of deny. -m limit --limit-burst 50 --limit 1/s At the end of my NEW ACCEPT set, I call a chain that, within the limit, logs and rejects remaining connections, beyond the limit it returns. the next two rules log some (with limit again) of the remaining connections and drops them all. The setup gives a balance between the problems of logging and rejecting everything bad and just dropping everything bad. Doesn't that open the possibility for a DOS, simply by sending a stream of new attempted connections to your computers? Then this would continuously saturate the rate of new attempted connections, and your legitimate connections would be virtually impossible. Or is the netfilter limit code as smart as to use separate limits to separate source IP numbers? Unfortunately the limit function doesn't easily apply to specific ip addresses (I think there is a way to do it but it's not easy and I don't know how). and a stream of new connections will dos me. :) Maybe I wasn't clear, I don't limit good connections. (though it might be a good idea to limit port 80 to a rate my apache can sustain, otherwise route to a lightweight httpd that responds with try again later). I'm using limit for REJECT of bad connections when they connect, when the limit is reached I stop rejecting the bad ones and just DROP them. for logging, I log the rejected ones but only some of the dropped ones. REJECT means I respond, DROP means the client may continue to try until it times out, So generally there is less bandwidth with REJECT, unless you are being attacked, then there is less with DROP. and for certain abusive subnets I request that they be dropped (or whatever) at my ISP router. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Thu, 2004-11-04 at 17:48, Luis Pérez Meliá wrote: I'm using iptables. In my rules I have this: . . . iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You are not only blocking illegal flag combinations, you are also blocking perfectly legal ones! And then spreading this bad configuration. There are flags in the TCP that we want to be allowed on start of connections, specifically ECN flags, you can look at http://www.icir.org/floyd/ecnProblems.html Note that you will not be able to receive mails from the LKML with such a setup since LKML server uses ECN. You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Thu, 2004-11-04 at 18:41, martin f krafft wrote: also sprach Luis Pérez Meliá [EMAIL PROTECTED] [2004.11.04.1848 +0100]: iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
* Jan Minar: Is this a serious problem? Maybe. It is a very serious bug. Actually, it's a feature because some TCP extensions use SYN+FIN (TCP for Transactions or something like that). The real, nasty bug was in stacks that accepted SYN+RST as a regular SYN, easily passing through to quite a few stateless packet filters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 11:29:21AM +, Baruch Even wrote: On Thu, 2004-11-04 at 18:41, martin f krafft wrote: also sprach Luis Prez Meli [EMAIL PROTECTED] [2004.11.04.1848 +0100]: iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Serious documentation bug. Just count the number of sites that give wrong examples. Patch against woody's iptables: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8 Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to Please comment. -- Jan pgpa5lBfTvuXG.pgp Description: PGP signature
Re: TCP SYN packets which have the FIN flag set.
Hi! On Friday 05 November 2004 12:27, Baruch Even wrote: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Shouldn't iptables -A INPUT -m state --state INVALID -j DROP as the _first_ rule take care of all packages with illegal flags? Unfortunately, I haven't found any documentation what exactly is considered INVALID. Anybody? Cheers, Stefan -- Technische Universitaet Muenchen Raum: 1131 Physik-Department T39 Tel.: 089/289-12197 James-Franck-Strasse E-Mail: [EMAIL PROTECTED] D-85748 Garching -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
Please do not CC me on list replies. It's in the header, it's in my signature, it's in the list policy. also sprach Baruch Even [EMAIL PROTECTED] [2004.11.05.1229 +0100]: This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Why do you care about the connection being NEW? I am not challenging, I just can't figure out an attack scenario that could exploit the fact that I only check for --syn. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. You say to use RST,ACK,FIN,SYN SYN which makes sense. If you use --syn and iptables-save, RST,ACK,SYN SYN is stored, so this is what --syn seems to mean. Why does --syn not set FIN in the mask? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 12:03, Florian Weimer wrote: * Jan Minar: Is this a serious problem? Maybe. It is a very serious bug. Actually, it's a feature because some TCP extensions use SYN+FIN (TCP for Transactions or something like that). TTCP is a dead proposal, it brings into TCP the IP spoofing problems of UDP, if you want to speed TCP startup time just send the data with the third packet. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 14:27, martin f krafft wrote: also sprach Baruch Even [EMAIL PROTECTED] [2004.11.05.1229 +0100]: This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Why do you care about the connection being NEW? I am not challenging, I just can't figure out an attack scenario that could exploit the fact that I only check for --syn. You have three categories into which all sessions go: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. If you don't check for NEW, a SYN packet which is INVALID for some connection can be accepted. If you check for INVALID before you check for SYN you're covered. A former e-mail of mine explains why the --tcp-flags ALL SYN check is a bad idea. You say to use RST,ACK,FIN,SYN SYN which makes sense. If you use --syn and iptables-save, RST,ACK,SYN SYN is stored, so this is what --syn seems to mean. Why does --syn not set FIN in the mask? Because of ideas like TTCP (as mentioned before in this thread), for the exact reasons you'll have to ask the netfilter team, I developed a firewall but it wasn't netfilter. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 13:06, Stefan Fritsch wrote: Hi! On Friday 05 November 2004 12:27, Baruch Even wrote: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Please dont do that! You can use SYN,ACK,FIN,RST SYN to check for illegal flags. Shouldn't iptables -A INPUT -m state --state INVALID -j DROP as the _first_ rule take care of all packages with illegal flags? Unfortunately, I haven't found any documentation what exactly is considered INVALID. Anybody? I started to read the netfilter source to be sure but it's too much work so take this answer with a grain of salt. As far as I know the INVALID bit will be flagged if a packet matched a connection but is invalid in the connection context, a SYN packet for an established connection or a packet without an ACK in the established connection. Things like that. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 12:49, Jan Minar wrote: On Fri, Nov 05, 2004 at 11:29:21AM +, Baruch Even wrote: On Thu, 2004-11-04 at 18:41, martin f krafft wrote: What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. This comes from the fact that the NEW state of Netfilter only means that this is the first time this connection is seen by the firewall. What you really want is the connection to be NEW and a valid connection opening, so you check the SYN flag too. Serious documentation bug. Just count the number of sites that give wrong examples. Patch against woody's iptables: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to I disagree with this description, the --state NEW case should be described for what it is, there should be no expectation of a validity check for it, but the ESTABLISHED and RELATED cases do check for validity. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) I'm thinking PREROUTING is the best table (covers localhost, nat and bridge connections); but historically I've used it on INPUT. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, 2004-11-05 at 17:13, George Georgalis wrote: On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) If you checked INVALID and ESTABLISHED, the rest has to be NEW. You can check it if you want for completeness, you can avoid checking it to save a few bits compared. Baruch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: On Fri, 2004-11-05 at 14:27, martin f krafft wrote: You have three categories into which all sessions go: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. If you don't check for NEW, a SYN packet which is INVALID for some connection can be accepted. If you check for INVALID before you check for SYN you're covered. Here again, at least the manpage seems to be misleading. Quoting the iptables(8) manpage from woody: Possible states are INVALID meaning that the packet is associated with no known connection, [...] NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions At least one of INVALID and NEW definitions is invalid. If the NEW was to match INVALID packets, these packets will be by definition ``associated with no known connection'', and vice versa. -- Jan pgpbANUptwNjH.pgp Description: PGP signature
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 05:57:18PM +, Baruch Even wrote: On Fri, 2004-11-05 at 17:13, George Georgalis wrote: On Fri, Nov 05, 2004 at 03:04:34PM +, Baruch Even wrote: ESTABLISHED,RELATED NEW INVALID pick two to cover the spectrum of attacks. Why not all three in this order... INVALID -j REJECT ESTABLISHED,RELATED -j ACCEPT NEW -j ACCEPT (if allowed) If you checked INVALID and ESTABLISHED, the rest has to be NEW. You can check it if you want for completeness, you can avoid checking it to save a few bits compared. performance isn't really an issue for me. but I do accept only certain new connections from certain networks. and for anybody who is interested, I've found the limit function works well to manage logging and types of deny. -m limit --limit-burst 50 --limit 1/s At the end of my NEW ACCEPT set, I call a chain that, within the limit, logs and rejects remaining connections, beyond the limit it returns. the next two rules log some (with limit again) of the remaining connections and drops them all. The setup gives a balance between the problems of logging and rejecting everything bad and just dropping everything bad. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
On Fri, Nov 05, 2004 at 03:10:00PM +, Baruch Even wrote: On Fri, 2004-11-05 at 12:49, Jan Minar wrote: --- iptables-1.2.6a.ORIG/iptables.8 Fri Nov 5 12:28:43 2004 +++ iptables-1.2.6a-local.0/iptables.8 Fri Nov 5 12:47:14 2004 @@ -521,7 +521,12 @@ supporting this feature) .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that no +.I validity +check is performed, so for example \fB--state NEW\fP will match SYN,FIN packets. +Some TCP stacks assign special meanings to such packets, and this actually might +be what you want. For a more stringent filtering, see the \fB--tcp-flags\fP and +\fB--syn\fP options.. .TP .BI --state state Where state is a comma separated list of the connection states to I disagree with this description, the --state NEW case should be described for what it is, there should be no expectation of a validity check for it, but the ESTABLISHED and RELATED cases do check for validity. The term INVALID is somewhat unfortunate, and the Woody's manpage really enforces the confusion. The wording of the NEW explanation is obviously misleading. The following should clean the mess: After some questions and answers on #iptables @ freenode, and some RTFMing, here goes the second version of the patch. It's against the iptables in Sarge. When the dust settles, it should be backported to Woody, as usually. The problem with the conntrack mechanism vs. flagwise filtering maybe requires someone who understands the inner workings. --- iptables.8.ORIG 2004-11-05 23:16:40.0 +0100 +++ iptables.8 2004-11-06 00:25:53.0 +0100 @@ -470,7 +470,10 @@ .B RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, -or an ICMP error. +or an ICMP error. If you want to track complex application layer +protocols such as FTP, IRC, or SNMP-ALG, you will need a protocol +helper, either compiled in the kernel, or as a module. Without one, +tracking RELATED packets will not work fully (or even at all). .B SNAT A virtual state, matching if the original source address differs from the reply destination. @@ -831,7 +834,11 @@ Matches a given realm number (and optionally mask). .SS state This module, when combined with connection tracking, allows access to -the connection tracking state for this packet. +the connection tracking state for this packet. Note that the tracking isn't +\ XXX ``isn't really stateful'' -- so what *is* it? +really stateful. If you need real stateful filtering that requires correct +connection initiation and tracks sequence numbers, you may want to apply the +tcp-window-tracking patch from patch-o-matic. .TP .BI --state state Where state is a comma separated list of the connection states to @@ -834,21 +841,44 @@ .B INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any -known connection, +known connection. Note that malformed packets not necessarily are INVALID. +In particular, non-compliant combination of TCP flags does not make that +particular packet INVALID. (The term INVALID is somewhat unfortunate.) +See \fB--tcp-flags\fR if you need to match packets according to their TCP +flags. Note however, that because of the intrinsic limitations of the +connection tracking mechanism, flagwise filtering in combination with this +module may result in dropping legitimate connections prematurely, +\ +\ This is what I'm ^^talking^^ about: +\ +\ iptables -A INPUT -p tcp ! --tcp-flags SYN SYN,ACK,RST -m state --state \ +\ NEW -j DROP +\ +\ Note that doing this will prevent idle sessions from continuing once they +\ have expired from the conntrack table. In the normal relaxed view such +\ connections initiated from the correct direction (i.e. the direction you +\ allow NEW packets through) can normally continue even if expired from +\ conntrack, provided that the first data/ack packet that resumes the +\ connection comes from the correct direction. +\ +\ Shamelessly stolen on 2004-11-05 from: +\ http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html .B ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, +\ XXX When exactly is a connection ESTABLISHED? .B NEW -meaning that the packet has started a new connection, or otherwise -associated with a connection which has not seen packets in both +meaning that the packet is attempting to start a new connection, or is +otherwise associated with a connection which has not seen packets in both directions, and + .B RELATED -meaning that the packet is starting a new connection, but is +meaning that the packet is attempting to start a new connection, but is associated with an existing
Re: TCP SYN packets which have the FIN flag set.
Please don't use HTML. On Wed, Nov 03, 2004 at 06:35:58PM +0100, Luis Prez Meli wrote: Is this a serious problem? Maybe. It is a very serious bug. Test ID:11618 View Source Category:Firewalls Title:Remote host replies to SYN+FIN Summary:Sends a SYN+FIN packet and expects a SYN+ACK Description: The remote host does not discard TCP SYN packets which have the FIN flag set. google/wikipedia will tell you what TCP SYN packets are, and why it's so important to filter them on the firewall. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. So, which firewall are You using? -- Jan pgpEwRN7Ydc1F.pgp Description: PGP signature
Re: TCP SYN packets which have the FIN flag set.
The FIN flag indicates that the host that sends it is ready to drop the connection, but a SYN flag indicates that the host is ready to start a connection. Having both set is bad because a cracker can use this to sneak packets through a firewall that does not block them. If you are using IPTables, then you would filter using the TCP Flags option, and drop the packets. I recommend some reading over at http://iptables-tutorial.frozentux.net/ There is a lot of good stuff over there including info on TCP Connections, and the handshake process, which is vital in setting up a Good firewall, IMHO, anyway. --- Luis P�rez Meli� [EMAIL PROTECTED] wrote: Is this a serious problem? When I pass Nessus: Test ID:11618 View Source Category:Firewalls Title:Remote host replies to SYN+FIN Summary:Sends a SYN+FIN packet and expects a SYN+ACK Description: The remote host does not discard TCP SYN packets which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. See also : http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html http://www.kb.cert.org/vuls/id/464113 Solution : Contact your vendor for a patch Risk factor : Medium Cross-Ref:BugTraq ID: 7487 Thanks, -- .''`. Luis P�rez Meli� : :' : `. `'` `- Debian GNU/Linux = -UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.-Dennis Ritchie __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
I'm using iptables. In my rules I have this: . . . iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT Thanks for the web: http://iptables-tutorial.frozentux.net El jue, 04-11-2004 a las 12:14, Jan Minar escribió: Please don't use HTML. Sorry! On Wed, Nov 03, 2004 at 06:35:58PM +0100, Luis Pérez Meliá wrote: Is this a serious problem? Maybe. It is a very serious bug. Test ID:11618 View Source Category:Firewalls Title:Remote host replies to SYN+FIN Summary:Sends a SYN+FIN packet and expects a SYN+ACK Description: The remote host does not discard TCP SYN packets which have the FIN flag set. google/wikipedia will tell you what TCP SYN packets are, and why it's so important to filter them on the firewall. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. So, which firewall are You using? -- .''`. Luis Pérez Meliá : :' : `. `'` `- Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TCP SYN packets which have the FIN flag set.
also sprach Luis Pérez Meliá [EMAIL PROTECTED] [2004.11.04.1848 +0100]: iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT What's the point of matching state NEW *and* SYN packets? Just SYN packets should suffice. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: TCP SYN packets which have the FIN flag set.
On Thu, Nov 04, 2004 at 06:48:29PM +0100, Luis Prez Meli wrote: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Doesn't match any packets which have the SYN flag set. iptables -A INPUT -m state --state NEW -p tcp --tcp-flags ALL SYN -j ACCEPT ^ Matches SYN packets which have all the other flags unset. So no problem here. The packet filtering code in kernels 2.4.x 2.6.x should not exhibit the behavior Nessus found, unless badly configured. In other words, the problem might lay somewhere in Your iptables configuration/scripts. Using some higher-level firewall configuration utility might be an option? You may want to run Nessus with greater verbosity enabled, if that's possible, and/or use tcpdump(8) to discover what's really going on the wire. Ethereal seems to be quite a good tool if You're not that proficient in TCP/IP and the rather cryptic tcpdump output. HTH, -- Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
TCP SYN packets which have the FIN flag set.
Is this a serious problem? When I pass Nessus: Test ID:11618View Source Category:Firewalls Title:Remote host replies to SYN+FIN Summary:Sends a SYN+FIN packet and expects a SYN+ACK Description: The remote host does not discard TCP SYN packets which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. See also : http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html http://www.kb.cert.org/vuls/id/464113 Solution : Contact your vendor for a patch Risk factor : Medium Cross-Ref:BugTraq ID: 7487 Thanks, -- .''`. Luis Prez Meli : :' : `. `'` `- Debian GNU/Linux
TCP SYN packets which have the FIN flag set.
Is this a serious problem? When I pass Nessus: Test ID:11618View Source Category:Firewalls Title:Remote host replies to SYN+FIN Summary:Sends a SYN+FIN packet and expects a SYN+ACK Description: The remote host does not discard TCP SYN packets which have the FIN flag set. Depending on the kind of firewall you are using, an attacker may use this flaw to bypass its rules. See also : http://archives.neohapsis.com/archives/bugtraq/2002-10/0266.html http://www.kb.cert.org/vuls/id/464113 Solution : Contact your vendor for a patch Risk factor : Medium Cross-Ref:BugTraq ID: 7487 Thanks, -- .''`. Luis Prez Meli : :' : `. `'` `- Debian GNU/Linux
