| amb | Hi |
|---|
| Vegas | hey amb |
|---|
| amb | Shall I begin to translate? |
|---|
| Vegas | amb will make the english translation of the lecture being hold on #infosec |
|---|
| Vegas | k amb |
|---|
| Vegas | u can start |
|---|
| Vegas | subject is Experience of INFOMED in the fight against virii amb |
|---|
| Vegas | he didn't know he was gonna make it 2 minutes ago :\ |
|---|
| amb | During the year 200 the council of infomed got together to talk about computer virii, this wasn't something new |
|---|
| amb | During the past years we had already fought against some famous cases in our network |
|---|
| amb | In that period the antional health ministerium had already done a great job on moving their intitutions toward |
|---|
| amb | the computer science area, specially the internet |
|---|
| amb | And of course email |
|---|
| amb | And at the same time, like always in humanty, they felt a great curiosity towards the new technologies |
|---|
| amb | As the national network got bigger and more stable the number of IP links between states and institutions |
|---|
| amb | Got bigger, as well as the connection speed |
|---|
| amb | In thjose conditions it seemed that each time a new virus appeared in the internet |
|---|
| amb | it would rapidly grow in those networks |
|---|
| amb | But in those years the propagation of virii |
|---|
| amb | was relatively simple to stop, bercause generally the attachment |
|---|
| amb | had a name or a number of names that were well known |
|---|
| amb | Or the sender was the same, |
|---|
| amb | thus the worst moment was the one between the entrance in our network |
|---|
| amb | and the moment the rules to stop tits propagation were initiated |
|---|
| amb | But still the problems this caused to our users were growing every day |
|---|
| amb | As I already mentioned the directing group of infomed |
|---|
| amb | analized the problem and reached the following conclusions: |
|---|
| amb | 1 - There is a continual rise of computer virii that reach the infomed network |
|---|
| amb | 2- Also a rise of users in Infomed |
|---|
| amb | This last point due to the rise of institutions connected to out network |
|---|
| amb | Another problem is: |
|---|
| amb | 3- The users can't download updates of different applications from the net, including Antivirus tools |
|---|
| amb | 4- Our users don't possess a lot of knowledge in the computer-science area, specially in the virus/security field |
|---|
| amb | This last point is mainly because of two reasons |
|---|
| amb | first: The massive introduction of computers in our society is a recent phenomenon |
|---|
| amb | 2nd: There are very few courses on computer science |
|---|
| amb | This last point is due to: |
|---|
| amb | Out internal links and with the ISP are saturated because of, in a big part, the number of virus that travel in our network |
|---|
| amb | In our meeting a series of decisions were taken that would allow to start solving the identified problems |
|---|
| amb | Some of them were: |
|---|
| amb | 1st: Create a strategy to educate out users in the computer science area |
|---|
| amb | This demands that: |
|---|
| amb | GAU distributes advertencies of virii to the users |
|---|
| amb | (GAU means User Attention Group) |
|---|
| amb | It's a department whose mission is to take care of the users :-) |
|---|
| amb | Well, I'll go on: |
|---|
| amb | GAU starts giving courses on basic computer security to our users. |
|---|
| amb | This was the first decision, but it was also decided that we had to: |
|---|
| amb | Implement a mail-client with a web interface, i.e. a webmail |
|---|
| amb | so the users could see if their mails contained attachments without needing to download them, so it would be possible to eliminate directly those that arise suspicion |
|---|
| amb | and |
|---|
| amb | Those virii that would manage to get executed on a PC of the users won't be able to resend themselves |
|---|
| amb | Because the contact list isn't available locally |
|---|
| amb | The last decicion of the meeting was that: |
|---|
| amb | 1st: All emails that enter and leave the network, as well as those that move internally, will have to be scanned for virii |
|---|
| amb | 2nd: The updates of the central antivirus archive will have to be done automatically. |
|---|
| amb | The implementations of these solutions was a gradual process, starting with the simplest that could be done without spending money on new technical equipment |
|---|
| amb | The first two points were the firsts ones to be inmplements |
|---|
| amb | Nowadays the GAU continues to organize the courses with a very good reception |
|---|
| amb | *acbetween the users |
|---|
| amb | <sorry> |
|---|
| amb | And also very good results, and two discussion groups have also beed started |
|---|
| amb | one for decontamination tools, news, antivirus & co |
|---|
| amb | the other one for urgent news. |
|---|
| amb | Also, the use of webmail had contrbuted to reduce the number of virii |
|---|
| amb | Because the number of virii that exploit navigators' vulnerabilities are less than those that exploit email clients vulns. |
|---|
| amb | Also effective was that out webmail configuration didn't allow displaying emails that are written in the html format |
|---|
| amb | They are shown as attachments |
|---|
| amb | The implementation of a central antivirus was delayed |
|---|
| amb | because we didn't have the needed hardware for this task at that time. |
|---|
| amb | I remind you that at the most critical moment our mail server was a dual pentium with 192 MB RAM and it served the email of more than 4000 users |
|---|
| amb | And it also managed the mails of the provincial nodes and other mental institutions |
|---|
| amb | Because of it, it wasn't very restricted and didn't limit the propagations of virii in any sense |
|---|
| amb | So freedom was given to the different nodes to become independent, and antivirii were installed on all of them to manage that huge volume of mails |
|---|
| amb | Once better equipment became available (dual P3 with 1Ghz and 1Gb RAM) |
|---|
| amb | The situation changed, we were able to install the central antivirus |
|---|
| amb | Then a study was done about the different products that were available |
|---|
| amb | Important points for us were: |
|---|
| amb | 1st: Maximum compatibility with sendmail, it would have to need a minimum amount of configurations changes |
|---|
| amb | 2nd: The capacity to process large numbers of emails |
|---|
| amb | 3rd: The system resources was limited, specially since the user volume grows exponentially as well as the connection facilities |
|---|
| amb | 4th: It would have to be totally, or at least in it's main modules, free software |
|---|
| amb | In this study the following site helped a lot: |
|---|
| amb | http://www.linuxsecuritycentral.com/resources.php?title=Anti-Virus |
|---|
| amb | We decided to use Mailscanner, the profesionality of the place and the statistics that it shows made us try it out resulting in a total and great compatibility with sendmail and thus with our system |
|---|
| amb | Now we would only have to choose the antivirus itself, the "engine" that mailscanned uses |
|---|
| amb | We had two options at that moment: mcafee and mofos |
|---|
| amb | We chose mcafee |
|---|
| amb | nowadays mailscanner supports more antivirus but all but one are commercial and closed ones, just like mcafee |
|---|
| amb | So we mantain the orginal scheme |
|---|
| amb | At this moment I think I should explain some details regarding our mailscanner implementation and its configuration |
|---|
| amb | We, just like many cuban networks, still use UUCP as the mail exchange protocol, although it is an ancient ptotocol and in desuse |
|---|
| amb | In the internet, but in Cuba it still has a lot of importance, even in IP networks like our own |
|---|
| amb | Once the mail has been exchanged through the UUCP applications |
|---|
| amb | These are distributed to their final destination directly using Sendmail |
|---|
| amb | and the messages delivered this was are not checked by mailscanner in it's default configuration! |
|---|
| amb | This meaned that the messages that came from our UUCP nodes weren't checked for virii |
|---|
| amb | Same can happen with any other mail client that works through direct sendmail invocation, like the console clients and the webmail clients |
|---|
| amb | but those are not risky, at least as far as windows virii are concerned :-) |
|---|
| amb | Well, the necessary chanfes that are needed in the startup configuration of RedHat's sendmail are minimal but important |
|---|
| amb | And a bit more complex than those that tmailscanners' author suggests |
|---|
| amb | They are going to be dealed now: |
|---|
| amb | Mailscanner recommends that sendmails' configuration stays unmodified and that the only changes should be the startup options of the sendmail that runs in the backgroung |
|---|
| amb | It recommends that sendmail is started with these options: |
|---|
| amb | sendmail -bd -ODeliveryMode=queueonly -OqueueDirectory=/var/spool/mqu eue.in |
|---|
| amb | And the other instance: |
|---|
| amb | sendmail -q15m |
|---|
| amb | So that all messages that are served thourgh smtp will be ports in the /var/spool/mqueue.in and that the mailscanner will check them and put the "clean" ones in |
|---|
| amb | /var/spool/mqueue where sendmail, every 15 mins, will deal with them. |
|---|
| amb | In this scheme every message that is served through direct invocation of sendmail will be put directly in /var/spool/mqueue |
|---|
| amb | And will be servede inmediatly without checking |
|---|
| amb | This is so because the sendmail configuration (/etc/sendmail.cf) |
|---|
| amb | hasn't been changed consequently. |
|---|
| amb | Identified the problem and understood the problem it was easy to find the solution |
|---|
| amb | The first thing we had to do was modify sendmails' configuration, something that wasn't much of a püroblem due to our previous configuration |
|---|
| amb | The change was simple, we had to define that the way sendmail works by default is queueonly and that the directory for the que is /var/spool/mqueue.in |
|---|
| amb | using the .mc file it is very simple |
|---|
| amb | We only have to add these 2 options: |
|---|
| amb | define(`confDELIVERY_MODE',`queueonly')dnl |
|---|
| amb | This one is for specifying the "que only" |
|---|
| amb | To set the directory: |
|---|
| amb | define(`QUEUE_DIR',`/var/spool/mqueue.in')dnl |
|---|
| amb | The details can be found in the /usr/share/sendmail-cf/README directory in RedHat |
|---|
| amb | Once the sendmail.cf file is created we will have to edit the sendmail-daemon startup options in this new context |
|---|
| amb | The options need to be: |
|---|
| amb | sendmail -bd |
|---|
| amb | i.e., launch sendmail to the background listening on port 25 |
|---|
| amb | And this other instance: |
|---|
| amb | sendmail -q15 -0queueDirectory=/var/spool/mqueue |
|---|
| amb | BNecause sendmail already "knows" it has to work in queueonly and that the dir it has to put the msgs in is /var/spool/mqueue.in |
|---|
| amb | but to the daemon in charge of checking the queue directory for delivering the messages that are left by the antivirus |
|---|
| amb | We have to specify anpther directory, the directory where mailscanner will put the clean mails in, i.e. /var/spool/mqueue |
|---|
| amb | And that is precisely the last option |
|---|
| amb | In RedHat Linux there is a better method to pass these options to sendmail |
|---|
| amb | and that is using the /etc/sysconfig/sendmail file |
|---|
| amb | That way we avoid breaking the configuration in case of a sendmail update |
|---|
| amb | With these modifications we resolve the problem of verifying the mails distributed by UUCP |
|---|
| amb | Sorry to have bored the non-cuban listeners because they probably won't have heard of UUCP |
|---|
| amb | But anyway, I hope that our experience will help you in case you want to check all mails that pass through the mail server |
|---|
| amb | To finish this talk about out experience using the mailscanner I will say that |
|---|
| amb | we had a period of time in which we daily had some bad news :-( |
|---|
| amb | Out server has RedHat installed |
|---|
| amb | (7.2) |
|---|
| amb | And it happened that when RedHat decided to go from the 2.4.9 kernel to the 2.4.18 in one of it's mistakes, our system collapsed, literally collapsed |
|---|
| amb | It couldn't hold the traffic abd it always got to the point where it brought the server down |
|---|
| amb | I am not an expert with the kernel but I knew the change between the version 2.4.9 and the 2.4.10 when Linus cganged all the virtual memory handling |
|---|
| amb | and I believe that this is the reason for RedHat's delay in the version change |
|---|
| amb | But well, we couldn't use the new version of the kernel |
|---|
| amb | The fault was of the mailscanner or it's "backend", perl, and so we spend a lot of time |
|---|
| amb | During which the RedHat kernel was compiled again and again with equally bad results |
|---|
| amb | We asked in discussion groups, in RedHat's bugtrack but to no avail |
|---|
| amb | Finally, when it was impossible to continue with the outdate of the kernel it was decided to try with one of Alan Cox's tree, vola!!! |
|---|
| amb | Using the same .config we had for RedHat, everything went much better than with the old kernel |
|---|
| amb | I comment this anecdote because it might help someone, even if it's not easy to dupplicate, because I believe that it was perls' fault |
|---|
| amb | because we had some leads that on other servers that were lightly stressed where periodic application also degrade the servers resources for some moments |
|---|
| amb | aand those apps are also written in perl |
|---|
| amb | These are our experiences with the email virii, at least as far as stopping them in the linux-server level |
|---|
| amb | But I didn't want to finish without commenting some statistics that might help someone who hasn't yet decided to install an antivirus in their linux server. |
|---|
| amb | :-) |
|---|
| amb | In the page http://ww.linux.cu/usuarios/roger/Mensajes-vs-Virus2.html |
|---|
| amb | You can view a recent statistic about MailScanner's work on our server |
|---|
| amb | As you can see 170000 nails pass thorugh our server during workdays, monday to friday, this means |
|---|
| amb | more or less 7000 per hour or 110 per minute |
|---|
| amb | Out of these approx. 2500 are mails with virii, stopped by mailscanner of course, and sometimes there are explosions when we even reach 10.000 mails daily with virii |
|---|
| amb | This happens when a new one comes out :-) |
|---|
| amb | For example when the last bugbear variant came out the number of detected virii went up from 300 to 3000 |
|---|
| amb | Nonetheless, only approx. 1% of the mails are infected, a small number |
|---|
| amb | And lastly (This time for real *g*) I wanted to say that the work of the GUA (User Atention Group, remember?) together with the instinct of securing |
|---|
| sorry, forgot the word *g* | :-) and the ones one is responbsible of |
|---|
| amb | has been translated to a low number of incidents with virii on PC's on our users' home-PC's |
|---|
| amb | This conclusion has been taken from the graphs, because even when our total traffic goes down to less than the hal-workday-level during the weekend |
|---|
| amb | The number of virii goes down to even 8 times the normal value |
|---|
| amb | It seems that our users that are in the institutions don't worry about virii or maybe they believe it's the administrators responsability and just forget about security :-( |
|---|
| amb | Ok, that's all! |
|---|
| amb | <THE END> |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | clap clap clap clap clap clap clap |
|---|
| Vegas | well done amb |
|---|
| Vegas | you've been great dude |
|---|
| amb | lol, not really, the finished on the other chan long long ago :-)> clap clap clap clap clap clap clap clap clap clap> clap clap clap clap clap clap clap clap clap clap> clap clap clap clap clap clap clap clap clap clap> clap clap clap clap clap clap clap clap clap clap> clap clap clap clap clap clap clap clap clap clap> amb.... impresionante!!!!!!> thanks you very much amb !! |
|---|
| amb | Glad to help, lol |
|---|
| Vegas | :) |
|---|
| Vegas | we really had nobody and you came and... and... in like 2 minutes you came and start to translate the lecture |
|---|
| Vegas | thanks really much again |
|---|
| Vegas | appreciate it |
|---|
| amb | lol, np, it was fun :-) |
|---|
| Vegas | you didn't even know what was the topic lol> :)))) |
|---|
| Vegas | anyway thank you dude :)> congratulations amb... nobody know who traslate as fast as you ! |
|---|
| jj | buenas |
|---|
| Vegas | lol |
|---|
| amb | rotfl |
|---|
| amb | ok, I'll leave you then :-) |
|---|
| amb | If you ever need (and want) my help tell me |
|---|
| amb | cya |
|---|