Ключевые слова: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: paul@alien.ru, mactep@usa.net | 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: paul@alien.ru, mactep@usa.net | 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: maks@chat.ru, maks@cbr.astrakhan.su
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: maks@chat.ru, maks@cbr.astrakhan.su
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: butenko@stalker.com (Vladimir Butenko)
In article <366458D8.2D3DD170@escortcorp.com>, Vladimir Pastukhov
<vol@escortcorp.com> 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> = vol@escortcorp.com -- это чтобы vol@stalker.com на Вас ушел
<*bum@funny> = <ssss-*-bum@escortcorp.com> - это чтобы mmubum@funny ушел
на ssss-mmu-bum@escortcorp.com
escortcorp.com = escortcorp.com%spammer.com - это чтобы вся почта на Ваш
домен через spammer.com уходила.
Hу и так далее. Заметим, что все это хреначится по уже РАЗОБРАHHЫМ адресам,
так что не надо писать 20 правил на все варианты роутинга и возможных адресов
<vol@stalker.com: <@stalker.com:vol>, vol%stalker.com, stalker.com!vol, etc -
их можно и преобразовать, но в сложных случаях число вариантов растет
экспоненциально.
Если в таблице нету ничего - отдаем на растерзания модулям. В этот момент,
например UUCP может обнаружить, что "domain" - это собственное uucp имя ЭТОГО
хоста - и просто обнулить его (провоцируя новый цикл рутера по парсингу
"локальной части" и рутингу уже ее), или что это имя - имя какого-то
известного ууцп хоста - при этом оно может либо сразу сказать - "это мое"
(зарутить на себя), либо (что концептуальнее) - заменить доменное имя
на domain.uucp, а на себя рутить только домены вида domain.uucp.
Почему концептуальнее? А потому, что если я не хочу, чтобы на бедного
пользователя Vasya cыпалась его ууцп почта (потому как он давно уже имеет
нормальный аккаунт на другом хосте, то я впишу один раз в Рутер:
<vasya@oldhost.uucp> = 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 <vol@escortcorp.com>
--
Vladimir Butenko
Stalker Software, Inc.
--- ifmail v.2.14dev2 * Origin: Stalker Software, Inc. (2:5020/400@fidonet)
