Tommaso Di Donato wrote:
Hi guys!
If you really wan to slow down a remote portscan (or os
fingerprinting), in my own opinion the only very useful way is
tarpitting.. Tarpit is an extension of linux iptables/netfilter..
http://www.securityfocus.com/infocus/1723
Does anybody know if there is t
Hi guys!
If you really wan to slow down a remote portscan (or os
fingerprinting), in my own opinion the only very useful way is
tarpitting.. Tarpit is an extension of linux iptables/netfilter..
http://www.securityfocus.com/infocus/1723
Does anybody know if there is the same thing for pf?
On 9/26/05, Greg Hennessy <[EMAIL PROTECTED]> wrote:
> > so its safe to assume that internet -> WAN stuff should be
> > blocked. but for internal access between my LAN/OPT
> > interfaces and outbound WAN i can use reject and it wouldn't
> > be considered bad form?
Hmm, rejecting on the outbound W
> At 12:24 PM 9/26/2005, you wrote:
> >Something I have noticed, is that playing ball on the internet
> >interface has reduced the amount of scanning traffic significantly.
>
> Greg, that's interesting. Do you have any theories as to why?
I've given that some thought and had one or two discus
At 12:24 PM 9/26/2005, you wrote:
Something I have noticed, is that playing ball on the internet interface has
reduced the amount of scanning traffic significantly.
Greg, that's interesting. Do you have any theories as to why?
> so its safe to assume that internet -> WAN stuff should be
> blocked. but for internal access between my LAN/OPT
> interfaces and outbound WAN i can use reject and it wouldn't
> be considered bad form?
Not at all. It's something I insist on when managing production firewalls of
whatever hu
Matthew Lenz wrote:
so its safe to assume that internet -> WAN stuff should be blocked.
but for internal access between my LAN/OPT interfaces and outbound WAN
i can use reject and it wouldn't be considered bad form?
Under most circumstances, yes, that's correct.
Matthew Lenz wrote:
Just had a situation where a backend job was hanging because it couldn't
get to an ip. the tcp connect just kinda hung and this particular
software module had a really long timeout set. Is there a reason why
for example there is a global block in pfsense as opposed to a g
A Rossi wrote:
I've narrowed it down to 2 possible sites:
http://www.auditmypc.com/
and
https://www.grc.com/x/ne.dll?bh0bkyd2
neither gave me anything out of the ordinary behind m0n0wall or pfsense.
first one found my private IP address **GASP** Oh no!;)
-cmb
I've narrowed it down to 2 possible sites:
http://www.auditmypc.com/
and
https://www.grc.com/x/ne.dll?bh0bkyd2
- Original Message -
From: "Chris Buechler" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 23, 2005 12:54 PM
Subject: Re: [pfSense-discussion] block
never heard of any tests trying for that. maybe your ISP dropping some
ports (135-139, 445, etc. are common) and rejecting them and it saw the
unreachables as you connecting back?
Hard telling, sounds like a buggy testing tool to me though. if you can
recall what site it is, I'll check it ou
r" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 23, 2005 12:23 PM
Subject: Re: [pfSense-discussion] block vs reject?
> Matthew Lenz wrote:
>
> >Just had a situation where a backend job was hanging because it couldn't
> >get to an ip. the tcp connect just kinda hu
Matthew Lenz wrote:
Just had a situation where a backend job was hanging because it couldn't
get to an ip. the tcp connect just kinda hung and this particular
software module had a really long timeout set. Is there a reason why
for example there is a global block in pfsense as opposed to a glo
Just had a situation where a backend job was hanging because it couldn't
get to an ip. the tcp connect just kinda hung and this particular
software module had a really long timeout set. Is there a reason why
for example there is a global block in pfsense as opposed to a global
reject (which seems
14 matches
Mail list logo
