All of lore.kernel.org
 help / color / mirror / Atom feed
* Port Scanner
@ 2003-11-05 14:14 Leandro Takashi Hirano
  2003-11-05 14:19 ` Antony Stone
  2003-11-05 14:37 ` Cedric Blancher
  0 siblings, 2 replies; 13+ messages in thread
From: Leandro Takashi Hirano @ 2003-11-05 14:14 UTC (permalink / raw)
  To: Lista de Mail netfilter

How does this rule work?

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit –limit
1/s -j ACCEPT

Is it safe to use only this rule to avoid port scanners?

Thanks for help!




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 14:14 Leandro Takashi Hirano
@ 2003-11-05 14:19 ` Antony Stone
  2003-11-05 14:44   ` Leandro Takashi Hirano
  2003-11-05 14:37 ` Cedric Blancher
  1 sibling, 1 reply; 13+ messages in thread
From: Antony Stone @ 2003-11-05 14:19 UTC (permalink / raw)
  To: Lista de Mail netfilter

On Wednesday 05 November 2003 2:14 pm, Leandro Takashi Hirano wrote:

> How does this rule work?
>
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit ?limit
> 1/s -j ACCEPT

It means that any packets which have the RST flag set, and the SYN, ACK, FIN 
flags cleared, will only be allowed *through* the firewall at a maximum rate 
of one packet per second.

> Is it safe to use only this rule to avoid port scanners?

Depends what you mean by "safe" and "avoid" :)

Here are some observations on the above rule:

1. It is in the FORWARD chain, therefore it has no effect on people port 
scanning the firewall itself (it would need to be in the INPUT chain to 
affect that).

2. One packet per second will be ACCEPTed.   What happens to the other 
packets (and whether anything gets returned to the scanner) depends on the 
other rules following this one in the chain.

3. The rule only applies to packets with RST set, and SYN, ACK, FIN clear.   
Therefore it will incfluence the outcome of a RST port scan, but have no 
effect on a FIN scan, or a SYN scan.

I think in order to answer your question we first need to know:

 - what response do you want someone to get when they attempt to port scan 
your system?

Regards,

Antony.


-- 

"It is not the strongest of the species that survive, nor the most 
intelligent, but the ones most responsive to change."

 - Charles Darwin
                                                     Please reply to the list;
                                                           please don't CC me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 14:14 Leandro Takashi Hirano
  2003-11-05 14:19 ` Antony Stone
@ 2003-11-05 14:37 ` Cedric Blancher
  2003-11-05 15:15   ` hare ram
  1 sibling, 1 reply; 13+ messages in thread
From: Cedric Blancher @ 2003-11-05 14:37 UTC (permalink / raw)
  To: Leandro Takashi Hirano; +Cc: Lista de Mail netfilter

Le mer 05/11/2003 à 15:14, Leandro Takashi Hirano a écrit :
> Is it safe to use only this rule to avoid port scanners?

See psd match :

	http://www.netfilter.org/documentation/pomlist/pom-base.html#psd

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 14:19 ` Antony Stone
@ 2003-11-05 14:44   ` Leandro Takashi Hirano
  2003-11-05 15:15     ` Antony Stone
  0 siblings, 1 reply; 13+ messages in thread
From: Leandro Takashi Hirano @ 2003-11-05 14:44 UTC (permalink / raw)
  To: Lista de Mail netfilter

> On Wednesday 05 November 2003 2:14 pm, Leandro Takashi Hirano wrote:
>
>> How does this rule work?
>>
>> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
>> ?limit 1/s -j ACCEPT
>
> It means that any packets which have the RST flag set, and the SYN, ACK,
> FIN  flags cleared, will only be allowed *through* the firewall at a
> maximum rate  of one packet per second.
>
>> Is it safe to use only this rule to avoid port scanners?
>
> Depends what you mean by "safe" and "avoid" :)
>
> Here are some observations on the above rule:
>
> 1. It is in the FORWARD chain, therefore it has no effect on people port
>  scanning the firewall itself (it would need to be in the INPUT chain to
>  affect that).
>
> 2. One packet per second will be ACCEPTed.   What happens to the other
> packets (and whether anything gets returned to the scanner) depends on
> the  other rules following this one in the chain.


OK, one packet per second will be ACCEPTed, but aren´t the other packets
going to be DROPed?



>
> 3. The rule only applies to packets with RST set, and SYN, ACK, FIN
> clear.    Therefore it will incfluence the outcome of a RST port scan,
> but have no  effect on a FIN scan, or a SYN scan.
>

Do I have also to create a rule for FIN scan and SYN scan?
Do you have some port scanners rules to show me? (and other protection
rules too)

And thanks very much for the help!!!

> I think in order to answer your question we first need to know:
>
>  - what response do you want someone to get when they attempt to port
> scan
> your system?
>

no answer....

> Regards,
>
> Antony.
>
>
> --
>
> "It is not the strongest of the species that survive, nor the most
> intelligent, but the ones most responsive to change."
>
>  - Charles Darwin
>                                                      Please reply to the
> list;
>                                                            please don't
> CC me.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
@ 2003-11-05 15:06 tsh
  2003-11-05 15:22 ` Antony Stone
  2003-11-05 15:25 ` Martín
  0 siblings, 2 replies; 13+ messages in thread
From: tsh @ 2003-11-05 15:06 UTC (permalink / raw)
  To: netfilter

I was thinking about just this the other night, and is seems
to me that such a rule should be rejecting stuff which exceeds the rate
limit rather than accepting stuff which doesnt exceed it,
since the -j ACCEPT will mean that any subsequent rules in
a FORWARD table wont be tested.

Something like

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit ! limit 1/s -j DROP

Cheers,
Terry





>> On Wednesday 05 November 2003 2:14 pm, Leandro Takashi Hirano wrote:
>>
>>> How does this rule work?
>>>
>>> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
>>> ?limit 1/s -j ACCEPT
>>
>> It means that any packets which have the RST flag set, and the SYN, ACK,
>> FIN  flags cleared, will only be allowed *through* the firewall at a
>> maximum rate  of one packet per second.
>>
>>> Is it safe to use only this rule to avoid port scanners?
>>
>> Depends what you mean by "safe" and "avoid" :)
>>
>> Here are some observations on the above rule:
>>
>> 1. It is in the FORWARD chain, therefore it has no effect on people port
>>  scanning the firewall itself (it would need to be in the INPUT chain to
>>  affect that).
>>
>> 2. One packet per second will be ACCEPTed.   What happens to the other
>> packets (and whether anything gets returned to the scanner) depends on
>> the  other rules following this one in the chain.
>
>
>OK, one packet per second will be ACCEPTed, but aren_t the other packets
>going to be DROPed?
>
>
>
>>
>> 3. The rule only applies to packets with RST set, and SYN, ACK, FIN
>> clear.    Therefore it will incfluence the outcome of a RST port scan,
>> but have no  effect on a FIN scan, or a SYN scan.
>>
>
>Do I have also to create a rule for FIN scan and SYN scan?
>Do you have some port scanners rules to show me? (and other protection
>rules too)
>
>And thanks very much for the help!!!
>
>> I think in order to answer your question we first need to know:
>>
>>  - what response do you want someone to get when they attempt to port
>> scan
>> your system?
>>
>
>no answer....
>
>> Regards,
>>
>> Antony.
>>
>>
>> --
>>
>> "It is not the strongest of the species that survive, nor the most
>> intelligent, but the ones most responsive to change."
>>
>>  - Charles Darwin
>>                                                      Please reply to the
>> list;
>>                                                            please don't
>> CC me.
>




----- End of forwarded message from Leandro Takashi Hirano -----


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 14:44   ` Leandro Takashi Hirano
@ 2003-11-05 15:15     ` Antony Stone
  0 siblings, 0 replies; 13+ messages in thread
From: Antony Stone @ 2003-11-05 15:15 UTC (permalink / raw)
  To: Lista de Mail netfilter

On Wednesday 05 November 2003 2:44 pm, Leandro Takashi Hirano wrote:

> > 2. One packet per second will be ACCEPTed.   What happens to the other
> > packets (and whether anything gets returned to the scanner) depends on
> > the  other rules following this one in the chain.
>
> OK, one packet per second will be ACCEPTed, but aren´t the other packets
> going to be DROPed?

As I said, that depends on what rules follow this one in the chain.   You can 
DROP the packets, you can REJECT the packets - you can even ACCEPT them if 
you want to!

> > 3. The rule only applies to packets with RST set, and SYN, ACK, FIN
> > clear.    Therefore it will incfluence the outcome of a RST port scan,
> > but have no  effect on a FIN scan, or a SYN scan.
>
> Do I have also to create a rule for FIN scan and SYN scan?

If you want to block those types of scan, then yes.

> Do you have some port scanners rules to show me? (and other protection
> rules too)

Tell me what you want to do and I may be able to show you a rule which does 
it.

Personally I simply DROP all packets which I don't want to allow.

> > I think in order to answer your question we first need to know:
> >
> >  - what response do you want someone to get when they attempt to port
> > scan your system?
>
> no answer....

Okay.

Antony.

-- 

I love deadlines.   I love the whooshing noise they make as they go by.

 - Douglas Noel Adams
                                                     Please reply to the list;
                                                           please don't CC me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 14:37 ` Cedric Blancher
@ 2003-11-05 15:15   ` hare ram
  2003-11-05 15:28     ` Antony Stone
  0 siblings, 1 reply; 13+ messages in thread
From: hare ram @ 2003-11-05 15:15 UTC (permalink / raw)
  To: Cedric Blancher, Leandro Takashi Hirano; +Cc: Lista de Mail netfilter

Hi

iam using p-o-m with PSD patch

right now iam running this

iptables -A INPUT -m psd -j DROP

how do i run the script like this
Log the Portscanner IP and Drop them

thanks
hare

----- Original Message ----- 
From: "Cedric Blancher" <blancher@cartel-securite.fr>
To: "Leandro Takashi Hirano" <takashi@alcidesmaya.com.br>
Cc: "Lista de Mail netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, November 05, 2003 8:07 PM
Subject: Re: Port Scanner


Le mer 05/11/2003 à 15:14, Leandro Takashi Hirano a écrit :
> Is it safe to use only this rule to avoid port scanners?

See psd match :

http://www.netfilter.org/documentation/pomlist/pom-base.html#psd

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 15:06 Port Scanner tsh
@ 2003-11-05 15:22 ` Antony Stone
  2003-11-05 15:25 ` Martín
  1 sibling, 0 replies; 13+ messages in thread
From: Antony Stone @ 2003-11-05 15:22 UTC (permalink / raw)
  To: netfilter

On Wednesday 05 November 2003 3:06 pm, tsh@mrc-lmb.cam.ac.uk wrote:

> I was thinking about just this the other night, and is seems to me that
> such a rule should be rejecting stuff which exceeds the rate limit rather
> than accepting stuff which doesnt exceed it, since the -j ACCEPT will mean
> that any subsequent rules in a FORWARD table wont be tested.
>
> Something like
>
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit ! limit
> 1/s -j DROP

Why do people want to ACCEPT any packets of this type at all?   If a packet 
is part of an ESTABLISHED connection then it is going to pass through your 
FORWARD chain on the connection tracking rule; if a packet is not part of an 
ESTABLISHED connection, then it's either a valid new connection (in which 
case you ACCEPT it), or else it isn't (in which case you don't ACCEPT it).

I can't quite see why you would want to accept even a slow rate of such 
packets.

Regards,

Antony.

-- 

This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.
                                                     Please reply to the list;
                                                           please don't CC me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 15:06 Port Scanner tsh
  2003-11-05 15:22 ` Antony Stone
@ 2003-11-05 15:25 ` Martín
  1 sibling, 0 replies; 13+ messages in thread
From: Martín @ 2003-11-05 15:25 UTC (permalink / raw)
  To: tsh; +Cc: netfilter@lists.netfilter.org

The bestway to stop portscanning is useing something like PORTSENTRY. I 
dont think useing iptables for this is a good idea, you may DROP legal 
traffic this way, PORTSENTRY is more inteligent and is specially developed 
for this task (and works together eith iptables by the way)



En Wed, 5 Nov 2003 15:06:55 +0000 (GMT), <tsh@mrc-lmb.cam.ac.uk> escribió:

> I was thinking about just this the other night, and is seems
> to me that such a rule should be rejecting stuff which exceeds the rate
> limit rather than accepting stuff which doesnt exceed it,
> since the -j ACCEPT will mean that any subsequent rules in
> a FORWARD table wont be tested.
>
> Something like
>
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit ! 
> limit 1/s -j DROP
>
> Cheers,
> Terry
>
>
>
>
>
>>> On Wednesday 05 November 2003 2:14 pm, Leandro Takashi Hirano wrote:
>>>
>>>> How does this rule work?
>>>>
>>>> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
>>>> ?limit 1/s -j ACCEPT
>>>
>>> It means that any packets which have the RST flag set, and the SYN, 
>>> ACK,
>>> FIN  flags cleared, will only be allowed *through* the firewall at a
>>> maximum rate  of one packet per second.
>>>
>>>> Is it safe to use only this rule to avoid port scanners?
>>>
>>> Depends what you mean by "safe" and "avoid" :)
>>>
>>> Here are some observations on the above rule:
>>>
>>> 1. It is in the FORWARD chain, therefore it has no effect on people 
>>> port
>>> scanning the firewall itself (it would need to be in the INPUT chain to
>>> affect that).
>>>
>>> 2. One packet per second will be ACCEPTed.   What happens to the other
>>> packets (and whether anything gets returned to the scanner) depends on
>>> the  other rules following this one in the chain.
>>
>>
>> OK, one packet per second will be ACCEPTed, but aren_t the other packets
>> going to be DROPed?
>>
>>
>>
>>>
>>> 3. The rule only applies to packets with RST set, and SYN, ACK, FIN
>>> clear.    Therefore it will incfluence the outcome of a RST port scan,
>>> but have no  effect on a FIN scan, or a SYN scan.
>>>
>>
>> Do I have also to create a rule for FIN scan and SYN scan?
>> Do you have some port scanners rules to show me? (and other protection
>> rules too)
>>
>> And thanks very much for the help!!!
>>
>>> I think in order to answer your question we first need to know:
>>>
>>> - what response do you want someone to get when they attempt to port
>>> scan
>>> your system?
>>>
>>
>> no answer....
>>
>>> Regards,
>>>
>>> Antony.
>>>
>>>
>>> --
>>>
>>> "It is not the strongest of the species that survive, nor the most
>>> intelligent, but the ones most responsive to change."
>>>
>>> - Charles Darwin
>>> Please reply to the
>>> list;
>>> please don't
>>> CC me.
>>
>
>
>
>
> ----- End of forwarded message from Leandro Takashi Hirano -----
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 15:15   ` hare ram
@ 2003-11-05 15:28     ` Antony Stone
  0 siblings, 0 replies; 13+ messages in thread
From: Antony Stone @ 2003-11-05 15:28 UTC (permalink / raw)
  To: netfilter

On Wednesday 05 November 2003 3:15 pm, hare ram wrote:

> Hi
>
> iam using p-o-m with PSD patch
>
> right now iam running this
>
> iptables -A INPUT -m psd -j DROP
>
> how do i run the script like this
> Log the Portscanner IP and Drop them

How about:

iptables -N log-and-drop

iptables -A INPUT -m psd -j log-and-drop

iptables -A log-and-drop -j LOG --log-level=....etc
iptables -A log-and-drop -j DROP

Antony.

-- 

Documentation is like sex:
when it's good, it's very very good;
when it's bad, it's still better than nothing.
                                                     Please reply to the list;
                                                           please don't CC me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
@ 2003-11-05 16:38 tsh
  2003-11-05 17:07 ` Antony Stone
  0 siblings, 1 reply; 13+ messages in thread
From: tsh @ 2003-11-05 16:38 UTC (permalink / raw)
  To: netfilter

Not particularly packets of this type, but e.g. to put a rate-limit
on incoming NEW connections, in order to help prevent a DoS attack
on, say, a webserver or mailhub. 
It would be nice if the limit module was adaptive, and only flagged
ips which were exceeding the rate, otherwise it seems to me that
the same effect as a DoS attack can be achieved simply by sending
packets at a sufficient rate to trigger the limit cut-off, which
would then block *all* packets until the flow reduced.
Even with a seperate rule for each server, all NEW connections
to that server would still be blocked if the limit was exceeded.

Cheers,
T.


>> I was thinking about just this the other night, and is seems to me that
>> such a rule should be rejecting stuff which exceeds the rate limit rather
>> than accepting stuff which doesnt exceed it, since the -j ACCEPT will mean
>> that any subsequent rules in a FORWARD table wont be tested.
>>
>> Something like
>>
>> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit ! limit
>> 1/s -j DROP
>
>Why do people want to ACCEPT any packets of this type at all?   If a packet 
>is part of an ESTABLISHED connection then it is going to pass through your 
>FORWARD chain on the connection tracking rule; if a packet is not part of an 
>ESTABLISHED connection, then it's either a valid new connection (in which 
>case you ACCEPT it), or else it isn't (in which case you don't ACCEPT it).
>
>I can't quite see why you would want to accept even a slow rate of such 
>>packets.
>
>Regards,
>
>Antony.

-- 

This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar. _ Whisk until soft peaks form, then place in a warm oven for 40 
minutes. _ Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream. _ Then notify me immediately by return email 
and eat the original message.
                                                     Please reply to the list;
                                                           please don't CC me.


----- End of forwarded message from Antony Stone -----


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 16:38 tsh
@ 2003-11-05 17:07 ` Antony Stone
  2003-11-05 19:19   ` SBlaze
  0 siblings, 1 reply; 13+ messages in thread
From: Antony Stone @ 2003-11-05 17:07 UTC (permalink / raw)
  To: netfilter

On Wednesday 05 November 2003 4:38 pm, tsh@mrc-lmb.cam.ac.uk wrote:

> Not particularly packets of this type, but e.g. to put a rate-limit
> on incoming NEW connections, in order to help prevent a DoS attack
> on, say, a webserver or mailhub.

Indeed - that makes much more sense, yes.

Antony.

> >> I was thinking about just this the other night, and is seems to me that
> >> such a rule should be rejecting stuff which exceeds the rate limit
> >> rather than accepting stuff which doesnt exceed it, since the -j ACCEPT
> >> will mean that any subsequent rules in a FORWARD table wont be tested.
> >>
> >> Something like
> >>
> >> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit !
> >> limit 1/s -j DROP
> >
> >Why do people want to ACCEPT any packets of this type at all?   If a
> > packet is part of an ESTABLISHED connection then it is going to pass
> > through your FORWARD chain on the connection tracking rule; if a packet
> > is not part of an ESTABLISHED connection, then it's either a valid new
> > connection (in which case you ACCEPT it), or else it isn't (in which case
> > you don't ACCEPT it).
> >
> >I can't quite see why you would want to accept even a slow rate of such
> >
> >>packets.
> >
> >Regards,
> >
> >Antony.

-- 

If at first you don't succeed, destroy all the evidence that you tried.
                                                     Please reply to the list;
                                                           please don't CC me.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Port Scanner
  2003-11-05 17:07 ` Antony Stone
@ 2003-11-05 19:19   ` SBlaze
  0 siblings, 0 replies; 13+ messages in thread
From: SBlaze @ 2003-11-05 19:19 UTC (permalink / raw)
  To: netfilter

In the interest of sharing.. I'ld like to show how I stop portscanning.

Please take note about this and my method. It's for a NATed network on a home
cable line. If you want to open services to the world they should preceed these
lines. This is a very hard nosed way to stop portscanning and any other types
of connections to your computer. Please note that you may want to add other
protcols to the list as well if you use this method.. such as IGMP etc etc

This does stop any and all of NMAPs cuurrent scans.

# NMAP and Connection killer
#
# iptables -A INPUT -p tcp -i eth0 -m state --state NEW -j LOG
iptables -A INPUT -p tcp -i eth0 -m state --state NEW,INVALID -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# UDP Filters
#
#iptables -A INPUT -p udp -i eth0 -m state --state NEW,INVALID -j LOG
iptables -A INPUT -p udp -i eth0 -m state --state NEW,INVALID -j DROP
iptables -A INPUT -p udp -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

# ICMP Filtration
#
iptables -A INPUT -p icmp -i eth0 -m state --state NEW,INVALID -j DROP
iptables -A INPUT -p icmp -i eth0 -m state --state ESTABLISHED,RELATED -j
ACCEPT

SBlaze

=====
In the absence of order there will be chaos.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2003-11-05 19:19 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-05 15:06 Port Scanner tsh
2003-11-05 15:22 ` Antony Stone
2003-11-05 15:25 ` Martín
  -- strict thread matches above, loose matches on Subject: below --
2003-11-05 16:38 tsh
2003-11-05 17:07 ` Antony Stone
2003-11-05 19:19   ` SBlaze
2003-11-05 14:14 Leandro Takashi Hirano
2003-11-05 14:19 ` Antony Stone
2003-11-05 14:44   ` Leandro Takashi Hirano
2003-11-05 15:15     ` Antony Stone
2003-11-05 14:37 ` Cedric Blancher
2003-11-05 15:15   ` hare ram
2003-11-05 15:28     ` Antony Stone

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.