| pask | I'm proud to introduce Mr. Jose Nazario from Monkey.org (USA) | 
| pask | Dr. Nazario holds a Ph.D. in biochemistry from Case Western Reserve University but currently works as a system  | 
| pask | verification and security analyst for an American networking company. He has been active in the Open Source software and | 
| pask | security community for several years. | 
| pask | The conference's title is Vthrottle: stopping mail viruses through libmilter | 
| pask | the audience could download some slides | 
| pask | from jose's web at monkey.org, exactly at http://monkey.org/~jose/software/vthrottle/ | 
| pask | The conference will be translated simultaneously to spanish at #redes channel and to dutch at #taee channel. The attendants could ask, just at the end of conference , at #qc channel | 
| pask | The #linux channel would remain moderated til the end of conference. | 
| pask | Ok, | 
| pask | and now, | 
| pask | jose, | 
| pask | the channel is waiting for you!! | 
| jose_n | good afternoon/day/night/morning ... my name is jose nazario. | 
| jose_n | thank you pask for that great introduction. i'm | 
| jose_n | an openbsd developer and security analyst living in ann arbor, | 
| jose_n | michigan, in the united states. | 
| jose_n | i'm going to be presenting today on | 
| jose_n | some software i wrote recently called 'vthrottle'. | 
| jose_n | as pask said, the slides for the talk are on my website here: | 
| jose_n | http://monkey.org/~jose/presentations/vthrottle.d/ | 
| jose_n | the concept behind vthrottle is not mine, it belongs to an HP | 
| jose_n | labs researcher named matt williamson.  | 
| jose_n | he and his research | 
| jose_n | group have been investigating using activity rate limiting | 
| jose_n | mechanisms to prevent network anomalies from growing too | 
| jose_n | quickly. | 
| jose_n | i became aware of this research while writing a book | 
| jose_n | on internet worms which was published last month.  | 
| jose_n | in a nutshell the technique seems to have some promise to it,   | 
| jose_n | but i'm not entirely convinced it will work for everything.  | 
| jose_n | so, i decided to write up and release some software to test it to | 
| jose_n | see how well it will work in the real world.  | 
| jose_n | this software is | 
| jose_n | only at version 0.30, but it is very stable and has most of the | 
| jose_n | features it will need for a 1.0 release.  | 
| jose_n | [slide 2] | 
| jose_n | so, very quickly, vthrottle is a mail server plugin that allows | 
| jose_n | you to modify server behavior. | 
| jose_n |  it operates at the MTA layer, or mail transport agent. | 
| jose_n | this is where the SMTP transaction occurs | 
| jose_n | between servers and clients. | 
| jose_n | this is different than your mail  | 
| jose_n | client, which is called an MUA (mail user agent) or the software | 
| jose_n | which drops the mail off into your inbox, which is called the  | 
| jose_n | LDA (local delivery agent). | 
| jose_n | vthrottle doesn't stop worms, it only slows them down.  | 
| jose_n | you'll never win the race ahead of a worm, so what you want to do is  | 
| jose_n | to try and gain some extra time to react. | 
| jose_n | to do this, and to do    | 
| jose_n | this for worms we haven't seen yet, we work on generic worm | 
| jose_n | properties.  | 
| jose_n | we never look at the payload, we only look at the | 
| jose_n | behavior of a host.  | 
| jose_n | the implementation is built as a milter plugin for sendmail | 
| jose_n | severs. | 
| jose_n | milter is the plugin architecture for sendmail, which | 
| jose_n | lets you interact with the server and make judgements about mail. | 
| jose_n | [slide 3] | 
| jose_n | let's take a few minutes and talk about libmilter. | 
| jose_n | libmilter is | 
| jose_n | the sendmail plugin architecture, as i said on the last slide. | 
| jose_n | it is a library for the client code, and the server needs support | 
| jose_n | for it as well at compile time. | 
| jose_n | it is for sendmail only, not | 
| jose_n | for postfix, qmail, exim or the like. | 
| jose_n | it provides a framework for interacting with mail by working on | 
| jose_n | state transitions within smtp. | 
| jose_n | these transitions occur when | 
| jose_n | a client connets, it says HELO, it sets the "mail from",  | 
| jose_n | who | 
| jose_n | the mail is going to, and when it sends the headers, when | 
| jose_n | the headers end, when it sends the body of the mail,  | 
| jose_n | and when the  | 
| jose_n | body of the mail ends, when the message ends, and when the | 
| jose_n | client aborts the connection. | 
| jose_n | milter clients listen on a local domain (UNIX) socket or a  | 
| jose_n | network (IPv4 or IPv6) socket. | 
| jose_n | this lets your run a single milter | 
| jose_n | server for all of your MTA farm and work with multiple SMTP | 
| jose_n | servers.  | 
| jose_n | [slide 4] | 
| jose_n | people have typically been using milter plugins for the following | 
| jose_n | four reasons. | 
| jose_n | the first is as a mail logger mechanism. this lets your copy all | 
| jose_n | of a subset of the messages that pass through a system, for | 
| jose_n | example for archiving or record keeping purposes. | 
| jose_n | the second is to use it as a statistics gatherer. | 
| jose_n | this can | 
| jose_n | be things like a mail quota information gatherer, a connection | 
| jose_n | counter, or the like. i'm looking at using this information | 
| jose_n | to further a generic worm detection and control mechanism. | 
| jose_n | the third is as an antivirus subsystem hook.  | 
| jose_n | you can feed | 
| jose_n | the antivirus software the mail message itself and return information | 
| jose_n | about the message to the server. | 
| jose_n | oops .. duplicate :) | 
| jose_n | here you can do things like | 
| jose_n | reject or pass a mail message after inspection.  | 
| jose_n | the fourth one is as an anti-spam mechanism. similar to the | 
| jose_n | antivirus mechanism, you can pass the message or header information | 
| jose_n | to the anti-spam subsystem and pass or fail messages this way.  | 
| jose_n | as i alluded to in the previous slides, milter can actually  | 
| jose_n | *do* things to your mail connections. | 
| jose_n | you can react to a  | 
| jose_n | state transition request by giving a pass code (a 200 series | 
| jose_n | reply), or a failure (400 for a temporary failure or 500 for | 
| jose_n | a permanent failure).  | 
| jose_n | coming 8.13 you can quarantine messages | 
| jose_n | using libmilter.  | 
| jose_n | you can also modify the mail as it passes through the system.  | 
| jose_n | here what you can do is add headers (such as "X-SPAM"), or | 
| jose_n | even rewrite portions of the message (such as defanging an | 
| jose_n | attachment, modifying a message body or the like).  | 
| jose_n | lastly you can copy messages silently using the milter system. | 
| jose_n | this can basically open up a file and dump the message body | 
| jose_n | into the file, including the headers and the body of the message. | 
| jose_n | [slide 6] | 
| jose_n | using libmilter is very easy to do.  | 
| jose_n | the first step is to build | 
| jose_n | a sendmail program that has libmilter support added in already. | 
| jose_n | the first step is to build | 
| jose_n | a sendmail program that has libmilter support added in already. | 
| jose_n | oops | 
| jose_n | our network broke for a bit | 
| jose_n | using libmilter is very easy to do. the first step is to build | 
| jose_n | a sendmail program that has libmilter support added in already. | 
| jose_n | then you basically add a milter call in the configuration, | 
| jose_n | forcing messages to pass the check called by the milter program. | 
| jose_n | the next thing to do is to write the milter program. what you | 
| jose_n | do is you fill in a struct which tells the program what functions | 
| jose_n | to call at what points for these state transitions within an    | 
| jose_n | SMTP transaction. | 
| jose_n | and, of course, you can set them to NULL  | 
| jose_n | if you wish them to not be evaluated. these are just function | 
| jose_n | pointers. | 
| jose_n | next you write the functions which evaluate the portion of the | 
| jose_n | SMTP transaction. | 
| jose_n | all functions can treate the body as a | 
| jose_n | string, but you have to be careful about embedded NULLs. all | 
| jose_n | methods return one of pass, fail, or reject. | 
| jose_n | within the program you need to connect to the socket you have | 
| jose_n | set up to communicate with the MTA program (a UNIX domain | 
| jose_n | socket or a network socket).  | 
| jose_n | then the last thing you need to | 
| jose_n | do is call smfi_main(), which starts the milter program. | 
| jose_n | someone asked in #qc if milter like tools exist for qmail. nope, not that i know of. | 
| jose_n | i dont use qmail, but i'm pretty sure milter wont work with qmail and support for milter like tools don't exist.  | 
| jose_n | [slide 7] | 
| jose_n | milter programs are typically written in C or C++, but bindings | 
| jose_n | have been written in Perl. perl milters have the same basic | 
| jose_n | structure as a C milter does. | 
| jose_n | it should be easy to write milter bindings for other languages | 
| jose_n | using the SWIG toolkit. | 
| jose_n | then you could write in Python, Ruby,  | 
| jose_n | tcl, C# or whatever else you like that SWIG supports. i don't | 
| jose_n | think anyone has done this yet. | 
| jose_n | [slide 8] | 
| jose_n | vthrottle works very very simply. it has three parts of the SMTP | 
| jose_n | transaction it watches.  | 
| jose_n | the first is who connects to the | 
| jose_n | mail server. the second is how you say HELO (how you start the | 
| jose_n | SMTP transaction). and the third is the address the mail is  | 
| jose_n | coming from.  | 
| jose_n | for the connection and HELO information the | 
| jose_n | hostname is kept and compared; for the "mail from" segment | 
| jose_n | an email address is used. | 
| jose_n | for each of these pieces of information, vthrottle keeps a list | 
| jose_n | of who it has seen and when they were seen. | 
| jose_n | what vthrottle | 
| jose_n | then does is it looks at the current time and the list time it | 
| jose_n | saw any of those obervations and enforces a minimum interval | 
| jose_n | between those observations. | 
| jose_n | we make two pretty bold assumptions here, first that normal hosts wont | 
| jose_n | try and send mail faster than this limit. | 
| jose_n | and the second part | 
| jose_n | of this assumption is that we figure most worms and viruses | 
| jose_n | will try and send mail faster than this limit. | 
| jose_n | like i said earlier, this isn't my idea, it's from matt williamson. | 
| jose_n | he's a researcher in the UK working for HP labs. | 
| jose_n | [slide 9] | 
| jose_n | vthrottle is very easy to install.  | 
| jose_n | first make sure that your | 
| jose_n | sendmail has support for milter build it and that you have the | 
| jose_n | milter library and headers installed. | 
| jose_n | this is part of the | 
| jose_n | normal sendmail distribution, so you dont need any special | 
| jose_n | software. | 
| jose_n | then, obviously, download the software from my site: | 
| jose_n | http://monkey.org/~jose/software/vthrottle/ | 
| jose_n | the current version is 0.30, which i released last weekend | 
| jose_n | (14 december 2003). | 
| jose_n | building vthrottle can be a bit tricky, only because i dont | 
| jose_n | have a ./configure script yet. | 
| jose_n | you need to modify the Makefile | 
| jose_n | to point it at the libmilter headers and the library. | 
| jose_n | then you can install it wherever you like. the README lists the | 
| jose_n | configuration change you need to make to your sendmail.mc file. | 
| jose_n | once you regenerate your .cf file you're all set. | 
| jose_n | you start it very simply: vthrottle -s <socket>, which is | 
| jose_n | the communications socket for the program. | 
| jose_n | you can | 
| jose_n | set a different interval time with -i (it defaults to 60 seconds right now). | 
| jose_n | you can create a "whitelist" using | 
| jose_n | -w, too. this file specifies different limits for mail addresses | 
| jose_n | or hosts. | 
| jose_n | [slide 10] | 
| jose_n | these are the big features of vthrottle right now, over its | 
| jose_n | basic behavior. | 
| jose_n | you can configure a default interval that | 
| jose_n | works for your network or your behavior. | 
| jose_n | let's say people in | 
| jose_n | your office send mail every 30 seconds on average, you can | 
| jose_n | change the behavior on the command line at runtime. | 
| jose_n | you can also whitelist hosts or mail addresses using the | 
| jose_n | whitelist function. | 
| jose_n | this is for major peer MTA systems or | 
| jose_n | mailing list addresses. you can set a different interval | 
| jose_n | for those entries. | 
| jose_n | [slide 11] | 
| jose_n | this is a basic order of operations for a mail server using | 
| jose_n | vthrottle. | 
| jose_n | when a host connects or says HELO, vthrottle looks at its | 
| jose_n | list of hosts and when they were seen.  | 
| jose_n | if it has seen the | 
| jose_n | host before, it compares the time now to when it was last | 
| jose_n | seen and how long you are supposed to wait. | 
| jose_n | if it's longer | 
| jose_n | than the required interval, then vthrottle says "ok" and | 
| jose_n | the message is allowed. | 
| jose_n | f it hasn't seen the host | 
| jose_n | before, it adds it to the list and moves on with an "ok". | 
| jose_n | if the connection is too soon, vthrottle tells the server | 
| jose_n | to reject the transaction. | 
| jose_n | when the source mail address is sent, vthrottle repeats that | 
| jose_n | check on a list of mail addresses. | 
| jose_n | if they are at least | 
| jose_n | "interval" seconds apart, then the mail can pass. if not | 
| jose_n | the message attempt fails. | 
| jose_n | whenever an attempt to send mail is prevented by a rejection | 
| jose_n | or a failure, it is logged for the administrator. | 
| jose_n | [slide 12] | 
| jose_n | vthrottle has some bugs ... some of which are my fault. | 
| jose_n | the first is that it sends a permanent failure to the | 
| jose_n | host when it tells it to go away for a connection or a | 
| jose_n | HELO request. | 
| jose_n | this is specified by the SMTP standards and  | 
| jose_n | is limited by sendmail. | 
| jose_n | the second is that the list used in vthrottle is global. | 
| jose_n | because vthrottle is threaded, it will probably destroy   | 
| jose_n | the list and make it useless ... | 
| jose_n | the third bug is more of a performance problem i expect to | 
| jose_n | see. it uses a singly linked list to look up addresses, | 
| jose_n | so performance will degrade with the number of addresses | 
| jose_n | and hosts your servers interact with. | 
| jose_n | maybe i should use | 
| jose_n | a splay tree, which is self optimizing ... | 
| jose_n | [slide 13] | 
| jose_n | this is a short list of things i plan to do with vthrottle | 
| jose_n | for a 1.0 release.  | 
| jose_n | the first is to fix sendmail with a | 
| jose_n | patch to get it to return a temporary failure for a | 
| jose_n | connection or HELO throttle action. | 
| jose_n | this should make | 
| jose_n | clients react more sanely and try again in a few minutes. | 
| jose_n | the next two i already did. you should be able to vary the | 
| jose_n | default interval, which you can now do. the third is to | 
| jose_n | improve the whitelist file syntax, and that is done, too. | 
| jose_n | lastly i need to implement a deferment queue for messages | 
| jose_n | that have been throttled. this will be trickier but will | 
| jose_n | make the server easier to manage large queues of | 
| jose_n | mail rather than hoping the client gets it right. | 
| jose_n | [slide 14] | 
| jose_n | sadly, i don't run mail servers anymore. so, i haven't | 
| jose_n | tested vthrottle in the real world. for all i know it's | 
| jose_n | dead slow and ruins your mail server.  | 
| jose_n | it could be, because | 
| jose_n | it has to traverse this linked list of information, but that | 
| jose_n | depends on the network size. | 
| jose_n | obviously i hope vthrottle doesn't have a negative impact on | 
| jose_n | normal network operations.  | 
| jose_n | the worst case scenario for | 
| jose_n | this kind of impact is that someone will be away from the | 
| jose_n | network for a while and compose a bunch of mail. when they | 
| jose_n | sit down to send it out, that "shotgun" blast of mail | 
| jose_n | will be throttled. a deferment queue will help a lot in that | 
| jose_n | regard. | 
| jose_n | [slide 15] | 
| jose_n | there are some weaknesses in the design which i want to see if | 
| jose_n | i can work around. | 
| jose_n | the first is when a host reuses its existing connection via an | 
| jose_n | SMTP RSET (reset state). what i should do here is start the | 
| jose_n | check again and pretend it connected again. should be simple | 
| jose_n | to do if libmilter has a handler for RSET ... | 
| jose_n | the second is the situation when the virus spoofs the HELO | 
| jose_n | information. remember you can send anything you want here, | 
| jose_n | and the server doesn't have to verify it. i imagine some | 
| jose_n | viruses already do this. | 
| jose_n | the mail. in the absence of strong authentication (ie via | 
| jose_n | TLS) of the sender, there is no way around this one. | 
| jose_n | [slide 16] | 
| jose_n | and that's it! i need to thank matt williamson and the | 
| jose_n | management team at HP labs, they were comfortable | 
| jose_n | enough with someone else releasing a product which | 
| jose_n | does what their patent pending process does. :) | 
| jose_n | you can see the latest release of vthrottle on its homepage: | 
| jose_n |   http://monkey.org/~jose/softwaree/vthrottle/ | 
| jose_n | the website needs sexy graphics if you feel like contributing. | 
| jose_n | i have some ideas but i'm not a good artist. | 
| jose_n | lastly this took only a few hours to write and extend, | 
| jose_n | but getting it up to version 0.30 took about 400 lines of C | 
| jose_n | code and about 6 hours of work. | 
| jose_n | thank you :) | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| MJesus | clap clap clap clap clap clap clap clap clap clap | 
| fernand0 | plas plas plas plsa plas plas plas plas plas plas | 
| fernand0 | plas plas plas plsa plas plas plas plas plas plas |