[51004] in North American Network Operators' Group
Re: Echo
daemon@ATHENA.MIT.EDU (Karsten W. Rohrbach)
Sat Aug 17 19:08:53 2002
Date: Sun, 18 Aug 2002 01:08:37 +0200
From: "Karsten W. Rohrbach" <karsten@rohrbach.de>
To: Brad Knowles <brad.knowles@skynet.be>
Cc: Martin Hannigan <hannigan@fugawi.net>, nanog@merit.edu
In-Reply-To: <a05111b1ab98470990872@[10.0.1.60]>; from brad.knowles@skynet.be on Sat, Aug 17, 2002 at 11:36:49PM +0200
Errors-To: owner-nanog-outgoing@merit.edu
--3Pql8miugIZX0722
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Brad Knowles(brad.knowles@skynet.be)@2002.08.17 23:36:49 +0000:
> At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:
>=20
> > ...ip source address that is, thought it was obvious.
>=20
> You mean, the IP address of the machine contacting you, or the IP=20
> address of the originating machine? If the former, keep in mind that=20
> many providers host a large number of customers, and you could deny=20
> service to a lot of innocent people. If the latter, then you would=20
> be vulnerable to forging.
every machine connecting to an smtp port is a potential transmitting
relay...
>=20
> > a very logical
> > algorithm would be ``n source ip adresses per /16 per minute'' which
> > would catch at least the badly distributed DDoS attacks and does not
> > impose large processing overhead in cycles and memory, i think.
>=20
> Assuming you're talking about the transmitting relay (which would=20
> be difficult to fake), this would be some additional protection.
thinking twice about the pseudo algo up there, it would be rotten easy
to DoS the systems for connections from ``well-known'' systems which
might depend on the service (latency measurement, again). one would need
to have a white list for those ip adresses.
>=20
> > i don't think that an echo service would be this popular that it
> > needs to process very many messages for the same /16 in a short period
> > of time.
>=20
> Unless someone is trying to DoS your machine. Heck, they could=20
> just generate zillions of SYN packets with random source IP=20
> addresses, and that could cause you some significant problems.
syn-cookies, where's the problem?
>=20
> > it was just a quick idea. but queueing and (rapidly) scheduled weedouts
> > of those queues are nothing new, when you guard services with gpg/pgp.
>=20
> Cron job every minute? Would you use a program to pull down the=20
> mailbox with POP3 or IMAP or somesuch, or would you directly access &=20
> process the mailbox? Or maybe pre-filter the messages with procmail=20
> into seperate mailbox files which could then be further processed by=20
> your script?
hmmm, cron job is simple, but intermediate storage of the incoming
mails might pose problems, you're prefectly right...
>=20
> What do you do if they decide to start sending you a large number=20
> of really huge messages? They could potentially fill up your mailbox=20
> space on the disk, even in just a single minute.
deliver to a filter that limits max. size of messages by lines?
then stuff its output in a fifo with a daemon listening on the other
side:
|head -n200 >/var/whereever_not_tmp/echofifo
implement the fifo listener as a small daemon that select()s on the fifo
and processes the mails.=20
regards,
/k
--=20
> "Niklaus Wirth has lamented that, whereas Europeans pronounce his name
> correctly (Ni-klows Virt), Americans invariably mangle it into
> (Nick-les Worth). Which is to say that Europeans call him by name, but
> Americans call him by value."
WebMonster Community Project -- Reliable and quick since 1998 -- All on BSD
http://www.webmonster.de/ - ftp://ftp.webmonster.de/ - http://www.rohrbach.=
de/
GnuPG: 0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4 A113 B393 6BF4 DEC9 48A6
REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--3Pql8miugIZX0722
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Comment: For info see http://www.gnupg.org
iD8DBQE9Xtd1s5Nr9N7JSKYRApf7AKCr3JM3aoqF6YmmLDyS+Da43N7x6QCfYKy0
akCkPdQ/8fTooRwOwtRfKNc=
=BC1F
-----END PGP SIGNATURE-----
--3Pql8miugIZX0722--
