PHP-сессии. Сколько их создается для одного посетителя?

Question

[Павел]

Всем привет! Есть VPS с Ubuntu 12. Внезапно легли все сайты (5шт.) Поковырялся, проблема в том, что закончилось место. На самом деле закончились иноды. В папке с сессиями насобиралось полтора миллиона файлов sess_* . На этот момент сайты работали 5 месяцев, все молодые. Суммарный трафик не более 300 посетителей в сутки. Отсюда и вопрос нормально ли такое количество сессий, или это вредонос? И почему вообще apache или php не убирают за собой?

UPD в php.ini самого php стоит session.gc_maxlifetime = 1440
в сайтах на Opencart в php.ini стоит session.gc_maxlifetime = 3600
У WP своих php.ini не нашел.

UPD 2 сессии лежат в /var/www/user_name/data/mod-tmp
И я вижу там файлы созданные более 2-х часов назад. Это то время когда почистил все и задал вопрос.

UPD 3 Докопались до сути. В php.ini выключен сборщик мусора. стояли такие значения
session.gc_probability = 0
и
session.gc_divisor = 1000
Поставил session.gc_probability = 1 сессии начали удаляться.
Всем спасибо!

Comments

[VerniteAccount]

Может стоит поискать плагин для Апача с авточистилкой + очищать сессии при логауте. На сколько я помню сессия должна уничтожаться автоматически в случае закрытия всех страниц сайта + сессия хранится не в файле а в Cookies и дублируется в HTTP заголовках. В редких случаях она может передаваться GET параметром после расширения файла в адресной строке браузера.

[Павел]

VerniteAccount: в куки хранится идентификатор сессии, а сама сессия на сервере. Вот мне и интересно откуда полтора ляма. Вычитал, что может быть от роботов. Они не хранят куки и, значит, на каждый запрос робота создается новая сессия. Но в апаче же должен быть сборщик мусора.. сессии же не должны храниться вечно

[VerniteAccount]

Павел: Подскажите, владелец сервера видит содержимое сессий выбранного хоста, при этом он может извлечь данные из сессии или она зашифрована и дешифруется во время компиляции скриптов?
Знаю, вопрос не совсем корректный, так как хостер может делать с сайтом все что угодно, в теории. Но все-же, это меня интересует, так как в будущем возможно буду хостить его у себя на машине.

[Павел]

VerniteAccount: нет, данные не шифруются. можно зайти и посмотреть что написано в файлике сессии. Там примерно такое

default|a:2:{s:8:"language";s:2:"ru";s:8:"currency";s:3:"UAH";}

Окружение клиента грубо говоря. если он залогинен там может лежать id пользователя, и, вероятно, хеш пароля, но не точно. Но в самом файле сессии не как не указано какому клиенту он принадлежит. Принадлежность проверяется по кукам

[VerniteAccount]

Павел: Спасибо за ответ, а что быстрее и надежнее стандартные сессии либо массив с данными в Cookies и своими хешами с солью?

[Павел]

VerniteAccount: куки ограничены по размеру и небезопасны. Не стоит изобретать велосипедов)

[k2lhu]

Возможно сумасшедшее предположение, но вы используете session_destroy(); ?

[Павел]

сайты на Opencart и WordPress, уверен там это все предусмотрено.

[Arman]

скорее всего сайты указали хранить сессии на несколько лет - общая практика в целом, вы в свою очередь можете настроить какой крон и в наглую удалять файлы по времени модификации, в целом пользователей просто попросят еще раз авторизоваться, если не было их больше месяца допустим. Еще вариант переназначить механизм сессии хранить их в БД, мемкэш или редис, но опять же это ресурсы, я бы пошел по первому пути, не нравится, пусть переделают механизм сессии на свое и получат сессию больше месяца или два сколько там дадите им

[k2lhu]

Павел: вы правы, интересно в чем же дело :)

Answer 1

[Евгений Вольф]

Пока думал о причино-следственных связях происходящего и писал ответ, тут уже без меня и написали много и на часть вопросов ответили... и даже прояснилось кое что...

Как Вы понимаете, сказать с большей вероятностью сложно, но мне картина видится, в таком порядке:
1. У Вас есть сайт на ВП
2. Админка ВП или её признаки, доступны по стандартным адресам
3. Заходит бот, в поисках свежего ВП для взлома (с целью рассылки спама), и пытается брутфорсить Вашу админку, или ещё что-то в таком духе делать
3.1 Возможно ему приглянулась админка не ВП, а какого другого сайта... без подробных логов доступа угадать - как пальцем в... небо!
4. Бот несколько часов генерирует паразитные запросы
5. Каждый такой запрос, создаёт новый файл сессии
6. По умолчанию, файл сессии ПХП хранится 24 часа
7. Файлов сессий стало слишком много

Это наверное, самый вероятный вариант из всех, что мне удалось придумать не имея доступа к серверу и практически никакой информации о происходящем внутри оного...

Возможные полезные действия с Вашей стороны:
а) Можно настроить время жизни сессий в ПХП
б) Не хранить админки в свободном доступе
в) Выбрать и установить какой-то механизм защиты от ботов. Не сложно догадаться, что пользователь не мог запрашивать 500 страниц в минуту...

Comments

[Павел]

Спасибо. Дополнил вопрос. Почему сессии не удаляются?

[Павел]

судя по содержимому - сессии плодит Opencart. Я не могу ручаться прям за все, но за последние 2 час создано около 100 файлов, поклацал по ним - там такое:

default|a:2:{s:8:"language";s:2:"ru";s:8:"currency";s:3:"UAH";}

[Евгений Вольф]

Павел: как вариант - просто не успевают, один бот, за 10 минут может сделать очень много запросов. А за 24-60 минут, даже 1.5млн. запросов могли пройти. Нужно анализировать дату/время создания и последнего обращения к файлам сессий которые там насоздавались, что бы дать какой-то более конкретный ответ. Так же, "Garbage collector" срабатывает только каждый N-ый запрос, то есть он срабатывает с некоторым процентным соотношением (по умолчанию, 1% кажется), возможно вероятность срабатывания его, так же была изменена (ссылка в ответе выше, два параметра сразу над "maxlifetime").

Мне кажется, Вам проще было бы поставить что-то вроде этого... ну или хотя бы ограничьте макс. кол-во запросов в минуту с одного IP.

[Павел]

Евгений Вольф: Шикарно! В php5/apache2/php.ini стоит session.gc_probability = 0 и session.gc_divisor = 1000 . Я так подозреваю, что сборщик мусора у меня запускался чуть реже чем никогда? интересно, кто мне так напакостил. Это не дефолтные значения. Хостер, когда на впс накатывал систему, или человек, который настраивал его?

[Евгений Вольф]

Павел: вряд ли на вопрос "кто" кто-то из здесь присутствующих сможет дать ответ. Но, если верить формуле, сборщик запускался с вероятностью "0/1000" при каждом запросе. Хостер бы вряд ли подобным занимался, просто по тому, что хостеру чаще всего, вообще фиолетово, на Ваши настройки... Хостеры обычно ставят систему из образа-болванки, а там 99% настроек идут по умолчанию.

[Павел]

Евгений Вольф:

с вероятностью "0/1000"

То есть никогда не запускался, если я правильно понял. Поставил 1 и 100, посмотрю, поможет ли, если все ок, поотмечаю ответы) Спасибо!

[Евгений Вольф]

Павел: Если не поможет, по какой-то неведомой причине, могу подсказать Вам одно решение из разряда "в лоб". PHP не хочет управлять сессиями? Пусть сессиями управляет НЕ ПХП! :))) Такой подход немного ускорит доступ к данным и будет меньше дёргать жесткий диск, на VPS может быть тоже актуально, т.к. дисковая подсистема - обычно самое слабое место у них.

[Павел]

Евгений Вольф: спасибо. Интересно)

Answer 2

[Дмитрий Энтелис]

VerniteAccount: помнит не правильно. В куках хранится id сессии, сами данные сессии по умолчанию хранятся именно в файлах, за настройку отвечают параметры php.net/manual/ru/session.configuration.php#ini.se... и php.net/manual/ru/session.configuration.php#ini.se...

время жизни хранится в php.net/manual/ru/session.configuration.php#ini.se...

а вообще категорически не советую использовать родной механизм сессий php.

Comments

[Павел]

а какие альтернативы есть для хранения сессий? И может ли CMS для себя переписать настройки PHP на сервере?

[VerniteAccount]

Насчет > категорически не советую использовать родной механизм сессий php согласен с вами, то есть сессия таки хранится на сервере у хостера, а вызывается по id из фронтэнда, значит ли это что он имеет доступ к данным в этом файле либо происходит дешифрование "на лету" при очередной компиляции скриптов?

[Дмитрий Энтелис]

Павел: можно хранить сессии в sql, можно хранить их в redis, можно где угодно. Погуглите, информации море.

[Дмитрий Энтелис]

VerniteAccount: 1. Фронт не имеет доступа к содержимому сессии. 2. данные сессии никак не шифруются в принципе.

[Павел]

Спасибо. Дополнил вопрос. Почему сессии не удаляются?

Answer 3

[Пума Тайланд]

судя по всему у вас испменеджер и отключена чистка сессий

Comments

[Пума Тайланд]

Павел: не знаю где в настройках но проблема боянистам

[Павел]

Да, у меня isp. Сборщик мусора был в phph.ini выключен. Я включил. Получается isp его по умолчанию выключает? Где в настройках это искать?

Answer 4

[Arman]

скорее всего сайты указали хранить сессии на несколько лет - общая практика в целом, вы в свою очередь можете настроить какой крон и в наглую удалять файлы по времени модификации, в целом пользователей просто попросят еще раз авторизоваться, если не было их больше месяца допустим. Еще вариант переназначить механизм сессии хранить их в БД, мемкэш или редис, но опять же это ресурсы, я бы пошел по первому пути, не нравится, пусть переделают механизм сессии на свое и получат сессию больше месяца или два сколько там дадите им, но не думаю что они этого даже заметят

Comments

[Павел]

Спасибо. Дополнил вопрос. Почему сессии не удаляются?