Do I need a firewall rule for RST ?

In /var/log/messages, I often find packages that have been rejected because of the following rules:

$IPTABLES -A FORWARD -m multiport -p tcp -i ppp0 --sports $TCPOUT\
	-j ACCEPT --tcp-flags ACK ACK

$IPTABLES -A FORWARD -m multiport -p tcp -o ppp0 --dports $TCPOUT\
-j ACCEPT

In short, what I want to achieve is that incoming traffic should always have the ACK-bit set.

Packets that are rejected most often are packets that have the RST-flag set:

Jul  9 14:08:58 jhh kernel: IN=ppp0 OUT=eth0 SRC=145.58.30.9 DST=192.168.0.1 
LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=32896 PROTO=TCP SPT=80 DPT=1068 WINDOW=0 
RES=0x00 RST URGP=0
Jul  9 14:08:59 jhh kernel: IN=ppp0 OUT=eth0 SRC=145.58.30.9 DST=192.168.0.1 
LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=33682 PROTO=TCP SPT=80 DPT=1068 WINDOW=0 
RES=0x00 RST URGP=0
Jul  9 14:09:01 jhh kernel: IN=ppp0 OUT=eth0 SRC=145.58.30.9 DST=192.168.0.1 

LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=35186 PROTO=TCP SPT=80 DPT=1068 WINDOW=0 RES=0x00 RST URGP=0

Questions:

1) AFAIK these packets are harmless, correct? Or could some of them be used in attacks?

2) (Assuming they are harmless:) is it safe then to add a rule:

$IPTABLES -A FORWARD -m multiport -p tcp -i ppp0 --sports $TCPOUT\
	-j ACCEPT --tcp-flags RST RST

3) Is there perhaps a better way to deal with these kinds of packets? Perhaps i should better use "state" and forget about the flags?

Jan Humme.

Someone can send you these packets to tear down your established tcp sessions. Not that it's easy to do but feasible.

Yes. I'd do this. However it doesn't protect you from the case mentioned above. The only solution for that is using IPsec. But then again you cannot run IPsec for all your traffic...

Ramin