> process normally if the HELO and MAIL From/RCPT To look all right;
> otherwise continue to read small gulps of the DATA at slow intervals,
> then answer the final "." with a *temporary* failure code.
I'd rather have spammers consume less of my CPU time and bandwidth,
not have them keep coming
> process normally if the HELO and MAIL From/RCPT To look all right;
> otherwise continue to read small gulps of the DATA at slow intervals,
> then answer the final "." with a *temporary* failure code.
I'd rather have spammers consume less of my CPU time and bandwidth,
not have them keep coming
Geoff Rehmet <[EMAIL PROTECTED]> wrote:
>sysctl -d needs fixing. :-)
No, sysctl -d needs _implementing_. I've looked into this myself.
I brought it up on -hackers in mid-February, and here in early June.
"sysctl -d" invokes sysctl({0,5,...},...) (sysctl.c:show_var()).
kern_sysctl.c documents (
> On Tue, Aug 17, 1999, Geoff Rehmet wrote:
> If you're still volunteering, write a script to generate a
> sysctl description
> map from the sysctl's in the kernel..
>
> That would be very nice, and would kickstart me into
> finishing documenting
> all sysctls. :P
>
First issue:
hangdog:~%
On 18-Aug-99 Ollivier Robert wrote:
> > Instead of killing the spammer, make every mailserver like quicksand,
> > drawing him down and drowning him :-]
> Postfix does this :)
Sendmail has tarpit trapping as well I think.
---
Daniel O'Connor software and network engineer
for Genesis Software -
According to Leif Neland:
> the slowest possible, so the spammer could only deliver very few messages.
> Instead of killing the spammer, make every mailserver like quicksand,
> drawing him down and drowning him :-]
Postfix does this :)
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMA
> > This reminds me of a proposal for sendmail; instead of rejecting
> > mail from known spammers, one would accept the connection, but
> > slow traffic down to the slowest possible, so the spammer could
> > only deliver very few messages. Instead of killing the spammer,
> > make every mailserver
On Tue, 17 Aug 1999, Matt Crawford wrote:
> I see no point in the proposed mechanism. The scanner can still tell
> the difference between a port with a listener and a port with none.
> The only case in which the attacker is confounded would be in
> distinguishing a box which is down or off the
In article <[EMAIL PROTECTED]>,
Geoff Rehmet <[EMAIL PROTECTED]> wrote:
> >
> > Plus, packets with RST in them are used for other purposes besides
> > rejecting new incoming connections..
>
> True, my implementation is specific that I only omit generating
> a RST when the icoming segment is a S
On Tue, Aug 17, 1999, Geoff Rehmet wrote:
> > > Looks like I'm volunteering to write a manpage for the net.inet
> > > sysctls - or does one exist? - I sure as hell can't find it!
> >
> > :-), you put your keyboard in it now!!!
> Yup,
>
> well I need the pointy hat too. A grep through the man tr
< said:
> How would this be different than a packet filter on inbound
> connections?
It would work in open network environments.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those
I see no point in the proposed mechanism. The scanner can still tell
the difference between a port with a listener and a port with none.
The only case in which the attacker is confounded would be in
distinguishing a box which is down or off the net from a box which
has *no* services and does not
> > Looks like I'm volunteering to write a manpage for the net.inet
> > sysctls - or does one exist? - I sure as hell can't find it!
>
> :-), you put your keyboard in it now!!!
Yup,
well I need the pointy hat too. A grep through the man tree shows
references to various sysctl MIBs hidden all ov
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
>
> >
> > This is an ACK. I like those names, the idea is okay given that
> > the documentation for it reflects what has been discussed here in
> > this thread so folks can understand this is a very simple security
> > measure.
> Hmm, d
>
> Geoff Rehmet writes:
> > > : Not that easily.. how are you going to make ipfw
> dynamically know
> > > : which ports have listeners and which don't?
> > >
> > > By filtering all RST packets?
> >
> > My view was that this is much simpler than filtering packets -
> > never generate the packe
>
> This is an ACK. I like those names, the idea is okay given that
> the documentation for it reflects what has been discussed here in
> this thread so folks can understand this is a very simple security
> measure.
Hmm, dumb question for the day - where are things like "log_in_vain"
documente
Geoff Rehmet writes:
> > : Not that easily.. how are you going to make ipfw dynamically know
> > : which ports have listeners and which don't?
> >
> > By filtering all RST packets?
>
> My view was that this is much simpler than filtering packets -
> never generate the packet. My guess is that i
> In message <[EMAIL PROTECTED]> Archie Cobbs writes:
> : Not that easily.. how are you going to make ipfw dynamically know
> : which ports have listeners and which don't?
>
> By filtering all RST packets?
That would be closer than my set of rules, but has the undesired effect
of filtering what
> In message <[EMAIL PROTECTED]> Archie
> Cobbs writes:
> : Not that easily.. how are you going to make ipfw dynamically know
> : which ports have listeners and which don't?
>
> By filtering all RST packets?
My view was that this is much simpler than filtering packets -
never generate the packe
> Rodney W. Grimes writes :
> > >
> >
> > Now what would a box with so much security concern such that
> > it needed this knob be doing running an ftp session though
> > your point is valid and acceptable for low security boxes. And
> > I can see the real benifit that having this knob for t
On 17-Aug-99 Warner Losh wrote:
> : Not that easily.. how are you going to make ipfw dynamically know
> : which ports have listeners and which don't?
> By filtering all RST packets?
The defeats the purpose of having the computer not generate them in the first
place.. Well not totally I suppose,
In message <[EMAIL PROTECTED]> Archie Cobbs writes:
: Not that easily.. how are you going to make ipfw dynamically know
: which ports have listeners and which don't?
By filtering all RST packets?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the bo
In message <[EMAIL PROTECTED]> Geoff Rehmet
writes:
: In default configuration, everything would behave as per
: normal, and you would have to set a sysctl MIB before the
: behaviour that I have described is displayed.
:
: Can anyone think of any reason why this feature should
: not be implement
Rodney W. Grimes writes :
> >
>
> Now what would a box with so much security concern such that
> it needed this knob be doing running an ftp session though
> your point is valid and acceptable for low security boxes. And
> I can see the real benifit that having this knob for those boxes
> w
On 17-Aug-99 Rodney W. Grimes wrote:
> Would I use it in place of ipfw for what the original person asked
> about, no way, not in a million years. If I want a box secure it
> is going to have ipfw or ipfilter rules down to the last detail.
> Why, well, it would prevent some junior admin from
>
> On 17-Aug-99 Rodney W. Grimes wrote:
> > I kinda like the idea of this, but can't that really just
> > be done easily with a few ipfw rules, the last two being
> > the important ones:
> >
> > for port in "22 53" ; do
> > ipfw add allow udp from any to ${myip} ${port}
> > ipf
On 17-Aug-99 Rodney W. Grimes wrote:
> I kinda like the idea of this, but can't that really just
> be done easily with a few ipfw rules, the last two being
> the important ones:
>
> for port in "22 53" ; do
> ipfw add allow udp from any to ${myip} ${port}
> ipfw add allow udp fr
> Brian W. Buchanan writes:
> > > > Can anyone think of any reason why this feature should
> > > > not be implemented?
> > >
> > > I like that idea... net.inet.{tcp,udp}.drop_in_vain ?
> >
> > Why do we need a sysctl knob for this when it can be easily accomplished
> > with IPFW?
>
> Not that e
> Geoff Rehmet writes:
> > After the discussions regarding the "log_in_vain"
> > sysctls, I was thinking about a feature I would
> > like to implement:
> >
> > Instead of sending a RST (for TCP) or Port Unreachable
> > (for UDP) where the box is not listening on a socket,
> > I would like to impl
Brian W. Buchanan writes:
> > > Can anyone think of any reason why this feature should
> > > not be implemented?
> >
> > I like that idea... net.inet.{tcp,udp}.drop_in_vain ?
>
> Why do we need a sysctl knob for this when it can be easily accomplished
> with IPFW?
Not that easily.. how are you
On Mon, 16 Aug 1999, Archie Cobbs wrote:
> Geoff Rehmet writes:
> > After the discussions regarding the "log_in_vain"
> > sysctls, I was thinking about a feature I would
> > like to implement:
> >
> > Instead of sending a RST (for TCP) or Port Unreachable
> > (for UDP) where the box is not liste
Geoff Rehmet writes:
> After the discussions regarding the "log_in_vain"
> sysctls, I was thinking about a feature I would
> like to implement:
>
> Instead of sending a RST (for TCP) or Port Unreachable
> (for UDP) where the box is not listening on a socket,
> I would like to implement a sysctl,
After the discussions regarding the "log_in_vain"
sysctls, I was thinking about a feature I would
like to implement:
Instead of sending a RST (for TCP) or Port Unreachable
(for UDP) where the box is not listening on a socket,
I would like to implement a sysctl, which disables the
sending of the R
33 matches
Mail list logo
