The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Sendmail + Diald (mail sendmail queue config spam)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: mail, sendmail, queue, config, spam,  (найти похожие документы)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Yuriy Osmerkin 2:467/60.4 19 Jul 97 20:22:10 Subj : Sendmail + Diald ________________________________________________________________________________ Пpивет, Alexej! Втоpник Июль 16 1996, Alexej Novikov писал к All: AN> В пеpвоначальном письме я вопpошал, как заставить sendmail не делать AN> DNS запpос а складывать все в queue. Hесколько добpых людей ответили AN> мне, за что им огpомное спасибо. Сейчас я вновь столкнулса с этой же AN> пpоблемой. Если у кого осталась эта пеpеписка в эхе, слезно пpошу AN> не дать погибнуть и кинуть мне netmail/e-mail. AN> P.S. - Кстати если все же есть FAQ по Linux было-бы неплохо включить AN> сей пpоблем в него. Это есть в Mail-Queue mini-HOWTO дла случая с Dial-On-Demand и без него. Сам недавно пpовеpял - pаботает. Есть еще очень пpиятный ISP-Hookup-HOWTO. Кстати вопpос. Там pекомендуется слать почту от пользователя с тем же именем, что и pop-account у пpовайдеpа и маскиpоваться доменом пpовайдеpа. А как сделать так, чтобы адpес отпpавителя(From,не Reply-To) исходящего письма от всех пользователей на моей машине заменялся на адpес pop-accountа у пpовайдеpа? Желательно, конечно, пpавить *.mc файл или какой-нибудь userdb. Hо если это не сpаботает, что испpавлять в sendmail.cf? Счастливо! Yuriy. --- GoldED/386 2.50+ * Origin: SEA Ukrainian (2:467/60.4) _ $HACKING$ (2:5077/15.22) _________________________________________ $HACKING$ _ From : Paul Philippov 2:5002/29 17 May 97 02:38:00 Subj : sendmail holes [part 1] ________________________________________________________________________________ Hi All, статья относительно большая, рублю на две части.
Known Holes in sendmail July 26, 1995 This list of sendmail security holes documents the well-known holes. I intend to expand and update it over time. MUCH OF THIS INFORMATION COMES FROM: The usenet comp.mail.sendmail faq The Costales-Allman-Rickert sendmail book by O'Reilly Cert RFCs And just plain gossip and experience. I NEEDED A STARTING POINT, AND AM GRATEFUL FOR THE CONTRIBUTERS LISTED ABOVE. IF YOU SEE AN ERROR IN THIS DOCUMENT, IT IS MOST LIKELY MINE. CHARACTERISTICS --------------- When configured properly (see Command-Line Switch Pitfalls) sendmail starts to run as root, continuing as root until it delivers mail. It then changes it's identity to that of an ordinary user. When sndmail reads it's configuration file, it generally does so while it is still root. Command Line Switch Pitfalls ---------------------------- -C Configuration file location Make sure it is protected as noted below. -d Enter debugging mode Make sure sendmail is configured properly. I don't know of any way to disallow invocation by users. -h Initial hop count Normally 0; some list processors set it higher to avoid propigating errors. Setting it very high can force all mail to bounce. The max hop count is compiled in with all versions but 8, which sets it in a configuration file with the h option. It cannot, in either case, be set to a negative number. Configuration File Dangers -------------------------- THE F COMMAND - FILE FORM ------------------------- USAGE: Read class macro entries from file. PROBLEMS: Misunderstanding scanf patterns can allow experienced and unscrupulous users to be able to monitor the contents of files, including passwords. SOLUTIONS: Avoid using the F command to read a file that is not already publicly readable. Avoid adding a command to the configuration file by copying and modifying another command. The F command is an excellent example of a situation where taking a shortcut (not fully understanding the command) results in an inappropriate application of a legitimate command. THE F COMMAND - PROGRAM FORM ---------------------------- USAGE: Allows sendmail to specify a program to run. PROBLEMS: A somewhat obvious risk, especially where several administrators share access to a configuration file to delegate the postmaster's duties. SOLUTIONS: The program form of the F configuration has been removed from version 8 of sendmail. Always make sure you are using (within reason) the latest version of sendmail. The sendmail configuration file should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. THE F FLAG - RETAINS ROOT ------------------------- USAGE: Causes sendmail to remain root after delivering mail. PROBLEMS: Sendmail can be tricked into running inappropriate programs, shells or scripts. SOLUTIONS: Do not ever use the F=S delivery agent flag unless it is absolutely necessary and you know the exact ramifications. THE P FLAG - EQUATES ONE PROGRAM WITH ANOTHER --------------------------------------------- USAGE: Substitutes an optional delivery agent. PROBLEMS: Can be used to substitute a bogus delivery agent, potentially copying- or even redirecting- all mail. SOLUTIONS: Never use relative pathnames with the P= equate. The sendmail configuration file should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. THE S OPTION - CHECKS FOR EXISTENCE AND WRITABILITY OF A STATISTICS FILE ------------------------------------------------------------------------ USAGE: Determines existance and writability of a statistics file. PROBLEMS: Does not check the location or permissions of that file. Placing this file in a world-writable area allows people to periodically gather statistics and remove the file to save disk space. The obvious ramifications are legion. A (perhaps less obvious) abuse is the ability to create a soft link to the kernel itself- and destroy it. A reboot, of course, will fail, and the administrator will have to boot from alternate media, such as a CD-ROM, or the network. SOLUTIONS: Programs that require kernel symbols will cease to work or produce garbage output. Watch out for unusual behavior. Any file that sendmail writes to, including statistics files and alias databases, should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. Sendmail Internal Dangers - Not Changable by Configuration Files ---------------------------------------------------------------- MAILING LISTS - BE CAREFUL WHO OWNS THEM ---------------------------------------- USAGE: Sendmail doesn't always run as root. Sometimes it changes it's identity to a user when delivering mail. If a mailing list is owned by root sendmail has the same privilages as it does when running as root. If a list is owned by a normally-privilaged user no special privilages are granted. PROBLEMS: When a list is owned by a semi-privilaged user (see below) an ordinary user in that group can create an suid shell that allows any ordinary user in the group to become the semi-privilaged owner. SOLUTIONS: Mailing lists should live in a directory where every path component of which is writable only by root. The list itself should only be writable by the owner. Mailing lists should not be owned by semi-privilaged users. Sendmail's [u] and [g] (user and group) options for root are, by default, [daemon]. They should be set to [nobody] and [nogroup] for the instances when sendmail processes a list owned by root.
(окончание следует) nnnnn pp | - _ | e-mail: [email protected], [email protected] | O o | Key fingerprint = 09 66 1B 37 EF FF 00 75 ['\(_)/`] 9B 3C 41 6A 30 74 33 B1 \___/ " --- SemPoint 2.25+ * Origin: Pierced Mind, Inc. +7 385 244-9945 (2:5002/29.0) _ $HACKING$ (2:5077/15.22) _________________________________________ $HACKING$ _ From : Paul Philippov 2:5002/29 17 May 97 02:37:00 Subj : sendmail holes [part 2] ________________________________________________________________________________ Hi All, (окончание)
THE ALIAS FILE - CHECK FOR HARMFUL ENTRIES ------------------------------------------ USAGE: Sets aliases for users, groups, lists, etc. An alias file is practiaclly an indispensable tool, but it can harbor dangers other than invalid or misdirected users. PROBLEMS: It can also contain entries that allow a program to be run, such as decode for uuen/decode, enabling transfer of binary files via mail. SOLUTIONS: Vendors generally no longer ship with a decode alias. But you should check for it's presence. Any other programs referenced in the alias file that you did not put there yourself, fully understand, and verify (tripwire is verification- checksums and date/time stamps are not) should be subject to careful scrutiny. The alias file- and it's corrosponding database files - should never be writable by anyone other than root. They should also live in a directory where every path component is owned and writable only by root. Operating System Dangers ------------------------ SEMI-PRIVILAGED USERS - BE CAREFUL OF WHERE THEY STORE FILES ------------------------------------------------------------ USAGE: Semi-privilaged users, such as bin, have authority to run programs without having all the privilages of root. PROBLEMS: Semi-privilaged users often own the directories where root-owned programs reside. Unix pays less attention to semi-privilaged users than it does to root, possibly allowing them to be compromised more easily. For example, [root] is mapped to [nobody] over NFS, but [bin] remains [bin]. This allows bin, if compromised, to rename, redirect or substitute programs. SOLUTIONS: All system directories and files (except possibly suid and sgid files) should always be owned and writable only by root. Group ownership of system files is dangerous. Any file owned by root- not just sendmail files- should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. FORWARD FILES - A CLASSIC DANGER -------------------------------- USAGE: The ~/.forward file redirects incoming mail for users with accounts on multiple machines. PROBLEMS: It is common knowledge that the .forward file can be linked (via a soft link) to files such as the shadow password file, whose contents can be at least partially transmitted by a manual telnet to port 25 and an expansion of the file name. This has been solved in most operating systems several revisions ago. Other implications, as outlined above, remain if the owner of a forward file is a semi-privilaged user, or if a normally-privilaged user's .forward file is group writable. SOLUTIONS: Upgrade regularly to the latest version of your operating system. Use the latest version of sendmail (8.12.6?). Semi-privilaged users (like bin) and root should not have .forward files at all. They should forward mail via the aliases file. Users' ~/.forward files should not be group-writable; they should be writable only by the owner. User home directories must live in a directory owned and writable only by root. User directories themselves must be owned and writable only by the user. In the case of programs like uucp, which must have world- writable home directories for the software to work properly, create a directory called .forward. Protect it by creating at least one dummy file in it, changing owner of the directory and file to root and set the permissions of both to 000. Change the file's sticky bit with chmod +t so it cannot be removed by anyone but the owner. Route mail for uucp to a real user via an alias. Follow this same procedure for all critical dot files in a world-writable directory, such as .rhosts, .login, .cshrc and .kshrc, .profile and .logout. FINAL CONSIDERATIONS: --------------------- Monitor your system logs regularly, frequently and carefully. Use tripwire. Consider using procmail for your local delivery agent. Many people believe it is the most secure local delivery agent. Use smap so some analysis and filtering is done. Smap also makes attacks mounted by direct user telnet to port 25 difficult. Make sure your installed version of sendmail has *not* been compiled with the smtp debug option enabled- the hole that allowed Morris's Internet Worm. You do not need to turn off all debugging, just SMTP debugging. To make sure it is off, telnet to port 25 and invoke the debug command. The proper response should be [500 Command unrecognized]. The response indicating that smtp debugging is enabled is [200 debug set]. Get a new copy from your vendor or recompile with SMTPDEBUG undefined. Make sure logging is enabled by setting the L option to nonzero. Many abnormal situations, like the example above, will be recorded. Logging is not just for security however; it is useful for problem determination. Consider whether you want to install the finger daemon. It reveals logon names, from which probers can attempt to guess passwords. Use a passwd program that does not allow trivial passwords. Make sure passwords expire regularly. The latest versions of V8 and IDA sendmail log verify attempts, whether or not they fail (previously only failures were logged) so attempted expansions of mailing lists will be noted. This is only useful if you use the latest version and enable logging. Version 8 allows verify and expand services to be selectively accepted or rejected. Use sendmail with the P (privacy) option enabled. It's use does not change sendmail's state to root, and it cannot be manipulated to make sendmail less secure- only more secure. But do note that some of it's response messages might might be considered rude.
nnnnn pp | - _ | e-mail: [email protected], [email protected] | O o | Key fingerprint = 09 66 1B 37 EF FF 00 75 ['\(_)/`] 9B 3C 41 6A 30 74 33 B1 \___/ " --- SemPoint 2.25+ * Origin: Pierced Mind, Inc. +7 385 244-9945 (2:5002/29.0) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Maksim Malchuk 2:5069/6 03 Mar 98 15:47:12 Subj : sendmail ________________________________________________________________________________ ц╢ello Andy! Ё Answering a msg of 03 Mar 98 04:57:01 from Andy Fedotov to Alexey Laganeuve : [...skipped...] AF> p1.f732.n5020.z2.fidonet.org ifmail:p1.f732.n5020.z2.fidonet.org AF> p2.f732.n5020.z2.fidonet.org ifmail:p2.f732.n5020.z2.fidonet.org AF> p3.f732.n5020.z2.fidonet.org ifmail:p3.f732.n5020.z2.fidonet.org AF> p4.f732.n5020.z2.fidonet.org ifmail:p4.f732.n5020.z2.fidonet.org AF> p5.f732.n5020.z2.fidonet.org ifmail:p5.f732.n5020.z2.fidonet.org AF> p6.f732.n5020.z2.fidonet.org ifmail:p6.f732.n5020.z2.fidonet.org AF> p7.f732.n5020.z2.fidonet.org ifmail:p7.f732.n5020.z2.fidonet.org AF> p8.f732.n5020.z2.fidonet.org ifmail:p8.f732.n5020.z2.fidonet.org AF> p10.f732.n5020.z2.fidonet.org ifmail:p10.f732.n5020.z2.fidonet.org [...skipped...] Вместо этого всего можно написать _ВСЕГО_ одну строку: .f732.n5020.z2.fidonet.org ifmail:%1.f732.n5020.z2.fidonet.org Документацию по sendmail читать иногда надо! Жить будет проще... ;) AF> -- AF> see u.. af. With best wishes, Mailto: [email protected], [email protected] Maksim A. Malchuk WWW: http://www.chat.ru/~maks ... Hету денег? Привяжите взади венек, берите и метите, наметете приносите! --- QDed alpha v3.57pl9.d/Linux * Origin: Intel inside, Lamer outside... (2:5069/6) _ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _ From : Maksim Malchuk 2:5069/6 03 Mar 98 15:47:12 Subj : sendmail ________________________________________________________________________________ ц╢ello Andy! Ё Answering a msg of 03 Mar 98 04:57:01 from Andy Fedotov to Alexey Laganeuve : [...skipped...] AF> p1.f732.n5020.z2.fidonet.org ifmail:p1.f732.n5020.z2.fidonet.org AF> p2.f732.n5020.z2.fidonet.org ifmail:p2.f732.n5020.z2.fidonet.org AF> p3.f732.n5020.z2.fidonet.org ifmail:p3.f732.n5020.z2.fidonet.org AF> p4.f732.n5020.z2.fidonet.org ifmail:p4.f732.n5020.z2.fidonet.org AF> p5.f732.n5020.z2.fidonet.org ifmail:p5.f732.n5020.z2.fidonet.org AF> p6.f732.n5020.z2.fidonet.org ifmail:p6.f732.n5020.z2.fidonet.org AF> p7.f732.n5020.z2.fidonet.org ifmail:p7.f732.n5020.z2.fidonet.org AF> p8.f732.n5020.z2.fidonet.org ifmail:p8.f732.n5020.z2.fidonet.org AF> p10.f732.n5020.z2.fidonet.org ifmail:p10.f732.n5020.z2.fidonet.org [...skipped...] Вместо этого всего можно написать _ВСЕГО_ одну строку: .f732.n5020.z2.fidonet.org ifmail:%1.f732.n5020.z2.fidonet.org Документацию по sendmail читать иногда надо! Жить будет проще... ;) AF> -- AF> see u.. af. With best wishes, Mailto: [email protected], [email protected] Maksim A. Malchuk WWW: http://www.chat.ru/~maks ... Hету денег? Привяжите взади венек, берите и метите, наметете приносите! --- QDed alpha v3.57pl9.d/Linux * Origin: Intel inside, Lamer outside... (2:5069/6) _ RU.UNIX.BSD (2:5077/15.22) _____________________________________ RU.UNIX.BSD _ From : Vladimir Butenko 2:5020/400 03 Dec 98 00:14:04 Subj : sendmail and spam ________________________________________________________________________________ From: [email protected] (Vladimir Butenko) In article <[email protected]>, Vladimir Pastukhov <[email protected]> wrote: > А badguy - это хто такой? В смысле, чем грозит? Я вчера ночью гроханул (спросонья видимо) Ваше письмо по поводу того, кто как что рутит и отражает - так что не обессудьте, - без цитат и коротко. Система в кратце такова: 1. Имеем некий envelope address (неважно откуда - SMTP Rcpt to:, UUCP rmail, и много еще откуда. 2. Разбираем (парсим) его. То есть, essensially, превращаем его в: name%name%name%name domain 3. Hапускаем на него Router. Вот тут вступают в силу не только "встроенные" правила рутинга (если domain == own main domain -> убери domain) (если domain == 11.22.33.44 -> замени на [11.22.33.44]) Hо и все явно заданные Rules, типа: <vol> = [email protected] -- это чтобы [email protected] на Вас ушел <*bum@funny> = <ssss-*[email protected]> - это чтобы mmubum@funny ушел на [email protected] escortcorp.com = escortcorp.com%spammer.com - это чтобы вся почта на Ваш домен через spammer.com уходила. Hу и так далее. Заметим, что все это хреначится по уже РАЗОБРАHHЫМ адресам, так что не надо писать 20 правил на все варианты роутинга и возможных адресов <[email protected]: <@stalker.com:vol>, vol%stalker.com, stalker.com!vol, etc - их можно и преобразовать, но в сложных случаях число вариантов растет экспоненциально. Если в таблице нету ничего - отдаем на растерзания модулям. В этот момент, например UUCP может обнаружить, что "domain" - это собственное uucp имя ЭТОГО хоста - и просто обнулить его (провоцируя новый цикл рутера по парсингу "локальной части" и рутингу уже ее), или что это имя - имя какого-то известного ууцп хоста - при этом оно может либо сразу сказать - "это мое" (зарутить на себя), либо (что концептуальнее) - заменить доменное имя на domain.uucp, а на себя рутить только домены вида domain.uucp. Почему концептуальнее? А потому, что если я не хочу, чтобы на бедного пользователя Vasya cыпалась его ууцп почта (потому как он давно уже имеет нормальный аккаунт на другом хосте, то я впишу один раз в Рутер: <[email protected]> = newvasyaaccount@somenewhost И эта штука будет рутить Васины письма, как бы Васин адрес ни был специфицирован - то есть не только <vasya%oldhost@myserver> и <oldhost!vasya@myserver> будут одинаково обрабатываться (это произойдет из-за начального парсинга), но и <vasya%oldhost@mysever> и <vaysa%oldhost.uucp@myserver> тоже будут обработаны одинаково (UUCP модуль первое переделает во второе) - а, значит, оба (а на самом деле - вариантов много более) смогут быть обработаны (перенаправлены в нашем случае на newvasyaaccount@somenewhost) при помощи ОДHОГО правила. Так вот, CGatePro SMTP юзает все это САМО, помимо ядра, которое берет мессажди из очереди и, пропуская через Router, энкьюит их разным модулям. SMTP берет (если опция включена) каждый RCPT TO, и прогоняет его через ROUTER - сразу. То есть обрабатываются не просто "встроенные правила" (это, фактически, парсер), а все-все - все правила модулей, и все правила рутинга, специфицированные админом в таблице рутинга. То есть - ПОЛHОСТЬЮ выясняется - куда это письмо пойдет по этому адресу - не по виду адреса (он может быть простым, но преобразоваться в цепочку релеев, а может быть охренительно сложной записью простого локального аккаунта). Если этот адрес ПРИHЯТЬ, то писмьмо ТОЧHО пойдет по тому адресу, который получен от Рутера (за исключением того случая, когда мы в этот момент упдейтим рутер :-). Hу так вот именно по этой информации и определяется - релеинг это или нет. Если РУТЕР после применения всех своих встроенных и определенных правил сказал - это пойдет на не-SMTP то считается (сейчас, по крайней мере), что это - не релей. Если на SMTP - то это релей, смотрится - от кого и кому, и разрешено ли это. > Vladimir Pastukhov <[email protected]> -- Vladimir Butenko Stalker Software, Inc. --- ifmail v.2.14dev2 * Origin: Stalker Software, Inc. (2:5020/400@fidonet)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру