Darren Reed wrote:

> In some mail from Jedi/Sector One, sie said:
> [...]
> > FTP/FXP stateful firewalling.
>
> Is FXP standardised yet? Client in OpenBSD ?
>
> > IRC stateful firewalling.
>
> Impossible to do securely. If you thought FTP was bad, wait until you
> checkout DCC.
>
> > SNMP stateful firewalling.
>
> Security Not My Problem...in other words, use the UDP port and stateful
> filtering with that, as it is generally a 1:1 send/receive protocol.
> Afterall, you should only have read communities enabled.
>
> > RPC stateful firewalling.
>
> Doable and not uncommon in business cases for firewalls.
>
> > Talk stateful firewalling.
>
> Extinct ?
>
> > TFTP stateful firewalling.
>
> Hmmm, maybe.
>
> > ARP packets filtering.
>
> Not something pf should care about.
>
> > Stealth matching (matches ports where no server is listening).
>
> This is meant to be a firewall, not some sort of hacker-bait-trap, right ?
>
> > Substring matching.
>
> Across packet boundaries or just within the packet ?
>
> > Eggdrop stateful firewalling.
>
> Get an IDS.
>
> > TOS mangling.
>
> Why ? Well, I can kinda understand "why" for this...
>
> > TTL mangling.
>
> Why ?
>
> > Per-MAC address filtering.
>
> Not a useful function for something which filters IP traffic.
>
> Use your bridge filtering for this or maybe convert that into some sort
> of generic layer-2 filtering which could concievably handle a backend
> that does ATM filtering (for example).
>
> > IP options stripping.
>
> If someone puts IP options in, they generally should be there.
> If you don't want packets with IP options on your network, block them.
>
> > Static 1:1 mapping.
>
> Took them long enough to catch up :)
>
> > Hosts pools.
>
> Depending on implementation, can be useful.
>
> > Very flexible filtering against packet states (invalid, established, new,
> > related, snat, dnat, expected status, remaining lifetime...)
>
> Just in case life wasn't complicated enough, lets go make it even more so
> and increase the liklihood of a security bug creeping in.
>
> > Matching against packet lenght and time.
>
> Length ?! Now being able to allow access to port 80 from 9am to 5pm is
> different, but you might want to use "other" methods for that since the
> kernel has no concept of what the current time of day is (it runs in GMT),
> not to mention DST transitions, etc.
>
> > Portscan match.
>
> Not something firewalls should be doing.
>
> > Network quotas.
>
> Look at how filesystem quotas work and tell me if you really think any
> sort of network quota should exist within the domain of pf.
>
> > Random match.
>
> For random security ?
>
> > Ability to send ICMP unreachable messages from fake IP addresses.
>
> So, did you just look at the list of 'features' in netfilter or did you
> go and do your own dreaming ?
>
> Linux isn't considered "one big hack" for nothing. More than half of the
> above items have no place in any sort of "firewall" interface and are more
> or less in netfilter/iptables because that's an easy and convienient place
> for it to get shoe-horned in rather than designed into the system proprely.
>
> Darren

Now I am confused....did someone mention IRC, TFTP, RPC, and Talk whilst in a
discussion about security? Surely not...maybe a security policy is what's
required here rather than a software update...

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]