* Query: iptables Conflict Policy Avoidance/Reduction
@ 2009-06-03 18:48 william fitzgerald
2009-06-04 12:13 ` Gáspár Lajos
0 siblings, 1 reply; 3+ messages in thread
From: william fitzgerald @ 2009-06-03 18:48 UTC (permalink / raw)
To: Mail List - Netfilter
Dear all,
Configuring a larger firewall policy is error prone. Rules can be redundant to
others, rules can be shadowed by proceeding rules whereby they are never activated
and so forth.
How do conflicts arise when the iptable rules use the NIC interface option.
Simple Redundancy example:
Internet ---> (eth1)Firewall ---> Web Server
Intranet ---> (eth0)
Firewall with two interfaces eth1 (Internet facing) and eth0 (Intranet LAN
facing), eth+ is the wildcard for both.
Rule 1: iptables -A FORWARD -i eth+ -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
Rule 2: iptables -A FORWARD -i eth+ -s 192.168.1.0/24 -d 192.168.1.2 --dport 80 -j
ACCEPT
In the above scenario, Rule 2 is REDUNDANT to Rule 1 in that, the source IP of
Rule 2 is covered by the source IP of Rule 1.
However, aren't these generic style rules not considered *best practice* given
that the above rules when applied to all interfaces could allow IP Spoofing of
reserved IP address range 192.168.1.0/24
So in order to avoid spoofing, one has to create the following two rules and apply
them to specific interfaces.
iptables -A FORWARD -i eth1 -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.1.0/24 -d 192.168.1.2 --dport 80 -j ACCEPT
Simple Shadowed example:
Internet ---> (eth1)Firewall ---> Web Server
Partner ---> (eth1) Firewall ---> VPN Server
Default Policy: iptables -P FORWARD DROP
Rule 1: iptables -A FORWARD -i eth1 -s 0/0 -d webIP --dport 80 -j ACCEPT
Rule 2: iptables -A FORWARD -i eth1 -s 0/0 -d vpnIP --dport 22 -j DROP
Rule 3: iptables -A FORWARD -i eth1 -s partnerIP -d vpnIP --dport 22 -j ACCEPT
Rule 2 blocks the intended partners access via Rule 3. A simple swap of rule 2 and
rule 3 prevents this. But why bother with Rule 2 in the first place, given the
default policy is DROP and so there is no way for anyone else other than the
partners to get access (Rule 3). Looking at various example policies on the web, I
find that there are explicitly defined DROP rules in conjunction with ACCEPT rules
like rules 2 and 3 above. Its as if, one does not trust the default policy.
I am just wondering, if all rules are applied to specific Interfaces, specific
destination IP address, specific destination ports and some trust in the default
policy would a lot of the possible policy conflicts be ruled out?
If anyone could provide me with some scenarios/examples to the contrary that would
be great.
It would even be better if I could get a hold of some real firewall policies
(anonymised internal IP ranges of course).
I have done some formal modelling on detecting conflicts with more complex
scenarios then above on an already defined policy.
But lately its dawning on me that formal synthesis or creation of rules *may*
completely rule out such conflicts. Of course the assumption is that you begin
with an empty rule-less policy.
For example (trivial scenario):
Using formal logic to generate iptables syntax based on the fact that its best
practice to allow both public and lan ip addresses access to the public web server.
Inface SrcIP SrcPort DstIP DstPort Target
eth1 anyIP >1024 webIP 80 Accept
eth0 lanIP >1024 webIP 80 Accept
Where the above is much better than:
SrcIP SrcPort DstIP DstPort Target
anyIP >1024 webIP 80 Accept
And where the above is much better than:
SrcIP SrcPort DstIP DstPort Target
anyIP >1024 dmz 80 Accept
It appears to me at least, that creating rules to be more specific than generic,
while it increases the number rules, is probably a better solution more likely to
be free of conflicts.
Again all feedback is welcome. Perhaps reality is not as black and white!
regards,
Will.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Query: iptables Conflict Policy Avoidance/Reduction
2009-06-03 18:48 Query: iptables Conflict Policy Avoidance/Reduction william fitzgerald
@ 2009-06-04 12:13 ` Gáspár Lajos
2009-06-04 16:11 ` william fitzgerald
0 siblings, 1 reply; 3+ messages in thread
From: Gáspár Lajos @ 2009-06-04 12:13 UTC (permalink / raw)
To: wfitzgerald; +Cc: Mail List - Netfilter
Hi Will.!
On Wed, 03 Jun 2009 19:48:06 +0100, william fitzgerald
<wfitzgerald@tssg.org> wrote:
> Dear all,
> Rule 1: iptables -A FORWARD -i eth+ -s 0/0 -d 192.168.1.2 --dport 80 -j
> ACCEPT
> Rule 2: iptables -A FORWARD -i eth+ -s 192.168.1.0/24 -d 192.168.1.2
> --dport 80 -j
> ACCEPT
>
> In the above scenario, Rule 2 is REDUNDANT to Rule 1 in that, the source
IP
> of
> Rule 2 is covered by the source IP of Rule 1.
Without any NAT-ing the firewall would never see such packets... (Sending
packets to the same subnet should not be routed.)
> However, aren't these generic style rules not considered *best practice*
> given
> that the above rules when applied to all interfaces could allow IP
Spoofing
> of
> reserved IP address range 192.168.1.0/24
IP Spoofing should be done by specifying ALLOWED LOCAL IP ranges (and drop
everything else) and specifying DISALLOWED REMOTE (private) IP ranges (and
accept everything else).
For example in RAW chain PREROUTING table:
$table -P $chain DROP
create_subchain PRE_PPP0
$table -A $chain -j $subchain -i $PPP0_IF -d $PPP0_IP
$table -A $subchain -j DROP -s 10.0.0.0/8 -m comment --comment
'PRIVATE USE' #RFC1918
$table -A $subchain -j DROP -s 14.0.0.0/8 -m comment --comment 'PUBLIC
DATA NETWORKS' #RFC1700, page 181
$table -A $subchain -j DROP -s 24.0.0.0/8 -m comment --comment 'CABLE
TELEVISION NETWORKS' #NOT SURE!!!
$table -A $subchain -j DROP -s 39.0.0.0/8 -m comment --comment
'RESERVED' #RFC1797
$table -A $subchain -j DROP -s 127.0.0.0/8 -m comment --comment
'LOOPBACK' #RFC1700, page 5
$table -A $subchain -j DROP -s 128.0.0.0/16 -m comment --comment
'RESERVED'
$table -A $subchain -j DROP -s 169.254.0.0/16 -m comment --comment
'LINK LOCAL'
$table -A $subchain -j DROP -s 172.16.0.0/12 -m comment --comment
'PRIVATE USE' #RFC1918
$table -A $subchain -j DROP -s 191.255.0.0/16 -m comment --comment
'RESERVED'
$table -A $subchain -j DROP -s 192.0.0.0/24 -m comment --comment
'RESERVED'
$table -A $subchain -j DROP -s 192.0.2.0/24 -m comment --comment
'RESERVED'
$table -A $subchain -j DROP -s 192.88.99.0/24 -m comment --comment
'6to4 RELAY ANYCAST' #RFC3068
$table -A $subchain -j DROP -s 192.168.0.0/16 -m comment --comment
'PRIVATE USE' #RFC1918
$table -A $subchain -j DROP -s 198.18.0.0/15 -m comment --comment
'NETWORK INTERCONNECT' #RFC2544
$table -A $subchain -j DROP -s 223.255.255.0/24 -m comment --comment
'RESERVED'
$table -A $subchain -j DROP -s 224.0.0.0/4 -m comment --comment
'MULTICAST' #RFC3171
$table -A $subchain -j DROP -s 240.0.0.0/4 -m comment --comment
'RESERVED' #RFC1700, page 4
...
$table -A $subchain -j ACCEPT
$table -A $chain -j ACCEPT -i $LAN_IF -s $LAN_NW
> So in order to avoid spoofing, one has to create the following two rules
> and apply
> them to specific interfaces.
> iptables -A FORWARD -i eth1 -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
> iptables -A FORWARD -i eth0 -s 192.168.1.0/24 -d 192.168.1.2 --dport 80
-j
> ACCEPT
>
>
> Simple Shadowed example:
>
> Internet ---> (eth1)Firewall ---> Web Server
> Partner ---> (eth1) Firewall ---> VPN Server
>
> Default Policy: iptables -P FORWARD DROP
> Rule 1: iptables -A FORWARD -i eth1 -s 0/0 -d webIP --dport 80 -j ACCEPT
> Rule 2: iptables -A FORWARD -i eth1 -s 0/0 -d vpnIP --dport 22 -j DROP
> Rule 3: iptables -A FORWARD -i eth1 -s partnerIP -d vpnIP --dport 22 -j
> ACCEPT
>
> Rule 2 blocks the intended partners access via Rule 3. A simple swap of
> rule 2 and
> rule 3 prevents this. But why bother with Rule 2 in the first place,
given
> the
> default policy is DROP and so there is no way for anyone else other than
> the
> partners to get access (Rule 3). Looking at various example policies on
the
> web, I
> find that there are explicitly defined DROP rules in conjunction with
> ACCEPT rules
> like rules 2 and 3 above. Its as if, one does not trust the default
policy.
Not just the "no trust" scenario. If you want to speed up the
firewalling/lower the response ratio then maybe it is usefull to drop some
packets as soon as possible.
In my firewall policies I try to find asap the "usefull" rule for the
packet/connection.
For example:
> I am just wondering, if all rules are applied to specific Interfaces,
> specific
> destination IP address, specific destination ports and some trust in the
> default
> policy would a lot of the possible policy conflicts be ruled out?
>
> If anyone could provide me with some scenarios/examples to the contrary
> that would
> be great.
>
> It would even be better if I could get a hold of some real firewall
> policies
> (anonymised internal IP ranges of course).
The same rules from above:
Chain PREROUTING (policy DROP 1 packets, 76 bytes)
pkts bytes target prot opt in out source
destination
1240K 495M ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
692 19424 PRE_ETH0 all -- eth0 * 192.168.255.0/24
0.0.0.0/0
6996K 6377M PRE_PPP0 all -- ppp0 * 0.0.0.0/0
EXTERNAL_IP
1669K 514M PRE_MFL1 all -- mfl1 * 172.31.255.248/29
0.0.0.0/0
6697K 2227M PRE_BR1 all -- br1 * 0.0.0.0/0
0.0.0.0/0
412K 121M PRE_BR2 all -- br2 * 0.0.0.0/0
0.0.0.0/0
1667K 385M ACCEPT all -- vpn1 * 192.168.10.0/24
0.0.0.0/0
25 15605 ACCEPT all -- vpn2 * 192.168.253.0/24
0.0.0.0/0
1219K 82M ACCEPT all -- vpn-ftp * 172.31.255.1
0.0.0.0/0
35 1960 PRE_BRS all -- brs * 0.0.0.0/0
0.0.0.0/0
1 76 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 7 prefix `IPT: RAW PRE '
Chain PRE_PPP0 (1 references)
pkts bytes target prot opt in out source
destination
56 3136 DROP all -- * * 10.0.0.0/8
0.0.0.0/0 /* PRIVATE USE */
0 0 DROP all -- * * 14.0.0.0/8
0.0.0.0/0 /* PUBLIC DATA NETWORKS */
0 0 DROP all -- * * 24.0.0.0/8
0.0.0.0/0 /* CABLE TELEVISION NETWORKS */
0 0 DROP all -- * * 39.0.0.0/8
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 127.0.0.0/8
0.0.0.0/0 /* LOOPBACK */
0 0 DROP all -- * * 128.0.0.0/16
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 169.254.0.0/16
0.0.0.0/0 /* LINK LOCAL */
0 0 DROP all -- * * 172.16.0.0/12
0.0.0.0/0 /* PRIVATE USE */
0 0 DROP all -- * * 191.255.0.0/16
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 192.0.0.0/24
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 192.0.2.0/24
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 192.88.99.0/24
0.0.0.0/0 /* 6to4 RELAY ANYCAST */
1 154 DROP all -- * * 192.168.0.0/16
0.0.0.0/0 /* PRIVATE USE */
0 0 DROP all -- * * 198.18.0.0/15
0.0.0.0/0 /* NETWORK INTERCONNECT */
0 0 DROP all -- * * 223.255.255.0/24
0.0.0.0/0 /* RESERVED */
0 0 DROP all -- * * 224.0.0.0/4
0.0.0.0/0 /* MULTICAST */
0 0 DROP all -- * * 240.0.0.0/4
0.0.0.0/0 /* RESERVED */
...
6996K 6377M ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
> It appears to me at least, that creating rules to be more specific than
> generic,
> while it increases the number rules, is probably a better solution more
> likely to
> be free of conflicts.
YES! For example if you have to connect a new subnet/network. With generic
rules you may have some unwanted side-effects... :D
>
> Again all feedback is welcome. Perhaps reality is not as black and white!
>
> regards,
> Will.
Swifty
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Query: iptables Conflict Policy Avoidance/Reduction
2009-06-04 12:13 ` Gáspár Lajos
@ 2009-06-04 16:11 ` william fitzgerald
0 siblings, 0 replies; 3+ messages in thread
From: william fitzgerald @ 2009-06-04 16:11 UTC (permalink / raw)
To: Mail List - Netfilter
Thanks G치sp치r (aka Swifty),
I was having one of those moments where you think, you think, you did'nt grasp
something! Like, did I book those flights on the correct days syndrome, so you
start doubting yourself ;-)
G치sp치r Lajos wrote:
> Hi Will.!
>
> On Wed, 03 Jun 2009 19:48:06 +0100, william fitzgerald
> <wfitzgerald@tssg.org> wrote:
>> Dear all,
>
>> Rule 1: iptables -A FORWARD -i eth+ -s 0/0 -d 192.168.1.2 --dport 80 -j
>> ACCEPT
>> Rule 2: iptables -A FORWARD -i eth+ -s 192.168.1.0/24 -d 192.168.1.2
>> --dport 80 -j
>> ACCEPT
>>
>> In the above scenario, Rule 2 is REDUNDANT to Rule 1 in that, the source
> IP
>> of
>> Rule 2 is covered by the source IP of Rule 1.
>
> Without any NAT-ing the firewall would never see such packets... (Sending
> packets to the same subnet should not be routed.)
>
Agreed. I always make the assumption that NAT-rules are independent of
filter-rules and that that NAT up and running. Sorry, I should of made that
clearer in my original post.
>> However, aren't these generic style rules not considered *best practice*
>> given
>> that the above rules when applied to all interfaces could allow IP
> Spoofing
>> of
>> reserved IP address range 192.168.1.0/24
>
> IP Spoofing should be done by specifying ALLOWED LOCAL IP ranges (and drop
> everything else) and specifying DISALLOWED REMOTE (private) IP ranges (and
> accept everything else).
>
In the below examples you gave, I was trying to think of a quick way to avoid
these whereby you implicitly deny these kind of rules with the "default policy".
But I see how allowing all IP addresses (0/0) to a web server for example is also
inclusive of RFC1918, RFC 3330 and NIST-800-41 best practice private-resevered IP
address countermeasures. And so the need to be implemented on the external
interface. It was one of those days where I was suffering from brain paralysis ;-)
> For example in RAW chain PREROUTING table:
>
> $table -P $chain DROP
>
> create_subchain PRE_PPP0
> $table -A $chain -j $subchain -i $PPP0_IF -d $PPP0_IP
>
> $table -A $subchain -j DROP -s 10.0.0.0/8 -m comment --comment
> 'PRIVATE USE' #RFC1918
> $table -A $subchain -j DROP -s 14.0.0.0/8 -m comment --comment 'PUBLIC
> DATA NETWORKS' #RFC1700, page 181
> $table -A $subchain -j DROP -s 24.0.0.0/8 -m comment --comment 'CABLE
> TELEVISION NETWORKS' #NOT SURE!!!
> $table -A $subchain -j DROP -s 39.0.0.0/8 -m comment --comment
> 'RESERVED' #RFC1797
> $table -A $subchain -j DROP -s 127.0.0.0/8 -m comment --comment
> 'LOOPBACK' #RFC1700, page 5
> $table -A $subchain -j DROP -s 128.0.0.0/16 -m comment --comment
> 'RESERVED'
> $table -A $subchain -j DROP -s 169.254.0.0/16 -m comment --comment
> 'LINK LOCAL'
> $table -A $subchain -j DROP -s 172.16.0.0/12 -m comment --comment
> 'PRIVATE USE' #RFC1918
> $table -A $subchain -j DROP -s 191.255.0.0/16 -m comment --comment
> 'RESERVED'
> $table -A $subchain -j DROP -s 192.0.0.0/24 -m comment --comment
> 'RESERVED'
> $table -A $subchain -j DROP -s 192.0.2.0/24 -m comment --comment
> 'RESERVED'
> $table -A $subchain -j DROP -s 192.88.99.0/24 -m comment --comment
> '6to4 RELAY ANYCAST' #RFC3068
> $table -A $subchain -j DROP -s 192.168.0.0/16 -m comment --comment
> 'PRIVATE USE' #RFC1918
> $table -A $subchain -j DROP -s 198.18.0.0/15 -m comment --comment
> 'NETWORK INTERCONNECT' #RFC2544
> $table -A $subchain -j DROP -s 223.255.255.0/24 -m comment --comment
> 'RESERVED'
> $table -A $subchain -j DROP -s 224.0.0.0/4 -m comment --comment
> 'MULTICAST' #RFC3171
> $table -A $subchain -j DROP -s 240.0.0.0/4 -m comment --comment
> 'RESERVED' #RFC1700, page 4
>
> ...
>
> $table -A $subchain -j ACCEPT
>
>
> $table -A $chain -j ACCEPT -i $LAN_IF -s $LAN_NW
>
>
>
>> So in order to avoid spoofing, one has to create the following two rules
>> and apply
>> them to specific interfaces.
>> iptables -A FORWARD -i eth1 -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
>> iptables -A FORWARD -i eth0 -s 192.168.1.0/24 -d 192.168.1.2 --dport 80
> -j
>> ACCEPT
>>
>>
>> Simple Shadowed example:
>>
>> Internet ---> (eth1)Firewall ---> Web Server
>> Partner ---> (eth1) Firewall ---> VPN Server
>>
>> Default Policy: iptables -P FORWARD DROP
>> Rule 1: iptables -A FORWARD -i eth1 -s 0/0 -d webIP --dport 80 -j ACCEPT
>> Rule 2: iptables -A FORWARD -i eth1 -s 0/0 -d vpnIP --dport 22 -j DROP
>> Rule 3: iptables -A FORWARD -i eth1 -s partnerIP -d vpnIP --dport 22 -j
>> ACCEPT
>>
>> Rule 2 blocks the intended partners access via Rule 3. A simple swap of
>> rule 2 and
>> rule 3 prevents this. But why bother with Rule 2 in the first place,
> given
>> the
>> default policy is DROP and so there is no way for anyone else other than
>> the
>> partners to get access (Rule 3). Looking at various example policies on
> the
>> web, I
>> find that there are explicitly defined DROP rules in conjunction with
>> ACCEPT rules
>> like rules 2 and 3 above. Its as if, one does not trust the default
> policy.
>
> Not just the "no trust" scenario. If you want to speed up the
> firewalling/lower the response ratio then maybe it is usefull to drop some
> packets as soon as possible.
>
> In my firewall policies I try to find asap the "usefull" rule for the
> packet/connection.
> For example:
>
>> I am just wondering, if all rules are applied to specific Interfaces,
>> specific
>> destination IP address, specific destination ports and some trust in the
>> default
>> policy would a lot of the possible policy conflicts be ruled out?
>>
>> If anyone could provide me with some scenarios/examples to the contrary
>> that would
>> be great.
>>
>> It would even be better if I could get a hold of some real firewall
>> policies
>> (anonymised internal IP ranges of course).
>
> The same rules from above:
>
Perfect.
>
> Chain PREROUTING (policy DROP 1 packets, 76 bytes)
> pkts bytes target prot opt in out source
> destination
> 1240K 495M ACCEPT all -- lo * 0.0.0.0/0
> 0.0.0.0/0
> 692 19424 PRE_ETH0 all -- eth0 * 192.168.255.0/24
> 0.0.0.0/0
> 6996K 6377M PRE_PPP0 all -- ppp0 * 0.0.0.0/0
> EXTERNAL_IP
> 1669K 514M PRE_MFL1 all -- mfl1 * 172.31.255.248/29
> 0.0.0.0/0
> 6697K 2227M PRE_BR1 all -- br1 * 0.0.0.0/0
> 0.0.0.0/0
> 412K 121M PRE_BR2 all -- br2 * 0.0.0.0/0
> 0.0.0.0/0
> 1667K 385M ACCEPT all -- vpn1 * 192.168.10.0/24
> 0.0.0.0/0
> 25 15605 ACCEPT all -- vpn2 * 192.168.253.0/24
> 0.0.0.0/0
> 1219K 82M ACCEPT all -- vpn-ftp * 172.31.255.1
> 0.0.0.0/0
> 35 1960 PRE_BRS all -- brs * 0.0.0.0/0
> 0.0.0.0/0
> 1 76 LOG all -- * * 0.0.0.0/0
> 0.0.0.0/0 LOG flags 0 level 7 prefix `IPT: RAW PRE '
>
> Chain PRE_PPP0 (1 references)
> pkts bytes target prot opt in out source
> destination
> 56 3136 DROP all -- * * 10.0.0.0/8
> 0.0.0.0/0 /* PRIVATE USE */
> 0 0 DROP all -- * * 14.0.0.0/8
> 0.0.0.0/0 /* PUBLIC DATA NETWORKS */
> 0 0 DROP all -- * * 24.0.0.0/8
> 0.0.0.0/0 /* CABLE TELEVISION NETWORKS */
> 0 0 DROP all -- * * 39.0.0.0/8
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 127.0.0.0/8
> 0.0.0.0/0 /* LOOPBACK */
> 0 0 DROP all -- * * 128.0.0.0/16
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 169.254.0.0/16
> 0.0.0.0/0 /* LINK LOCAL */
> 0 0 DROP all -- * * 172.16.0.0/12
> 0.0.0.0/0 /* PRIVATE USE */
> 0 0 DROP all -- * * 191.255.0.0/16
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 192.0.0.0/24
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 192.0.2.0/24
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 192.88.99.0/24
> 0.0.0.0/0 /* 6to4 RELAY ANYCAST */
> 1 154 DROP all -- * * 192.168.0.0/16
> 0.0.0.0/0 /* PRIVATE USE */
> 0 0 DROP all -- * * 198.18.0.0/15
> 0.0.0.0/0 /* NETWORK INTERCONNECT */
> 0 0 DROP all -- * * 223.255.255.0/24
> 0.0.0.0/0 /* RESERVED */
> 0 0 DROP all -- * * 224.0.0.0/4
> 0.0.0.0/0 /* MULTICAST */
> 0 0 DROP all -- * * 240.0.0.0/4
> 0.0.0.0/0 /* RESERVED */
>
> ...
>
> 6996K 6377M ACCEPT all -- * * 0.0.0.0/0
> 0.0.0.0/0
>
>
>> It appears to me at least, that creating rules to be more specific than
>> generic,
>> while it increases the number rules, is probably a better solution more
>> likely to
>> be free of conflicts.
>
> YES! For example if you have to connect a new subnet/network. With generic
> rules you may have some unwanted side-effects... :D
Agreed ;-)
Two other previous posts I sent yesterday also suffer from the same short-term
memory delusion ;-)
Thanks for everything,
Will.
>
>> Again all feedback is welcome. Perhaps reality is not as black and white!
>>
>> regards,
>> Will.
>
> Swifty
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
________________________________________
William M. Fitzgerald (MSc, BSc)
PhD Student,
Cork Constraint Computation Centre,
Computer Science Dept.,
University College Cork,
Cork,
Ireland.
----------------------------------------
www.williamfitzgerald.net
www.williamfitzgerald.info
www.linkedin.com/in/williamfitzgerald
http://4c.ucc.ie/web/people.jsp?id=143
www.tssg.org/people/wfitzgerald/
________________________________________
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-06-04 16:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-03 18:48 Query: iptables Conflict Policy Avoidance/Reduction william fitzgerald
2009-06-04 12:13 ` Gáspár Lajos
2009-06-04 16:11 ` william fitzgerald
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.