Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | | | |
Не то чтобы лень :) 11.11.03 11:19 Число просмотров: 1495
Автор: !mm <Ivan Ch.> Статус: Elderman
|
Просто я например MS Exchange не использую (корпоративный стандарт, но мне он не нравится в силу своей глючности и тормознутости).
Пофигизм MS - притча во языцах.
Они, конечно, в SP исправляют ошибки, которые признавать не желают, но в это время ошибки используются всеми, кем только можно.
|
|
<sysadmin>
|
Всё так страшно 04.11.03 11:22
Автор: void <Grebnev Valery> Статус: Elderman
|
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS03-046.asp
И самое главное, как в этом поучаствовал сам мелкософт ;)))) Предлагаю обсудить эти страсти – мордасти.
Речь идёт о двух простых и безобидных вещах.
1) Если руки-крюки, то существует вероятность (мелкософт говорит, что это, ну очень страшно), что хацкер-удалёнец заполучит один из экаунтов (имя пользователя + его парольчик). Конечно, если это случится, то вы рискуете стать спамером. Никакое запрещение релэя вас не спасёт, т.к. вполне легально с вашего smtp и под вашем экаунтом удалёнец будет рассылать эротические картинки, перемежающиеся с рекламой корма для собак (разумеется, при этом предполагается, что вы не подозреваете, что вас уже ну…. того…. этого…. ).
2) Мелкософт говорит, что возможно и удаленное произвольного кода и DoS (это не самое смешное, почитайте методы лечения в ссылке), но об этом позже.
Началось всё в сентябре-октябре. Дыру нашли Китайцы, как указано
http://www.winnetmag.com/MicrosoftExchangeOutlook/Article/ArticleID/40507/MicrosoftExchangeOutlook_40507.html
http://www.winnetmag.com/Windows/Article/ArticleID/40543/40543.html
Возможно и раньше, но то, что Китайцы безобразничают - точно.
Этой мелкой пакости даже дали гордое название «Новый вид SMTP AUTH атаки», см. статьи выше.
В 20-х числах мелкософт поместил вышеупомянутую статью на течнет. Дальше понеслось. Люди стали пробовать. Думаете защищаться? Нет - других хацкать, поскольку мелкософт уже протрубил на весь мир о своей дырке. И рассказал, по существу, как это можно реализовать. Любопытные стали пробовать - а действительно эта «дырка работает»?
Лично моё мнение – в общем случае не работает. Ниже собственно, что вы можете увидеть в своих логах (если вас уже…. того …. этого) и мои аргументы в том, что ничего архи-ужасного не происходит.
23-го октября в Eventview – вере я обнаружил совершенно наглую попытку залогониться «административно» (вернее там удалённая попытка подобрать пароль):
Event Type: Failure Audit
Event Source: Security
Event Category: (2)
Event ID: 539
User: NT AUTHORITY\SYSTEM
Computer: MYSERVER
Logon Failure:
Reason: Account locked out
User Name: administrator
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Workstation Name: MYSERVER
…
…
Event Type: Failure Audit
Event Source: Security
Event Category: (2)
Event ID: 529
User: NT AUTHORITY\SYSTEM
Computer: MYSERVER
Logon Failure:
Reason: Unknown user name or bad password
User Name: administrator
Domain:
Logon Type: 3
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Workstation Name: MYSERVER
Это был явный подбор пароля, поскольку таких записей в логе было около 40. Смотрим дальше.
В логе фаервола (для тех секунд) было почти всё хорошо и допустимо с точки зрения IDS – все пакеты «легальные»:
218.7.157.238 x.y.w.z 1906 25 SYN
x.y.w.z 218.7.157.238 25 1906 SYN ACK
218.7.157.238 x.y.w.z 1917 25 SYN
x.y.w.z 218.7.157.238 25 1917 SYN ACK
218.7.157.238 x.y.w.z 1929 25 SYN
x.y.w.z 218.7.157.238 25 1929 SYN ACK
218.7.157.238 x.y.w.z 1943 25 SYN
x.y.w.z 218.7.157.238 25 1943 SYN ACK
218.7.157.238 x.y.w.z 1906 25 ACK
x.y.w.z 218.7.157.238 25 1906 PSH ACK
218.7.157.238 x.y.w.z 1958 25 SYN
x.y.w.z 218.7.157.238 25 1958 SYN ACK
218.7.157.238 x.y.w.z 1917 25 ACK
218.7.157.238 x.y.w.z 1971 25 SYN
x.y.w.z 218.7.157.238 25 1971 SYN ACK
218.7.157.238 x.y.w.z 1929 25 ACK
218.7.157.238 x.y.w.z 1987 25 SYN
x.y.w.z 218.7.157.238 25 1987 SYN ACK
218.7.157.238 x.y.w.z 1943 25 ACK
218.7.157.238 x.y.w.z 2002 25 SYN
x.y.w.z 218.7.157.238 25 2002 SYN ACK
218.7.157.238 x.y.w.z 1906 25 PSH ACK
x.y.w.z 218.7.157.238 25 1906 ACK
218.7.157.238 x.y.w.z 1958 25 ACK
x.y.w.z 218.7.157.238 25 1958 PSH ACK
x.y.w.z 218.7.157.238 25 1917 PSH ACK
x.y.w.z 218.7.157.238 25 1929 PSH ACK
x.y.w.z 218.7.157.238 25 1943 PSH ACK
218.7.157.238 x.y.w.z 2019 25 SYN
x.y.w.z 218.7.157.238 25 2019 SYN ACK
218.7.157.238 x.y.w.z 1971 25 ACK
218.7.157.238 x.y.w.z 1987 25 ACK
218.7.157.238 x.y.w.z 2035 25 SYN
….
…
Всего хендшейков - 23 и все почти сразу ;)))). Анормальность с точки зрения обычного трафика SMTP – огромное число активных соединений. Это не обычный флуд. Все соединения завершены вполне корректно, т.е.
…
…
218.7.157.238 x.y.w.z 1958 25 FIN ACK
x.y.w.z 218.7.157.238 25 1958 ACK
x.y.w.z 218.7.157.238 25 1958 FIN ACK
218.7.157.238 x.y.w.z 1958 25 ACK
В логе Exchange сервера обнаружились соответствующие по времени следующие записи (46 записей).
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
218.7.157.238 softht SMTPSVC1 MYSERVER EHLO +softht
….
…..
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
218.7.157.238 softht SMTPSVC1 MYSERVER QUIT softht
Анормальность в этом логе такая же, как и в логе фаервола.
Соображения о том, что это не может представлять серьёзную угрозу:
1) попытки видны во всех логах. Даже, если админ не знает, что происходит – можно просто прикрыть трафик на фаерволе от злодеев.
2) попытки вряд ли увенчаются успехом, поскольку при минимальном качестве администрирования любой экаунт будет заблокирован уже после 3-5 неудачных попыток логон. Времени посмотреть любые из перечисленных логов будет навалом для админа.
3) соображения о возможности удалённого выполнения кода мне кажутся абсурдом (в данной ситуации). Переполнения буфера, как и знание административного экаунта – не позволят передать управление на другому деструктивному процессу в данном случае. Если знаете как, напишите. Этот процесс уже должен в таком случае существовать.
4) про DoS я вообще молчу. Исследователь паролей должен действовать скрытно, надеясь более на социальный инжинеринг. Иначе его заметит в логах даже самый ленивый админ.
5) Теоретически подобрать имя пользователя и соответствующий пароль, конечно, можно. Но вот вопрос – а что потом с этим административным экаунтом делать-то? Как удалённо будем запускать деструкцию, если зачастую наружу торчит только 25, и 110 порт?
Как думаете, отцы сисадмины?
|
|
Я не отец, но я тебе вот так скажу. 04.11.03 13:46
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
Написано много и может быть хорошо. Я вот патч поставил просто.
|
| |
Я не отец, но я тебе вот так скажу. 05.11.03 02:04
Автор: void <Grebnev Valery> Статус: Elderman
|
> Написано много и может быть хорошо. Я вот патч поставил
> просто.
Я тебя понял так - поставил патч, и хорошо.
Если это всё, что сказано мне -то это _написано НЕ много и может быть хорошо_
Мне хотелось пообсуждать следующие проблемы:
1) Когда объявляется очередная война с чем либо плохим - это приводит, как показывает практика, к "обострению болезни". Это замечено многими, кто занимается вопросами безопасности. Любой.
2) Вопрос в том, а как такой патч работает? Что он может дать в этом случае? Всё ведь происходит "легально". Я слабо разбираюсь (вернее, никак) во внутренностях всего этого. На форуме есть нормальные спецы, которые могли бы пролить свет.
Что пропачили - реакцию сервера на команду smtp AUTH, "отменили" её, или переделали?
3) Поскольку речь идет о вполне понятных механизмах - то лажа мелкософта заключается и втом, что мелкософтовская публика говорит о невозможности блокирования такого "нормального трафика" на ISA. Бред сивой кобылы. Если есть сигнатура, то её можно использовать для противоядия. Я не случайно привёл логи, поскольку и характер логов Exchange, и характер логов на фареволе говорит об одном и том же. Видно - _даже человеку_ с достаточно слабой подготовкой (я о себе). Машина должна перемалывать это на ура.
4) Везде расплывчато сказано о том, описанный выше способ может привести то ли к DoS, то ли к переполению буферов (чего, кстати? каких сервисов?) и возможности выполнения кода злоумышленника?
Ну как в обсуждаемом контексте это может быть (я не вообще, а про конкретную ситуацию)? Ежели не будет ясности в этих вопросов, то как вообщем чем либо заниматься? В том числе задачами администрирования?
|
| | |
В ссылках, что ты дал, есть ответы на все твои вопросы. 05.11.03 12:42
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> 2) Вопрос в том, а как такой патч работает? Что он может
> дать в этом случае? Всё ведь происходит "легально". Я слабо
> разбираюсь (вернее, никак) во внутренностях всего этого. На
> форуме есть нормальные спецы, которые могли бы пролить
> свет.
> Что пропачили - реакцию сервера на команду smtp AUTH,
> "отменили" её, или переделали?
What does this patch do?
For Exchange Server 5.5 the patch removes the vulnerability by requiring that the authentication used between Exchange servers within an Exchange organization is used before an Exchange server accepts the SMTP extended verb requests.
For Exchange 2000 Server the patch removes the vulnerability by requiring that the authentication used between Exchange servers within an Exchange organization is used before an Exchange server accepts the SMTP extended verb requests. Additionally, this patch implements correct input validation in the affected buffer.
> 3) Поскольку речь идет о вполне понятных механизмах - то
> лажа мелкософта заключается и втом, что мелкософтовская
> публика говорит о невозможности блокирования такого
> "нормального трафика" на ISA. Бред сивой кобылы.
Что-то я такого не увидел. Я увидел совет использовать фильтрацию SMTP (в разделе workaround).
> 4) Везде расплывчато сказано о том, описанный выше способ
> может привести то ли к DoS, то ли к переполению буферов
> (чего, кстати? каких сервисов?) и возможности выполнения
> кода злоумышленника?
> Ну как в обсуждаемом контексте это может быть (я не вообще,
> а про конкретную ситуацию)? Ежели не будет ясности в этих
> вопросов, то как вообщем чем либо заниматься? В том числе
> задачами администрирования?
СУБЖ.
|
| | | |
ты ж помоги тогда найти эти самые ответы 06.11.03 02:52
Автор: void <Grebnev Valery> Статус: Elderman
|
ВНАЧАЛЕ ОБ ЭТОМ
**********************************
>> 2) Вопрос в том, а как такой патч работает? Что он может
>> дать в этом случае? Всё ведь происходит "легально". Я слабо
…
…
>What does this patch do?
>For Exchange 2000 Server the patch removes the vulnerability by requiring that the authentication used >etween Exchange servers within an Exchange organization is used before an Exchange server accepts >the SMTP extended verb requests. Additionally, this patch implements correct input validation in the >affected buffer.
Если это ответ технарям, то здесь три раза смешно:
1) Здесь сказано про обмен МЕЖДУ «…Exchange servers within an Exchange organization…». Т.е. про то, что Билл Гейтс мечтает, дескать, весь мир только и использует его продукты. Комментировать даже не хочу (уже разболелось сердце). То, что выше написано про обмен МЕЖУ MS EXHANGE ( И ТОЛЬКО МЕЖДУ НИМИ ) имеет очень отдалённое отношение (если имеет вообще) к Сети, где и sendmail-ы иногда встречаются.
2) “…before an Exchange server accepts >the SMTP extended verb requests…» Это каки-таки рексвесты? Ну, надо же написать народу-то. Какую ещё дырку мелкософт оставил, для каких команд smtp? Об этом см. ниже.
3) «…Additionally, this patch implements correct input validation in the >affected buffer ..». Если посмотреть те дополнительные ссылки, которые есть на этой же странице, то там написано
см. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0714
The Internet Mail Service in Exchange Server 5.5 and Exchange 2000 allows remote attackers to cause a denial of service (memory exhaustion) by directly connecting to the SMTP service and sending a certain extended verb request, possibly triggering a buffer overflow in Exchange 2000.
Ну, каких буферов? Да их для разных служб может быть тысячи. Далее там написано про специально подготовленные хакерские пакеты, которые укладывают в SMTP. То же написано на странице течнета выше:
Technical Description:
In Exchange 2000 Server, a security vulnerability exists that could allow an unauthenticated attacker to connect to the SMTP port on an Exchange server and issue a specially-crafted extended verb request. That request could cause a denial of service that is similar to the one that could occur on Exchange 5.5. Additionally, if an attacker issues the request with carefully chosen data, the attacker could cause a buffer overrun that could allow the attacker to run malicious programs of their choice in the security context of the SMTP service.
Нифига себе. Значит нужно у мелкософта спросить, что они такого оставили в реализации SMTP для специальных реквестов, что может напрочь убить этот сервайс. Только вот какое это отношение это имеет к обсуждаемой тематике – к нехорошему использованию команды AUTH плохими мальчиками? Так бы и сказали – косяково написан SMTP, и вне зависимости к обсуждаемой проблематике.
Вообще-то здесь я не понял, и вот чего «… could allow the attacker to run malicious programs ….». Ну как можно сорвать стек, или переполнить буфер, чтобы затем передать управление на деструктивный код атакера, при условии, что это «делается это по SMTP»? Этож самое интересное. Но, к сожалению, здесь ты промолчал.
ТЕПЕРЬ ОБ ЭТОМ
**********************************
>> 3) Поскольку речь идет о вполне понятных механизмах - то
>> лажа мелкософта заключается и втом, что мелкософтовская
>> публика говорит о невозможности блокирования такого
>> "нормального трафика" на ISA. Бред сивой кобылы.
>Что-то я такого не увидел. Я увидел совет использовать фильтрацию SMTP (в разделе >workaround).
Workarounds
• Use SMTP protocol inspection to filter out SMTP protocol extensions.
There are default ISA publishing rules for Exchange for filtering out any SMTP protocol extensions from traffic that passes the firewall. Other third-party products may offer similar functionality. More information on how to publish an Exchange server computer with ISA Server can be found at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;311237.
Ссылка выше ничего общего с обсуждаемой проблематикой не имеет. Там написано, если ты посмотришь, как прикрутить Ексченжди с проки или исой. Там речь идёт о том, как заставить Ексчендж слушать требуемые порты и соответствующим образом отвечать удалённым хостам. Фильтрация, которая обсуждается в той статье – это обычные фильтры для smtp. Там и слова нет про «smtp auth – атаку». Более того. Эти фильтры по определению «пропускают» любой почтовый трафик, с любым MIME.
Продолжаем смеяться дальше:
• Only accept authenticated SMTP sessions.
If practicle, accept only connections from SMTP servers that authenticate themselves by using the SMTP AUTH command.
To require SMTP authentication on an Exchange 2000 server:
1. Start Exchange System Manager.
2. Locate the server in the organization tree.
3. Expand the Protocols container for the server.
4. Expand the SMTP container.
5. For each SMTP virtual server:
• Open the properties and of the virtual server object.
• Click the Access properties page.
• Click the Authentication button.
• Clear the "Anonymous Access" checkbox.
• Click OK to accept the change.
Здесь товарищи от мелкософта просто сошли с ума, думая, что других серверов, кроме Ексчандж не существует. А я, например, хочу почту с mail.ru получать. Этот совет мелкософта – полный дэбилизм. Если сделать так, то вы будете «общаться» только с ограниченным кол-вом почтовых серверов. Похоже, что тот, кто написал ЭТО даже не прочитал соответствующий раздел хелпа Ексчанджа.
А вот теперь уже умираем со смеху:
• Use a firewall to block the port that SMTP uses.
Use a firewall to block the port that SMTP uses. Typically, that is port 25.
Ну, а этот совет заблокировать 25 порт я комментировать просто не могу. Что здесь сказать.
******************
> > вопросов, то как вообщем чем либо заниматься? В том числе
> > задачами администрирования?
> СУБЖ.
Я слабо разбираюсь в компьютерном сленге. Это что («СУБЖ»)? Ругательство?
ПС. Всё это было б так смешно, если б не было так грустно.
|
| | | | |
ты ж помоги тогда найти эти самые ответы 08.11.03 13:51
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> Если это ответ технарям, то здесь три раза смешно
...........
> Ну, каких буферов? Да их для разных служб может быть
> тысячи. Далее там написано про специально подготовленные
> хакерские пакеты, которые укладывают в SMTP
...........
> Вообще-то здесь я не понял, и вот чего «… could allow the
> attacker to run malicious programs ….». Ну как можно
> сорвать стек, или переполнить буфер, чтобы затем передать
> управление на деструктивный код атакера, при условии, что
> это «делается это по SMTP»? Этож самое интересное. Но, к
> сожалению, здесь ты промолчал.
...........
А, ну просто твой корневой пост содержал в себе интерес с точки зрения администратора. Ну, а если тебе эксплоит писать надо, то да, тут я не силён.
> Нифига себе. Значит нужно у мелкософта спросить, что они
> такого оставили в реализации SMTP для специальных
> реквестов, что может напрочь убить этот сервайс. Только вот
> какое это отношение это имеет к обсуждаемой тематике – к
> нехорошему использованию команды AUTH плохими мальчиками?
> Так бы и сказали – косяково написан SMTP, и вне зависимости
> к обсуждаемой проблематике.
Тут вообще комментировать нечего. Неконструктивный абзац.
> > СУБЖ.
>
> Я слабо разбираюсь в компьютерном сленге. Это что («СУБЖ»)?
> Ругательство?
Нет, это значит , что вместо букв "СУБЖ" нужно подставить тему поста.
|
| | | | | |
ты ж помоги тогда найти эти самые ответы 09.11.03 03:00
Автор: void <Grebnev Valery> Статус: Elderman
|
> > Вообще-то здесь я не понял, и вот чего «… could allow
> the
> > attacker to run malicious programs ….». Ну как можно
> > сорвать стек, или переполнить буфер, чтобы затем
> передать
> > управление на деструктивный код атакера, при условии,
> что
> > это «делается это по SMTP»? Этож самое интересное. Но,
> к
> > сожалению, здесь ты промолчал.
> ...........
>
> А, ну просто твой корневой пост содержал в себе интерес с
> точки зрения администратора. Ну, а если тебе эксплоит
> писать надо, то да, тут я не силён.
Мой корневой пост действительно содержал интерес начинающего администратора.
Здесь есть два обстоятельства.
1) Я не занимаюсь написанием деструктивного кода. Однако, если хотя бы в первом приближении не понимать, как такой код МОЖЕТ работать (в данном и только данном контексте реализации smtp MS), то возьму на себя смелость сказать, что решение ПРОСТЕЙШИХ задач администрирования - отчасти затруднено (опять таки для обсуждаемой проблематики). Это связано с тем, что smtp не существует сам посебе. Одновременно работают и другие сервайсы. Надо понимать, как переполнение буфера в одной из функций (например, получающей имя пользователя в "зашифрованное" в base64) в имплементации smtp может повлиять на другие сервисы? Я - не понимаю, как?
Поскольку я не разбираюсь в этих шучках, то и пост мой был таков.
Если рухнет Exchange - это не самое страшное, что может случиться с точки зрения безопасности.
2) Вы говорите, что можно поставить патч и спать спокойно. Ну, положим, я поставил патч. Ниже мои сображения в том, что этого может быть недостаточно.
Я не склонен впадать в истерику, параною. Я хочу следовать тому, что написАл Microsoft. Но хоть убей - не получается. Не логично у Microsoft получается, имхо.
Почему? Потому, что те решения по противодействию, которые предложены Microsoft на указанной странице выше, мне не понятны, мягко говоря.
Вот мои аргументы (которые были высказаны в предыдущем посте) в более сжатом виде:
1) Требование обязательной аутентификации (запрещение анонимного логон) приведёт к тому, что ваш сервер не сможет общаться с бОльшей часть почтовых серверов. Попробуйте следовать указаной рекомендации Microsoft и Вы увидите, что, например, почта с mail.ru уже не приезжает на Exchange. В логах там видно, что после нормального установления соединения и пары-тройки PUSH "Exchange отвечает" RST (разумеется отвечает не собственно Exchange, а реализация сокет).
2) Требование обязательной аутентификации, ДАЖЕ ЕСЛИ ЕМУ СЛЕДОВАТЬ, не отвечают существу поставленной задачи - Это ни как не защищает от попыток исследования экаунтов. Точно также атакеры будут читать "Authentication unsuccessful" в ответ на команды AUTH ... И разумеятся будут это делать огромное число раз в единицу времени.
И возможно, что при низком качестве администрирования домена - им повезёт.
3) Фареволы от MS - очень слабо решают эту задачу, имхо. Даже преславутый smtp message screener, что в "комплекте" с ISA ( может быть установлен дополнительно) - не решает этих задач.
ПС.
1) Если я в чём-то не прав, то поправьте. Опыта у меня не так, чтобы много, к сожалению.
2) Меня немного удивляет реакция сообщества админов на этом форуме. Вернее, её отсутствие. Может и впрям я передёргиваю ситуэшн?
|
| | | | | | |
ты ж помоги тогда найти эти самые ответы 10.11.03 15:25
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> 2) Меня немного удивляет реакция сообщества админов на этом
> форуме. Вернее, её отсутствие. Может и впрям я передёргиваю
> ситуэшн?
Ну, на самом деле, как ты мог заметить всяких уязвимостей есть и появляется довольно приличное количество. Можно вникать в детали очень глубоко. Можно даже пойти дальше: самому искать уязвимости в сервисах, тогда у тебя будет шанс, что ты найдёшь их раньше, чем злоумышленник :) Дело, в принципе, хорошее, но не у всех на это есть время.
> 2) Вы говорите, что можно поставить патч и спать спокойно.
> Ну, положим, я поставил патч. Ниже мои сображения в том,
> что этого может быть недостаточно.
Ну, если сильно беспокоит, поставь ты Снорта какого-нибудь, чтобы он отлавливал неудачные аутентификации на SMTP и алерт на это дело.
|
| | | | | | | |
По-моему, все довольно просто :) 10.11.03 16:09
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
Шаман - админ со стажем, поэтому к кривым патчам относится как к данности. А void еще молодой, горячий, соответственно, хочет, чтобы не только все работало, но и сделано было как надо, а не через задницу :) Похвальное стремление, вот только я с подобным подходом в программировании вечно в сроки не укладываюсь %-)
|
| | | | | | | | |
По-моему, все довольно просто :) 11.11.03 00:05
Автор: void <Grebnev Valery> Статус: Elderman
|
> Шаман - админ со стажем, поэтому к кривым патчам относится
> как к данности. А void еще молодой, горячий,
> соответственно, хочет, чтобы не только все работало, но и
> сделано было как надо, а не через задницу :) Похвальное
> стремление, вот только я с подобным подходом в
> программировании вечно в сроки не укладываюсь %-)
Лёшка, ну, как бы ты и прав и не прав. Конечно, если только болеть этим, как параноей - то жизни не хватит. Сдругой стороны, можно ж разбираться самому покуда силёнок достаточно, а потом спрашивать в форуме.
(модное "пупок не надорви" - чур не отвечать). Это ж коллективный мозг форума - покруче любого супер-пупер буржуйского компа вместе с мсдэнами будет. (кстати, буржуи, по крайней мере на некоторых форумах вообще помоему не въехали в ситуацию).
|
| | | | | | | | | |
А вот тут согласен. Но, видимо, народу лень :) 11.11.03 03:22
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 11.11.03 03:22 Количество правок: 1
|
|
|
| | | | | | | | | | |
Не то чтобы лень :) 11.11.03 11:19
Автор: !mm <Ivan Ch.> Статус: Elderman
|
Просто я например MS Exchange не использую (корпоративный стандарт, но мне он не нравится в силу своей глючности и тормознутости).
Пофигизм MS - притча во языцах.
Они, конечно, в SP исправляют ошибки, которые признавать не желают, но в это время ошибки используются всеми, кем только можно.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
