stop accepting new connections on port 80

stop accepting new connections on port 80

[Spam User]

Hi,

I've been trying to figure out how to get iptables to stop accepting new 
connections on port 80 while letting the existing connections finish up 
what they're doing.

I thought it would be as easy as removing the rule that allows new 
connections and leaving the rule that allowed related and established 
connections, but when I remove the rule that allows new connections, all 
connections stop working.

I tried variations with the rule, like changing NEW to ESTABLISHED and the 
such, but no luck...

I was working on this during off hours when the web server only had maybe 
5 or 6 active connections, so I'm not sure if the connection tracking 
module is the problem or if its what I'm doing.  I know the following 
rules aren't the greatest, but we're behind a firewall and use host based 
firewalls as just another security measure.

This is all on stock RHEL4 kernels and packages - but I tested with gentoo 
on 2.6.13 and had the same issues.

hopefully I've included enough info to help you help me :)

Thanks,

Mike


####### script to edit iptables rules
#!/bin/bash
# stop accepting new connections..

# this is the default chain on the web servers.
chain="RH-Firewall-1-INPUT"

case $1 in
start)
    # umm, yeah, start to stop accepting new connections
    echo "removing iptables rule for new connections on port 80"
    line=`iptables -nL --line-numbers | awk '$10 ~ /dpt:80/ {print $1}'`
    iptables -D RH-Firewall-1-INPUT $line
;;

stop)
    # re-add deleted chain to accept new connections
    echo "now allowing connections"
    # inserting it on line 6 because thats where it is when iptables starts after a reboot
    iptables -I $chain 6 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
;;
esac

####### end script

#### system info
[root@www16 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
[root@www16 ~]# uname -a
Linux www16 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686 
i386 GNU/Linux

[root@www16 ~]# iptables -nL --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 255
3    ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:5666
9    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:161
10   REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited



[root@www16 ~]# iptables-save
# Generated by iptables-save v1.2.11 on Wed Dec  7 12:20:25 2005
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [10643556:3502431634]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT
-A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 161 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Wed Dec  7 12:20:25 2005

[root@www16 ~]# iptables --version
iptables v1.2.11

RE: stop accepting new connections on port 80

[Derick Anderson]

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org 
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Spam User
> Sent: Wednesday, December 07, 2005 3:39 PM
> To: netfilter@lists.netfilter.org
> Subject: stop accepting new connections on port 80
> 
> Hi,
> 
> I've been trying to figure out how to get iptables to stop 
> accepting new connections on port 80 while letting the 
> existing connections finish up what they're doing.
> 
> I thought it would be as easy as removing the rule that 
> allows new connections and leaving the rule that allowed 
> related and established connections, but when I remove the 
> rule that allows new connections, all connections stop working.

[snip]

I don't know exactly how you're determining the above: is it a long
download that gets killed? HTTP opens at least (and usually only) one
connection per page so the problem may be that the connection is already
closed even though the page is still being viewed. Unless you are
downloading something it's not likely your connection will last much
longer than four or five seconds on a heavily graphical page with
broadband. 

Your rules look ok at first glance so I would recommend some time with
Ethereal and a long download from the web server. Download a big file
once with your default rules and see what happens. Then delete the file
and download it again, this time running your kill-new-connections
script and see if the file transfer gets knocked immediately.
 
> Thanks,
> 
> Mike

Derick Anderson

RE: stop accepting new connections on port 80

[Spam User]

On Wed, 7 Dec 2005, Derick Anderson wrote:

>
>> -----Original Message-----
>> From: netfilter-bounces@lists.netfilter.org
>> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Spam User
>> Sent: Wednesday, December 07, 2005 3:39 PM
>> To: netfilter@lists.netfilter.org
>> Subject: stop accepting new connections on port 80
>>
>> Hi,
>>
>> I've been trying to figure out how to get iptables to stop
>> accepting new connections on port 80 while letting the
>> existing connections finish up what they're doing.
>>
>> I thought it would be as easy as removing the rule that
>> allows new connections and leaving the rule that allowed
>> related and established connections, but when I remove the
>> rule that allows new connections, all connections stop working.
>
> [snip]
>
> I don't know exactly how you're determining the above: is it a long
> download that gets killed? HTTP opens at least (and usually only) one
> connection per page so the problem may be that the connection is already
> closed even though the page is still being viewed. Unless you are
> downloading something it's not likely your connection will last much
> longer than four or five seconds on a heavily graphical page with
> broadband.


I had sort of thought about this, but then I thought thats what the 
related and established rules took care of.

I suppose it it would be more helpful if the end goal was known.. to be 
more specific, I should have included that we use PHP sessions and what 
I'd like to do is keep the session open until all the currently open PHP 
sessions are closed (serve active session, don't accept new connections).

I was hoping that the connection tracking would be associated to the 
sessions (not by session id or anything, but by the relationship of the 
established connections from the caller), so if user a looked at page X 
then 10 seconds later looked at page y, netfilter would know because that 
client had had established connections - I suppose I can see the flaws in 
that logic though.  I thought that the callers connection info being in a 
time_wait state would possibly mean something to iptables.

I know this isnt an apache/php list, but maybe thats where I should be 
headed?  Something like sending apache a usr1 signal, but instead of 
accepting new connections with the new config, just don't accept new 
connections until the daemon is restarted.

In any case, thanks for your speedy response.

>
> Your rules look ok at first glance so I would recommend some time with
> Ethereal and a long download from the web server. Download a big file
> once with your default rules and see what happens. Then delete the file
> and download it again, this time running your kill-new-connections
> script and see if the file transfer gets knocked immediately.
>
>> Thanks,
>>
>> Mike
>
> Derick Anderson
>
>

RE: stop accepting new connections on port 80

[Derick Anderson]

 

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org 
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Spam User
> Sent: Wednesday, December 07, 2005 5:18 PM
> To: netfilter@lists.netfilter.org
> Subject: RE: stop accepting new connections on port 80
> 
> >
> > I don't know exactly how you're determining the above: is it a long 
> > download that gets killed? HTTP opens at least (and usually 
> only) one 
> > connection per page so the problem may be that the connection is 
> > already closed even though the page is still being viewed. 
> Unless you 
> > are downloading something it's not likely your connection will last 
> > much longer than four or five seconds on a heavily 
> graphical page with 
> > broadband.
> 
> 
> I had sort of thought about this, but then I thought thats 
> what the related and established rules took care of.
> 
> I suppose it it would be more helpful if the end goal was 
> known.. to be more specific, I should have included that we 
> use PHP sessions and what I'd like to do is keep the session 
> open until all the currently open PHP sessions are closed 
> (serve active session, don't accept new connections).
> 
> I was hoping that the connection tracking would be associated 
> to the sessions (not by session id or anything, but by the 
> relationship of the established connections from the caller), 
> so if user a looked at page X then 10 seconds later looked at 
> page y, netfilter would know because that client had had 
> established connections - I suppose I can see the flaws in 
> that logic though.  I thought that the callers connection 
> info being in a time_wait state would possibly mean something 
> to iptables.

Not knowing exactly how conntrack determines when a connection is
closing, I don't think I can help with explaining that. However each
page load is a different TCP connection (and the client may use a
different source port) so it would make sense to me that conntrack would
process it that way.

> I know this isnt an apache/php list, but maybe thats where I 
> should be headed?  Something like sending apache a usr1 
> signal, but instead of accepting new connections with the new 
> config, just don't accept new connections until the daemon is 
> restarted.
> 
> In any case, thanks for your speedy response.
> 

If you can get your hands on the PHP, I'd start there. You could (a)
have PHP check for the existence of some flag file (say,
/var/.STOP_SESSIONs) and deny new sessions or (b) do that in the
database to cut down on I/O if you've got a busy server.

I don't know enough about the inner workings of Apache to suggest a
solution with that.

Derick Anderson 

Re: stop accepting new connections on port 80

[Bill Hance]

what about entering a new rule, immediately before the one saying

-dport 80 -m state --state NEW -j ACCEPT

the new one would be

-dport 80 -m state --state NEW -j DROP


that would drop the new connections before they got to the rule that
accepts them

and it shouldn't effect establish/related or connection tracking

  -Bill




> Hi,
>
> I've been trying to figure out how to get iptables to stop accepting new
> connections on port 80 while letting the existing connections finish up
> what they're doing.
>
> I thought it would be as easy as removing the rule that allows new
> connections and leaving the rule that allowed related and established
> connections, but when I remove the rule that allows new connections, all
> connections stop working.
>
> I tried variations with the rule, like changing NEW to ESTABLISHED and the
> such, but no luck...
>
> I was working on this during off hours when the web server only had maybe
> 5 or 6 active connections, so I'm not sure if the connection tracking
> module is the problem or if its what I'm doing.  I know the following
> rules aren't the greatest, but we're behind a firewall and use host based
> firewalls as just another security measure.
>
> This is all on stock RHEL4 kernels and packages - but I tested with gentoo
> on 2.6.13 and had the same issues.
>
> hopefully I've included enough info to help you help me :)
>
> Thanks,
>
> Mike
>
>
> ####### script to edit iptables rules
> #!/bin/bash
> # stop accepting new connections..
>
> # this is the default chain on the web servers.
> chain="RH-Firewall-1-INPUT"
>
> case $1 in
> start)
>     # umm, yeah, start to stop accepting new connections
>     echo "removing iptables rule for new connections on port 80"
>     line=`iptables -nL --line-numbers | awk '$10 ~ /dpt:80/ {print $1}'`
>     iptables -D RH-Firewall-1-INPUT $line
> ;;
>
> stop)
>     # re-add deleted chain to accept new connections
>     echo "now allowing connections"
>     # inserting it on line 6 because thats where it is when iptables
> starts after a reboot
>     iptables -I $chain 6 -p tcp -m state --state NEW -m tcp --dport 80 -j
> ACCEPT
> ;;
> esac
>
> ####### end script
>
> #### system info
> [root@www16 ~]# cat /etc/redhat-release
> Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
> [root@www16 ~]# uname -a
> Linux www16 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686
> i386 GNU/Linux
>
> [root@www16 ~]# iptables -nL --line-numbers
> Chain INPUT (policy ACCEPT)
> num  target     prot opt source               destination
> 1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
>
> Chain FORWARD (policy ACCEPT)
> num  target     prot opt source               destination
> 1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT)
> num  target     prot opt source               destination
>
> Chain RH-Firewall-1-INPUT (2 references)
> num  target     prot opt source               destination
> 1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> 2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp
> type 255
> 3    ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
> 4    ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
> 5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state
> RELATED,ESTABLISHED
> 6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
> NEW tcp dpt:80
> 7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
> NEW tcp dpt:22
> 8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
> NEW tcp dpt:5666
> 9    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state
> NEW udp dpt:161
> 10   REJECT     all  --  0.0.0.0/0            0.0.0.0/0
> reject-with icmp-host-prohibited
>
>
>
> [root@www16 ~]# iptables-save
> # Generated by iptables-save v1.2.11 on Wed Dec  7 12:20:25 2005
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [10643556:3502431634]
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> -A RH-Firewall-1-INPUT -i lo -j ACCEPT
> -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
> -A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT
> -A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT
> -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 5666 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 161 -j
> ACCEPT
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> COMMIT
> # Completed on Wed Dec  7 12:20:25 2005
>
> [root@www16 ~]# iptables --version
> iptables v1.2.11
>
>

Re: stop accepting new connections on port 80

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 9 Dec 2005, Bill Hance wrote:

> what about entering a new rule, immediately before the one saying
>
> -dport 80 -m state --state NEW -j ACCEPT
>
> the new one would be
>
> -dport 80 -m state --state NEW -j DROP
>
>
> that would drop the new connections before they got to the rule that
> accepts them
>
> and it shouldn't effect establish/related or connection tracking


Of course the question is then how does a connection become established in 
the first place....


I get the impression the only way to try and do what you are attemtping is 
to que to user space, do yer deterministic evaluations there on whether or 
not you have a full port 80 queue, and then deal with the new attempt to 
reach port 80 there, finally pushing it back from user space to the 
FW/iptables rules and such...other with more knowledge on the semantics of 
this can stepup to assist, but, you are not going to accomplish this with 
simple rule sets.

Thanks,

Ron DuFresne


>
>  -Bill
>
>
>
>
>> Hi,
>>
>> I've been trying to figure out how to get iptables to stop accepting new
>> connections on port 80 while letting the existing connections finish up
>> what they're doing.
>>
>> I thought it would be as easy as removing the rule that allows new
>> connections and leaving the rule that allowed related and established
>> connections, but when I remove the rule that allows new connections, all
>> connections stop working.
>>
>> I tried variations with the rule, like changing NEW to ESTABLISHED and the
>> such, but no luck...
>>
>> I was working on this during off hours when the web server only had maybe
>> 5 or 6 active connections, so I'm not sure if the connection tracking
>> module is the problem or if its what I'm doing.  I know the following
>> rules aren't the greatest, but we're behind a firewall and use host based
>> firewalls as just another security measure.
>>
>> This is all on stock RHEL4 kernels and packages - but I tested with gentoo
>> on 2.6.13 and had the same issues.
>>
>> hopefully I've included enough info to help you help me :)
>>
>> Thanks,
>>
>> Mike
>>
>>
>> ####### script to edit iptables rules
>> #!/bin/bash
>> # stop accepting new connections..
>>
>> # this is the default chain on the web servers.
>> chain="RH-Firewall-1-INPUT"
>>
>> case $1 in
>> start)
>>     # umm, yeah, start to stop accepting new connections
>>     echo "removing iptables rule for new connections on port 80"
>>     line=`iptables -nL --line-numbers | awk '$10 ~ /dpt:80/ {print $1}'`
>>     iptables -D RH-Firewall-1-INPUT $line
>> ;;
>>
>> stop)
>>     # re-add deleted chain to accept new connections
>>     echo "now allowing connections"
>>     # inserting it on line 6 because thats where it is when iptables
>> starts after a reboot
>>     iptables -I $chain 6 -p tcp -m state --state NEW -m tcp --dport 80 -j
>> ACCEPT
>> ;;
>> esac
>>
>> ####### end script
>>
>> #### system info
>> [root@www16 ~]# cat /etc/redhat-release
>> Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
>> [root@www16 ~]# uname -a
>> Linux www16 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686
>> i386 GNU/Linux
>>
>> [root@www16 ~]# iptables -nL --line-numbers
>> Chain INPUT (policy ACCEPT)
>> num  target     prot opt source               destination
>> 1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
>>
>> Chain FORWARD (policy ACCEPT)
>> num  target     prot opt source               destination
>> 1    RH-Firewall-1-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
>>
>> Chain OUTPUT (policy ACCEPT)
>> num  target     prot opt source               destination
>>
>> Chain RH-Firewall-1-INPUT (2 references)
>> num  target     prot opt source               destination
>> 1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>> 2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp
>> type 255
>> 3    ACCEPT     esp  --  0.0.0.0/0            0.0.0.0/0
>> 4    ACCEPT     ah   --  0.0.0.0/0            0.0.0.0/0
>> 5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state
>> RELATED,ESTABLISHED
>> 6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
>> NEW tcp dpt:80
>> 7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
>> NEW tcp dpt:22
>> 8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state
>> NEW tcp dpt:5666
>> 9    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state
>> NEW udp dpt:161
>> 10   REJECT     all  --  0.0.0.0/0            0.0.0.0/0
>> reject-with icmp-host-prohibited
>>
>>
>>
>> [root@www16 ~]# iptables-save
>> # Generated by iptables-save v1.2.11 on Wed Dec  7 12:20:25 2005
>> *filter
>> :INPUT ACCEPT [0:0]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [10643556:3502431634]
>> :RH-Firewall-1-INPUT - [0:0]
>> -A INPUT -j RH-Firewall-1-INPUT
>> -A FORWARD -j RH-Firewall-1-INPUT
>> -A RH-Firewall-1-INPUT -i lo -j ACCEPT
>> -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT
>> -A RH-Firewall-1-INPUT -p ipv6-crypt -j ACCEPT
>> -A RH-Firewall-1-INPUT -p ipv6-auth -j ACCEPT
>> -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j
>> ACCEPT
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j
>> ACCEPT
>> -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 5666 -j
>> ACCEPT
>> -A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 161 -j
>> ACCEPT
>> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
>> COMMIT
>> # Completed on Wed Dec  7 12:20:25 2005
>>
>> [root@www16 ~]# iptables --version
>> iptables v1.2.11
>>
>>
>
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDmdYWst+vzJSwZikRAoe3AJ4+XsxsQAJsEOjno8GzmACnMjFT1gCgiyfv
DQFvnWRuxP32E11WWHk9+Zw=
=Bi7W
-----END PGP SIGNATURE-----

Re: stop accepting new connections on port 80

[Nick Drage]

On Wed, Dec 07, 2005 at 12:38:51 -0800, Spam User wrote:

> I've been trying to figure out how to get iptables to stop accepting
> new connections on port 80 while letting the existing connections
> finish up what they're doing.
> 
> I thought it would be as easy as removing the rule that allows new
> connections and leaving the rule that allowed related and established
> connections, but when I remove the rule that allows new connections,
> all connections stop working.

When you say "all connections", what do you mean?

Do you mean TCP connections, or browsing sessions?  I've never really
looked at it in detail but I'm wondering if you're expecting HTTP
sessions to stay up while someone views a site, whereas *IIRC* while a
user web-browses numerous separate HTTP connections are opened and
closed in quick succession.  Therefore as soon as you stop accepting new
TCP connections all web browsing will stop, even for people with a
half-loaded page.

Why do you want to stop new sessions?  If we take a step back [1] maybe
there's a different solution to your overall problem.

[1] "take a step back"... sorry, next thing you know we'll be running
ideas up the flagpole.

-- 
morals are for little people
Jenny Solzer

Re: stop accepting new connections on port 80

[Jan Engelhardt]

>what about entering a new rule, immediately before the one saying
>
>-dport 80 -m state --state NEW -j ACCEPT
>
>the new one would be
>
>-dport 80 -m state --state NEW -j DROP

-j REJECT is preferred here, otherwise users wait almost forever.
I have used it in the past and works fine (i.e. lets established ones go 
on)


Jan Engelhardt
--