Muff's website forum

Пожалуйста, войдите или зарегистрируйтесь.

Расширенный поиск  

Новости:

SMF - Just Installed!

Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.

Сообщения - Trennis

Страницы: [1] 2
1
Спасибо!

2
Почтовый сервер, он же шлюз в инет :)

3
Спасибо, что ответили, но после долгого рытья логов, понял что что-то нездоровое скорее всего у провайдера и, как оказалось, был прав. Оказывается, завелось пару машин с вирусом, которые слали спам, посему нам заблочили 25 порт, а заодно и несколько других вдобавок. Ну очень, правда, странный способ блокировать спамера, позволяя ему отсылать письма, но не принимать :)

Вообщем проблема решена. Почему сразу прову не позвонил? Потому что собирался убедиться, что с нашей стороны всё нормально и, если что, быть готовым стоять на этом.

Ещё раз спасибо.

Отсюда вопрос резонный, а можно ли как-то наш почтовый сервер обезопасить от таких горе вирусов по рассылке спама? Т.е. когда идёт из твоей собственной сети.
Настройка была по статье: http://muff.kiev.ua/content/exim-nastroika-pochtovogo-servera-na-baze-exim-s-khraneniem-spiska-polzovatelei-v-bd-mysql-i

По поводу антивирусов можете не говорить, это я знаю. Ради интереса, наверняка же как-то можно.

4
Ещё вскрылись интересные факты!

Не пробрасываются некоторые порты, а именно 80 порт на внутреннюю машину. Т.е. если стоит внешний стандартный порт (например 80), то не хочет редиректить на внутренний вэб-сервер на 80 порт:
#       HTTP на First(сайт)
redirect_port   tcp     192.168.0.102:80 80
Посему сайт, конечно не работает.
А если, скажем, 5555, то на внутренний сервер на 80 порт как по маслу.
#       HTTP на First(сайт)
redirect_port   tcp     192.168.0.102:80 5555
И так с каждым стандартным портом, будь то RDP или ещё что.

Что за напасть и как с этим бороться, может сталкивались с таким? Причём теперь уже для случая с портами ставил диск с резервной копией. Тоже самое. Мистика какая-то.
Извиняюсь, что пишу в этот же раздел, просто кажется всё взаимосвязано.

5
Приветствую!

Значит, возникла нежданно-негаданно проблема.

Отмечу только, что всё работало нормально, никаких настроек не менялось.

Сервер Exim, локальная отправка и получение проходит на ура. Изнутри на внешку тоже шлются нормально. Но вот извне письма не доходят. По логах файервоа видно, что стучатся на 25 порт:
Mar 19 14:57:39 gate kernel: ipfw: 8911 Accept TCP 81.88.195.231:25575 Внешний IP:25 in via rl0
Mar 19 14:57:40 gate kernel: ipfw: 8911 Accept TCP 197.251.172.145:23781 Внешний IP:25 in via rl0
Mar 19 14:57:41 gate kernel: ipfw: 8911 Accept TCP 59.113.227.11:3183 Внешний IP:25 in via rl0
Mar 19 14:57:41 gate kernel: ipfw: 8911 Accept TCP 89.248.176.25:57650 Внешний IP:25 in via rl0
Mar 19 14:57:44 gate kernel: ipfw: 8911 Accept TCP 89.248.176.25:57650 Внешний IP:25 in via rl0
Mar 19 14:57:44 gate kernel: ipfw: 8911 Accept TCP 59.113.227.11:3183 Внешний IP:25 in via rl0
Т.е. в сервак-то они проходят, но вот EXIM никак не реагирует!

Кстати, ради эксперимента, подключал резервную копию двухнедельной давности, ну уж тогда-то всё тоже точно работало, но! И в этот раз ничего не проходит.

Что делать, ума не приложу. Помогите, очень надо.  :(

6
Спасибо, буду смотреть. :)

7
Система / Загруженность сервера. Графики Cacti.
« : Февраля 20, 2012, 07:45:16 pm »
Добрый день!
]# uname -a
FreeBSD gate.bief.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Tue Sep  6 13:17:31 UTC 2011     root@gate.bief.ru:/usr/obj/usr/src/sys/GATE  i386

Значит проблема вот в чём. Время от времени появляется такое явление (см. графики):

Причину появления проблемы не могу понять. Чуть раньше, стабильно, раз в неделю, выдавал такие графики и заметно подтормаживал, помогал ребут. Однако потом, сам по себе, больше месяца проработал нормально, а потом опять та же ерунда.

В чём может быть проблема?

На серваке крутится exim, dovecot, clamav, apache, mysql, DNS, cacti, NUT, Monit.

И в дополнение, постоянно растёт занятое место на /var. Грешу на неротируемый лог. Прибавление идёт где-то в районе 2 гигов в месяц, или около того. Но попытки найти файл, скажем больше 500 МБ тоже не увенчались успехом, стало быть, не в ротации дело?

Буду признателен за помощь! :)

8
Почта / Re: Roundcube отправка почты
« : Октября 07, 2011, 09:11:21 am »
Послал в личку.

9
Почта / Re: Roundcube отправка почты
« : Октября 06, 2011, 11:09:01 pm »
Ну я так понял - это всё делается через DNS? Это пожалуй оно из немногого, что я не до конца уяснил :)
А так пример понятен, спасибо.

Настройка ответа стало быть в конфиге того же, например, Exim'a делается? :)

10
Почта / Re: Roundcube отправка почты
« : Октября 06, 2011, 10:39:59 pm »
Да, я знаю, что 30 это 4 хоста, просто при подключении к сети провайдера стоит именно 30. Подумал, как бы потом не возникло проблем, если 32 поставить. :) Но попробую, как Вы сказали. Спасибо за ссылку. На опен-релей не тянем :D

А можно ли ещё прокомментировать пару строк:
Warning - Reverse DNS does not match SMTP Banner -> Это что?
0 seconds - Good on Connection time
Not an open relay.  :D
5.086 seconds - Warning on Transaction time -> Типа большое время передачи?

11
Почта / Roundcube отправка почты
« : Октября 06, 2011, 12:56:39 pm »
Добрый день, очередной косяк возник во время эксплуатации.

Значит дело вот в чём, есть кусок конфига  exim.
# Список сетей, которым будет разрешена отправка без авторизации.
# Перечисляем сети, которые будут пользоваться даным сервером для
# отправки почты.
hostlist   relay_from_hosts = localhost : 127.0.0.1 : 192.168.0.0/24

При таком раскладе письма прекрасно отправляются с почтовых программ, типа outlook, но, при использовании roundcube, выдаёт ошибку и блочит по правилу:
# Разрешаем почту от хостов в релейных доменах.
accept  hosts         = +relay_from_hosts
accept  authenticated = *
deny    message       = relay not permitted

В логах это выглядит так:
Oct  6 11:36:48 gate exim[38772]: 2011-10-06 11:36:48 SMTP connection from [внешний ip] (TCP/IP connection count = 1)
Oct  6 11:36:49 gate exim[67229]: 2011-10-06 11:36:49 H=eth158-198.prov.ru (192.168.0.100) [внешний ip] F=<info@bief.ru> rejected RCPT <vasiya@mail.ru>: relay not permitted
Oct  6 11:36:49 gate exim[67229]: 2011-10-06 11:36:49 SMTP connection from eth158-198.prov.ru (192.168.0.100) [внешний ip] closed by QUIT
Я так понимаю тут и обратную зону надо крутить, но суть вопроса в следующем.

Я изменил настройки в Exime вот так:
# Список сетей, которым будет разрешена отправка без авторизации.
# Перечисляем сети, которые будут пользоваться даным сервером для
# отправки почты.
hostlist   relay_from_hosts = localhost : 127.0.0.1 : 192.168.0.0/24 : Внешний ip/30
И всё стало работать. Из roundcube всё стало нормально отправляться. Пока собственно говоря им никто ещё не пользуется, но хотелось бы всё же до ума довести, чтобы было как положено.
Так вот не будет ли каких либо последствий от таких изменений? Не смогут ли кто-нить с внешки использовать как релей и слать от нас почту, честно ещё плохо себе представляю как это происходит, потому прошу Вашего совета.

Заранее спасибо. :)

12
Разумеется :)  Я просто всегда вспоминаю, когда ищу проблему, и на форуме нахожу такую же, и в конце надпись: "Спасибо, я уже разобрался", и ничего более, не хочется чтобы так на мою натыкались :)

----------------
Значит так. Проверил почему такой скачок был. Я примерно с начала недели тестировал на нём работу сайта, который сейчас находится на другой машине. Вот собственно говоря и полезла память в Inact, та которую использовал Апачь для формирования страниц :)

Просто было любопытно. Сейчас, после перезагрузки, Free держится в районе 1500 Mb. Хотя со временем всё равно будет перебегать в Inact.

13
А раньше Free было как раз около 1200М.

---------------------
Вообщем почитал ещё разные посты, оказалось что это нормально и, что паниковать не стоит, а то я уже испугался. Подумал нужно скоро сервак ловить будет, чтобы не упал ;D Но всё же интересно, почему именно с этого периода :) До этого достаточно долго работал, и не захватывал так много :)

В любом случае, спасибо тебе Muff:)

P.S. Есть одна догадка, почему так происходит, хочу проверить...

14
Вот результат:
last pid: 18673;  load averages:  0.00,  0.00,  0.00                                                                                 up 1+03:49:45  20:03:32
172 processes: 3 running, 151 sleeping, 18 waiting
CPU:  0.2% user,  0.0% nice,  0.4% system,  0.2% interrupt, 99.2% idle
Mem: 441M Active, 1236M Inact, 193M Wired, 39M Cache, 112M Buf, 51M Free
Swap: 2048M Total, 364K Used, 2048M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root         2 171 ki31     0K    16K CPU0    0  54.5H 200.00% idle
   12 root        18 -60    -     0K   144K WAIT    1  10:56  0.00% intr
 1464 squid        1  44    0   105M 98264K kqread  0   7:54  0.00% squid
    0 root         9 -68    0     0K    64K -       0   5:37  0.00% kernel
 1476 root         1  44    0 11160K  5828K select  1   3:35  0.00% snmpd
 1141 bind         5  44    0 70868K 55960K kqread  1   2:47  0.00% named
   18 root         1  44    -     0K     8K syncer  0   1:41  0.00% syncer
15194 root         1  44    0  3708K  1524K select  1   1:06  0.00% natd
 5042 root         1  44    0  5852K  4152K select  1   0:44  0.00% tmux
 1838 mysql       27  44    0   647M   111M ucond   0   0:41  0.00% mysqld
 1868 clamav       2  44    0   127M   112M select  1   0:29  0.00% clamd
 1874 clamav       1  56    0 16680K  5340K pause   1   0:24  0.00% freshclam
   13 root         1 -16    -     0K     8K -       0   0:24  0.00% yarrow
 1406 uucp         1  44    0  3488K  1220K select  0   0:22  0.00% apcsmart
 1408 uucp         1  44    0  5144K  1860K select  1   0:17  0.00% upsd
    3 root         1  -8    -     0K     8K -       1   0:10  0.00% g_up
    4 root         1  -8    -     0K     8K -       0   0:05  0.00% g_down
    2 root         1  -8    -     0K     8K -       0   0:03  0.00% g_event
 1927 root         1  44    0 85288K 15136K select  1   0:03  0.00% httpd
 1902 root         1  44    0  3448K  1404K kqread  0   0:02  0.00% dovecot
   20 root         1  44    -     0K     8K sdflus  1   0:02  0.00% softdepflush
   21 root         1 -16    -     0K     8K flowcl  1   0:02  0.00% flowcleaner
 1880 mailnull     1  44    0 13292K  3604K select  0   0:02  0.00% exim-4.76-0
 2088 uucp         1  44    0  5132K  1832K nanslp  0   0:02  0.00% upsmon
15219 root         1  44    0  3428K  1168K select  1   0:02  0.00% rinetd
 1426 uucp         1  44    0  5132K  1804K nanslp  0   0:02  0.00% upsmon
   14 root        20 -64    -     0K   160K -       0   0:02  0.00% usb
16178 root         1  44    0  7128K  4324K piperd  1   0:02  0.00% perl
 1056 root         1  44    0  3488K  1276K select  1   0:01  0.00% syslogd
 1913 mailnull     1  44    0  7948K  2532K kqread  1   0:01  0.00% dovecot-auth
   19 root         1  44    -     0K     8K vlruwt  0   0:01  0.00% vnlru
15477 www          1  44    0 87336K 26188K lockf   0   0:01  0.00% httpd
 1908 root         1  44    0  3540K  1052K nanslp  1   0:01  0.00% bruteblockd
 1474 squid        1  44    0  2664K  1288K piperd  0   0:01  0.00% unlinkd
   17 root         1  44    -     0K     8K psleep  0   0:00  0.00% bufdaemon
    9 root         1  44    -     0K     8K psleep  1   0:00  0.00% pagedaemon
18571 root         1  44    0  3824K  2164K CPU1    0   0:00  0.00% top
16168 www          1  44    0 87336K 25768K lockf   0   0:00  0.00% httpd
 1989 root         1  44    0  3516K  1284K nanslp  0   0:00  0.00% cron
16409 www          1  44    0 87336K 22628K lockf   0   0:00  0.00% httpd
 1416 uucp         1  44    0  5132K  1768K nanslp  0   0:00  0.00% upslog
14996 root         1  44    0  7128K  4312K piperd  0   0:00  0.00% perl
 1919 mailnull     1  44    0  7948K  2740K kqread  0   0:00  0.00% dovecot-auth
16367 www          1  44    0 86312K 20828K lockf   0   0:00  0.00% httpd
18546 Adminbief    1  44    0  9572K  3800K select  0   0:00  0.00% sshd
 5043 root         1  45    0  4704K  2116K wait    0   0:00  0.00% bash
    1 root         1  76    0  2912K   328K wait    1   0:00  0.00% init
16464 www          1  44    0 86312K 20808K lockf   0   0:00  0.00% httpd
14997 root         1  44    0  4704K  2068K wait    0   0:00  0.00% bash
18544 root         1  50    0  9572K  3784K sbwait  1   0:00  0.00% sshd
16177 root         1  44    0  3292K   724K kqread  1   0:00  0.00% tail
 1488 mysql        1  76    0  3632K  1248K wait    0   0:00  0.00% sh


15
Система / Использование оперативной памяти
« : Октября 03, 2011, 03:23:06 pm »
Добрый день.
У меня такой вопрос, в течении недели на моём шлюзе использование оперативной памяти увеличилось до 2 Гб, уже Своп пошёл в дело, не могу понять в чём дело, это вообще нормально?

На сервере MySQL, EXIM, Apache, Bind, Cacti и ещё всякая мелочь. Обратил внимание на то, что стало так где-то после запуска NUT, может ли это быть причиной?

Заранее спасибо.

Страницы: [1] 2

Страница сгенерирована за 0.248 секунд. Запросов: 24.