iptables: "stateful inspection?"

iptables: "stateful inspection?"

[Michael Rothwell]

IPChains is essentially useless as a firewall due to its lack of
stateful packet filering. Will the IPTables code in 2.4 maintain
connection state?

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael H. Warfield]

On Wed, Dec 20, 2000 at 11:18:10AM -0500, Michael Rothwell wrote:
> IPChains is essentially useless as a firewall due to its lack of

	I think that's more than a little overstatement on your
part.  It depends entirely on the application you intend to put
it to.  It may be entirely useless TO YOU and your applications,
but your statement is far to broad to be accurate.

> stateful packet filering. Will the IPTables code in 2.4 maintain
> connection state?

	Yes it does.  It's clearly stated in all the documentation
on netfilter and in it's design.  Read the fine manual (or web site)
and you would have uncovered this (or been run over by it) for yourself.

	http://netfilter.filewatcher.org/

> -M

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael Rothwell]

"Michael H. Warfield" wrote:
>         I think that's more than a little overstatement on your
> part.  It depends entirely on the application you intend to put
> it to.  

Fine. How do I make FTP work through it? How can I allow all outgoing
TCP connections without opening the network to inbound connections on
the ports of desired services?

>         Yes it does.  It's clearly stated in all the documentation
> on netfilter and in it's design.  Read the fine manual (or web site)
> and you would have uncovered this (or been run over by it) for yourself.
> 
>         http://netfilter.filewatcher.org/

Thanks.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[David Lang]

On Wed, 20 Dec 2000, Michael Rothwell wrote:

> Date: Wed, 20 Dec 2000 11:30:15 -0500
> From: Michael Rothwell <rothwell@holly-springs.nc.us>
> To: Michael H. Warfield <mhw@wittsend.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: iptables: "stateful inspection?"
>
> "Michael H. Warfield" wrote:
> >         I think that's more than a little overstatement on your
> > part.  It depends entirely on the application you intend to put
> > it to.
>
> Fine. How do I make FTP work through it? How can I allow all outgoing
> TCP connections without opening the network to inbound connections on
> the ports of desired services?
>

for the issue of outbound TCP connections you can set ipchains filters
based on the Syn flag to prevent inbound connections.

for FTP I don't know off the top of my head how to do it when not
masquerading, when NAT is turned on load the FTP masq helper module and it
will allow you to do ftp out with no problems.

the real point that you need the stateful filtering is on UDP ports. for
that again I don't know any way when not doing NAT, but when NAT is
enabled it does do basic stateful filtering (but watch out for timeouts)

David Lang

> >         Yes it does.  It's clearly stated in all the documentation
> > on netfilter and in it's design.  Read the fine manual (or web site)
> > and you would have uncovered this (or been run over by it) for yourself.
> >
> >         http://netfilter.filewatcher.org/
>
> Thanks.
>
> -M
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael H. Warfield]

On Wed, Dec 20, 2000 at 08:51:34AM -0800, David Lang wrote:
> On Wed, 20 Dec 2000, Michael Rothwell wrote:

> > Date: Wed, 20 Dec 2000 11:30:15 -0500
> > From: Michael Rothwell <rothwell@holly-springs.nc.us>
> > To: Michael H. Warfield <mhw@wittsend.com>
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: iptables: "stateful inspection?"

> > "Michael H. Warfield" wrote:
> > >         I think that's more than a little overstatement on your
> > > part.  It depends entirely on the application you intend to put
> > > it to.

> > Fine. How do I make FTP work through it? How can I allow all outgoing
> > TCP connections without opening the network to inbound connections on
> > the ports of desired services?
> >

> for the issue of outbound TCP connections you can set ipchains filters
> based on the Syn flag to prevent inbound connections.

> for FTP I don't know off the top of my head how to do it when not
> masquerading, when NAT is turned on load the FTP masq helper module and it
> will allow you to do ftp out with no problems.

	You can use spf to add some stateful inspection for PORT mode
ftp.  Personally, I like the masquerading option better, though.

> the real point that you need the stateful filtering is on UDP ports. for
> that again I don't know any way when not doing NAT, but when NAT is
> enabled it does do basic stateful filtering (but watch out for timeouts)

	Stateful filter also helps block FIN scans and other stealth
scans, as well as some other esoteric attacks (fragmentation attacks,
Ping'O Death, etc...).  There are other ways to deal with those attacks
as well, but stateful filtering helps.  You also need it if you want to
take advantage of some ICMP as well.

	Big thing for me about NetFilter over IPChains, in addition to
statefull inspection, is the fact that we finally have an IPv6 aware
firewall now.  I've been chomping at the bit to get on IPv6 but
couldn't till I had working firewall code for that.

> David Lang

> > >         Yes it does.  It's clearly stated in all the documentation
> > > on netfilter and in it's design.  Read the fine manual (or web site)
> > > and you would have uncovered this (or been run over by it) for yourself.
> > >
> > >         http://netfilter.filewatcher.org/
> >
> > Thanks.
> >
> > -M

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael Rothwell]

"Michael H. Warfield" wrote:

>         You can use spf to add some stateful inspection for PORT mode
> ftp.  Personally, I like the masquerading option better, though.

Can you give an example of using MASQ selectively? I have real addresses
on both sides of the firewall, but want things like FTP to work
correctly. I think the IPChains HOWTOs are just a little terse. :)

Thanks!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael H. Warfield]

On Wed, Dec 20, 2000 at 12:52:27PM -0500, Michael Rothwell wrote:
> "Michael H. Warfield" wrote:

> >         You can use spf to add some stateful inspection for PORT mode
> > ftp.  Personally, I like the masquerading option better, though.

> Can you give an example of using MASQ selectively? I have real addresses
> on both sides of the firewall, but want things like FTP to work
> correctly. I think the IPChains HOWTOs are just a little terse. :)


	modprobe ip_masq_ftp
	ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21

	Seems to work for me (mine includes a "tag" and a policy route
rule to send it out my cable modem that I've left off here)...

	If you don't load the ip_masq_ftp module, you WILL get illegal
port errors on the PORT commands.

> Thanks!

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael H. Warfield]

Hello all!

On Wed, Dec 20, 2000 at 01:08:07PM -0500, Michael H. Warfield wrote:
> On Wed, Dec 20, 2000 at 12:52:27PM -0500, Michael Rothwell wrote:
> > "Michael H. Warfield" wrote:

> > >         You can use spf to add some stateful inspection for PORT mode
> > > ftp.  Personally, I like the masquerading option better, though.

> > Can you give an example of using MASQ selectively? I have real addresses
> > on both sides of the firewall, but want things like FTP to work
> > correctly. I think the IPChains HOWTOs are just a little terse. :)

	Michael Rothwell kindly pointed out to me in private mail that
I SCREWED UP (he didn't say that, I did) the copy-and-past on one of
the command lines and left out a "little detail"...

> 	modprobe ip_masq_ftp
> 	ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21

	This should have been:

	modprobe ip_masq_ftp
	ipchains -A forward -p tcp -s {Source Addresses} -d 0/0 21 -j MASQ

	DOH!  Sorry!

> 	Seems to work for me (mine includes a "tag" and a policy route
> rule to send it out my cable modem that I've left off here)...

> 	If you don't load the ip_masq_ftp module, you WILL get illegal
> port errors on the PORT commands.

> > Thanks!

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael H. Warfield]

On Wed, Dec 20, 2000 at 11:30:15AM -0500, Michael Rothwell wrote:
> "Michael H. Warfield" wrote:
> >         I think that's more than a little overstatement on your
> > part.  It depends entirely on the application you intend to put
> > it to.  

> Fine. How do I make FTP work through it? How can I allow all outgoing
> TCP connections without opening the network to inbound connections on
> the ports of desired services?

	Passive mode ftp works great for me.  You can also tack spf on
top of IPChains and get port mode working if that's really part of your
requirements.  If you really want to get sexy, you can use the MASQ
code to masquarade and handle the FTP for you.  Personally, I like
the MASQ trick better than using spf and enabling PORT mode.

	Policy routing helps out there as well where you want
to masquarade some services and let others pass untampered.  (Actually
you only REALLY need policy routing if you are also playing tricks
with the routing when you masquarade.)  I use policy routing anyways,
so I can route outbound ftp and http out a big fat unreliable broadband
pipe while protecting my static addresses through my nice reliable
ISDN channels.

	Your second question doesn't even seem to make sense to me.
Doesn't make sense as in either I don't understand your question or
the answer is so obvious if I do.  You allow outbound "SYN" packets
and block all (or only allow appropriate) inbound "SYN" packets (-y
option on the ipchains rules).  Or did I misunderstand your question?
In my case, inappropriate inbound SYN packets get portforwarded up to
Abacus PortSentry on the firewall to deal with port scanners.

	Yes, that setup still does allow people to do "FIN" scans and
other stealthy scans, but with Abacus PortSentry running in front of
everything and shutting down rogue sites that try to scan me that's
not a real great threat.  The IDS behind the firewall also fires off
if anyone tricky enough tries to stealth scan me WITHOUT an initial
SYN half scan or full scan (which would cut them off).

	Snort, behind the firewall, deals with the next layer of ankle
bitters that are just a little cut above the common riff raff that
try to port scan me.  Snort makes for yet another good adjunct to
both IPChains or NetFilter and PortSentry.  The combination is awesome
for frontend filtering and detection.  Anyone getting through that
without tripping an alarm is NOT an amateur and is worthy of my full,
undivided, PERSONAL attention (and I have custom detectors and surprises
for that level of "talent" as well).  :-)=)

	BTW...  Before anyone raises the customary remark about "What
about denial of service attacks by spoofing Abacus PortSentry"...
No one has documented an effective DoS attack against PortSentry
in the field.  It's just too difficult to do and too easy to protect
against.  My "evil twin" David LeBlanc (when he was still working with
me at Internet Security Systems a couple of years ago) tried it against
my PortSentry protected workstation.  He failed.  He knew everything
I had on that system including the PortSentry configuration and never
once managed to spoof so much as a single DoS attack that was effective.
If he couldn't do it with his level of talent and his knowledge of my
systems, it's going to take a world class talent who already knows my
entire setup to make that happen.  At that point, I have bigger problems
than worrying about PortSentry (and it's also a tip-off from PortSentry
that I need to be worried).  It would take a lot of effort and a lot of
incentive and a lot of access to make a real one happen.  If you have
all three of those, there are easier DoS attacks than attacking
PortSentry.  Lots of them that are LOTS easier.

> >         Yes it does.  It's clearly stated in all the documentation
> > on netfilter and in it's design.  Read the fine manual (or web site)
> > and you would have uncovered this (or been run over by it) for yourself.

> >         http://netfilter.filewatcher.org/

> Thanks.

	No problem.

> -M

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Alan Cox]

> "Michael H. Warfield" wrote:
> >         I think that's more than a little overstatement on your
> > part.  It depends entirely on the application you intend to put
> > it to.  
> 
> Fine. How do I make FTP work through it? How can I allow all outgoing

Passive mode or a proxy. 

> TCP connections without opening the network to inbound connections on
> the ports of desired services?

It does SYN checking. If you are running 'serious' security you wouldnt be
allowing outgoing connections anyway. One windows christmascard.exe virus that
connects back to an irc server to take input and you are hosed.

So its perfectly adequate for basic security, but if you want serious security
and you don't have passwords on outgoing connections think again. If you are
using ftp then be sure to also use other methods to verify a third party didnt
change the file you up/downloaded too.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael Rothwell]

Alan Cox wrote:

> It does SYN checking. If you are running 'serious' security you wouldnt be
> allowing outgoing connections anyway. One windows christmascard.exe virus that
> connects back to an irc server to take input and you are hosed.

Thankfully, pine and mutt are, to date, immune to that kind of thing. :)

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Dax Kelson]

Michael Rothwell said once upon a time (Wed, 20 Dec 2000):

> Alan Cox wrote:
>
> > It does SYN checking. If you are running 'serious' security you wouldnt be
> > allowing outgoing connections anyway. One windows christmascard.exe virus that
> > connects back to an irc server to take input and you are hosed.
>
> Thankfully, pine and mutt are, to date, immune to that kind of thing. :)

Try again.  Pine less than 4.30 has a buffer overflow builtin.  A properly
formated "From" header (or something) can hose you.  No need for any
attachment.

Dax

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Alan Cox]

> Alan Cox wrote:
> > It does SYN checking. If you are running 'serious' security you wouldnt be
> > allowing outgoing connections anyway. One windows christmascard.exe virus that
> > connects back to an irc server to take input and you are hosed.
> 
> Thankfully, pine and mutt are, to date, immune to that kind of thing. :)

There have been at least five holes found in pile that _could_ have been
exploited, and even one in all xterms pre X11R6 where ascii+escape codes
was all you needed.
Mutt has had minor things fixed for security reasons too.

It's harder. But you ignore two things - once someone does it anyone can
repeat it - and more importantly almost all exploits rely on user error.
Linux users are not always brighter than windows ones and there isnt a lot
you can do to make them smarter

Think of computer security like powertools. The day you think you are totally
safe is the day you end up hurt.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Laptop system clock slow after suspend to disk. (2.4.0-test9/hinote VP)

[Ian Stirling]

I've not noticed this on earlier kernel versions, is there something
silly I'm missing that's making my DEC hinote VP (p100 laptop)s 
system clock slow by a factor of five or so after resume?
Not the CPU or cmos clock, only the system clock.
Thoughts welcome.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Laptop system clock slow after suspend to disk. (2.4.0-test9/hinote VP)

[Keith Owens]

On Thu, 21 Dec 2000 02:26:12 +0000 (GMT), 
Ian Stirling <root@mauve.demon.co.uk> wrote:
>I've not noticed this on earlier kernel versions, is there something
>silly I'm missing that's making my DEC hinote VP (p100 laptop)s 
>system clock slow by a factor of five or so after resume?
>Not the CPU or cmos clock, only the system clock.

Try this.

Index: 0-test13-pre3.2/arch/i386/kernel/apm.c
--- 0-test13-pre3.2/arch/i386/kernel/apm.c Mon, 11 Dec 2000 09:23:40 +1100 kaos (linux-2.4/z/c/34_apm.c 1.1.1.7.2.5 644)
+++ 0-test13-pre3.2(w)/arch/i386/kernel/apm.c Fri, 22 Dec 2000 09:04:28 +1100 kaos (linux-2.4/z/c/34_apm.c 1.1.1.7.2.5 644)
@@ -262,6 +262,7 @@ extern int (*console_blank_hook)(int);
  * David Chen <chen@ctpa04.mit.edu>
  */
 #undef INIT_TIMER_AFTER_SUSPEND
+#define INIT_TIMER_AFTER_SUSPEND
 
 #ifdef INIT_TIMER_AFTER_SUSPEND
 #include <linux/timex.h>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael Rothwell]

Alan Cox wrote:

> There have been at least five holes found in pile that _could_ have been
> [speech]
> safe is the day you end up hurt.

Your specific example of an executable (windows) attachment, not buffer
overflows, etc. what what I was replying to. In general, you are
correct. Now, how about including that procfs cleanup patch that I sent,
and maybe the 64-bit printk patch? :)

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[George]

On Wed, 20 Dec 2000, Michael Rothwell wrote:

>"Michael H. Warfield" wrote:
>>         I think that's more than a little overstatement on your
>> part.  It depends entirely on the application you intend to put
>> it to.
>
>Fine. How do I make FTP work through it? How can I allow all outgoing
>TCP connections without opening the network to inbound connections on
>the ports of desired services?

/etc/sysctl.conf:
	# Set local port range to be higher.
	net.ipv4.ip_local_port_range = 32768 33792

/etc/ftpaccess:
	passive ports 0.0.0.0/0 32768 36863

Firewall script:
-----------------
STDPORT=32768:33792
IP=1.2.3.4/32

# Client FTP
ipchains -A output -j ACCEPT -p tcp -s $IP $STDPORT -d 0.0.0.0/0 ftp-data -y -l
ipchains -A output -j ACCEPT -p tcp -s $IP $STDPORT -d 0.0.0.0/0 ftp-data
ipchains -A output -j ACCEPT -p tcp -s $IP $STDPORT -d 0.0.0.0/0 ftp -y -l
ipchains -A output -j ACCEPT -p tcp -s $IP $STDPORT -d 0.0.0.0/0 ftp

# Server FTP
ipchains -A input -j ACCEPT -p tcp -s 0.0.0.0/0 ftp-data -d $IP $STDPORT # Needs SYN
ipchains -A input -j ACCEPT -p tcp -s 0.0.0.0/0 ftp -d $IP $STDPORT ! -y

[now deny all for all chains]

Unfortunately, any FTP server that doesn't use port 20 for data streams
won't work in Passive mode (oh well).  So I just download elsewhere first
and then get it locally for browsers that insist upon Passive.

For allowing outgoing connections without inbound, you'd use:

	ipchains -A input -j DENY -p tcp -y

or if that complains:

	ipchains -A input -j DENY -p tcp -s 0.0.0.0/0 -d $IP -y

You'll notice above I used '! -y' on the Server FTP rule.  If I missed a
detail, it might be due to trying to condense everything I have into what
you wanted.

-George Greer

(7,323 and 189 lines in my firewall rule script.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: iptables: "stateful inspection?"

[Michael Rothwell]

Felix von Leitner wrote:
> 
> > IPChains is essentially useless as a firewall due to its lack of
> > stateful packet filering.
> 
> Bullshit.
> Go back to the bowels or Redmond where you belong, luser.

Thanks. I appreciate that.

-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Laptop system clock slow after suspend to disk. (2.4.0-test9/hinote VP)

[Douglas Gilbert]

Ian Stirling <root@mauve.demon.co.uk> wrote:

> I've not noticed this on earlier kernel versions, is there something
> silly I'm missing that's making my DEC hinote VP (p100 laptop)s 
> system clock slow by a factor of five or so after resume?
> Not the CPU or cmos clock, only the system clock.
> Thoughts welcome.

I saw something like this on my thinkpad (RH6.2)
and it turned out to be connected to /etc/adjtime .
It was cured by changing the large numbers in
there to zeroes.

Could someone explain the mechanism?

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/