mobility and firewall

[Lance Lassetter]

On Sat, 2005-06-04 at 04:39 +0200, Ivan Krstic wrote:
> Lance Lassetter wrote:
> > Something as simple as this could help tremendously IMHO.
> 
> Please elaborate.
> 
> What is your threat model? The only thing that the ruleset you provide
> will do differently from a current Ubuntu install (without a firewall)
> is drop packets that are not part of known connections or that are
> malformed. In your threat model, what does this defend you against? How
> is defending against it helping security "tremendously"? How many of the
> last 1000 exploits published on BugTraq would you have stopped with this
> ruleset?
> 
> Having that ruleset in place would defend you against a set of extremely
> rare, obscure vulnerabilities while leaving you completely open to
> virtually every common exploit that you can find. You're trying to fit a
> square peg in a round hole: firewalls are a solution to a specific set
> of problems, and the ones you're trying to address do not seem to me to
> be in that set.
> 
> -IK
> 

I'll explain, to the best of my knowledge:

(1) iptables -P INPUT ACCEPT  
(2) iptables -P FORWARD DROP
(3) iptables -P OUTPUT ACCEPT
(4) iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
(5) iptables -A INPUT -m state --state INVALID -j DROP
(6) iptables -A INPUT -p tcp --syn -m state --state NEW -j ACCEPT 
(7) iptables -A INPUT -m limit -j LOG
(8) iptables -A INPUT -j DROP
(9) ...specifically DROP certain outgoing traffic known to have
problems?

(1) set incoming policy to accept for compatibility purposes.

(2) drop anything to be forwarded, prevents the computer from being a
hopping point to another machine by the malicious script/person.

(3) outgoing accept policy for compatibility purposes/ease of use.

(4) only accept packets that are from established and related
connections preventing incoming new connections that could be hostile.

(5) drop malformed packets?  yes, i've seen these type of attacks of
late, if this type rule applies.

(6) only accept new connections that are syn packets (this one could be
taken out i guess to prevent syn scans?) 

(7) log everything with a limit burst that gets in, up to this point.

(8) any traffic left over that doesn't meet this ruleset in INPUT
policy, drop. 

*(9) at this point possibly drop some specific outgoing protocol traffic
known to have vulnerabilities?

This is really simple and doesn't bind to any interface.  I've tried
some new connect nmap scans on something similar to this and it did seem
to help to have something like this in place.  Notice there are no
chains or the like, trying to keep it as simple as possible.

Lance(stuNNed)