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 +0000, 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, 2004-11-05 at 12:49, Jan Minar wrote: > On Fri, Nov 05, 2004 at 11:29:21AM +0000, 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, 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 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 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 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.
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: howto get pptpd with mppe to run ?
You need to also have a patched pppd program, this requires an additional patch which is to the best of my knowledge is not packaged in Debian. There is a new version of pppd in the works that has MPPE support included, but it's unreleased yet. Hopefully when it gets released the kernel patches it provides will be added to the Debian kernel by default so that users will have one less to go through. Baruch * Matthias Krauss <[EMAIL PROTECTED]> [030103 23:38]: > Hello list, > i got in stuck while trying to get pptpd 1.1.0-1 with the mppe > compression/encryption to run. > > I used the debian kernel sources 2.4.18 and patched it with the unstable > kernel-patch-mppe 1.2-1 fine so far and then made the kernel compile also > fine. > According to the logs the ppp_mppe mod registers fine, after a test conx i > see > in the logs pptp reports unknown options mppe-128 or mppe-40, then when i > try rmmod ppp_mppe and modprobe ppp_mppe again i get "No License" but the > mod was > loaded anyway. > > A testconx with simple chap proto works ok. > > Any ideas ??? > > Matthias -- Baruch Even http://baruch.ev-en.org/ http://www.nongnu.org/chktex/
Re: howto get pptpd with mppe to run ?
You need to also have a patched pppd program, this requires an additional patch which is to the best of my knowledge is not packaged in Debian. There is a new version of pppd in the works that has MPPE support included, but it's unreleased yet. Hopefully when it gets released the kernel patches it provides will be added to the Debian kernel by default so that users will have one less to go through. Baruch * Matthias Krauss <[EMAIL PROTECTED]> [030103 23:38]: > Hello list, > i got in stuck while trying to get pptpd 1.1.0-1 with the mppe > compression/encryption to run. > > I used the debian kernel sources 2.4.18 and patched it with the unstable > kernel-patch-mppe 1.2-1 fine so far and then made the kernel compile also > fine. > According to the logs the ppp_mppe mod registers fine, after a test conx i > see > in the logs pptp reports unknown options mppe-128 or mppe-40, then when i > try rmmod ppp_mppe and modprobe ppp_mppe again i get "No License" but the > mod was > loaded anyway. > > A testconx with simple chap proto works ok. > > Any ideas ??? > > Matthias -- Baruch Even http://baruch.ev-en.org/ http://www.nongnu.org/chktex/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
