Александр Слыжук

Примерно на 90% это административный, организационный и юридический вопрос. Техническая часть тут не самое главное.
Правильно организуйте работу. И сделайте так, чтобы вашим сотрудникам было невыгодно "сливать" код на сторону.

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).

Вот отличная статья на тему безопасности сети https://habrahabr.ru/post/283482/

Ctrl+Shift+J в Chromium работает ))

Обычно 8 pin = 4 pin + 4 pin, то есть они "сцеплены" в один разъем.

ну как я понял по картинке - лого стоит в brand. значит и номер телефона засунь туда же в brand

Не верно. Это значит, будет исполнятся каждую минуту и час 1, 10, 20, 30 числа.
Нужно указать два ноля, т.е., 0 0 1,10,20,30 * * command
Таким образом исполнение будет происходить в 00:00 нужных чисел.
Существует отличный сервис, в котором расшифровывается значение комманд cron:
crontab.guru/#0_0_1,10,20,30_*_*

Доброй ночи.
Да, в отличии от windows на ubuntu терминал на первом месте, главнейший инструмент.
Чтобы отредактировать файл, не обязательно вообще запускать gedit, можно через тот же терминал
sudo nano /etc/nginx/nginx.conf
Что за зверёк такой "nano" читайте здесь
И вообще, привыкните к терминалу, научитесь работать в нём и все девушки/парни(нужное подчеркнуть) - Ваши)))))

*************************************************
Через консоль можно не только редактировать, создавать, копировать, перемещать файлы внутри системы, но и на удалённом сервере через терминал можно творить чудеса.

1
2
3
4

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

вот

Какой интересный вопрос... Ну что ж, приступим. У меня как раз вечер свободный выдался, можем и порассуждать.

Стал замечать, что разработчиков сайтов на Wordpress высмеивают и говорят, что это уже прошлый век.

Прошлый век? Не знаю, доля WordPress продолжает расти. Сейчас это почти 27% всего интернета, если мне не изменяет память. Немногим больше четверти всех сайтов в мире. И на пути к одной трети. Вдумайтесь. Осознайте. А еще на WP делают проекты с бюджетами и по 20, и по 50, и 150к условных единиц. И с ежемесячным саппортом в четырех-пятизначных суммах. Все это есть. Рынок огромен.

Смеются над WP-разработчиками? Ну, пусть смеются. А мы тем временем хорошее бабло косим на этом "говнодвижке" (как его называют те, кто высмеивает), работаем в удовольствие, тусим по всяким WP-ивентам, создаем продукты, делаем заказчиков счастливыми, весело тратим заработанное и наслаждаемся жизнью. В общем, все отлично. А смех без причины - признак дурачины (С) детская поговорка.

Да, и обратите внимание на то, кто смеется. Какой-нибудь фрилансер-нищеброд, пытающийся заработать жалкие $400-800 в месяц, сутками колупающий свой кастомный фреймворк и отлавливая в нем стремные баги? Хипстер-рубист? Престарелый ценитель-теоретик C и Java, в 40 лет живущий с матерью? Ну ок. Пусть хохочут. Я не встречал ни одного разработчика высокого класса, независимо от предпочитаемых языков / технологий, который бы смеялся. Потому что опытный человек понимает, что это всего лишь инструмент. Который, к тому же, прекрасно выполняет свои задачи. Так же как Laravel. Как Django. И все остальное.

Есть такие люди, которые Canon vs Nikon, Apple vs Android, Mercedes vs BMW и тд. Holy Warriors они называются, и встречаются в любой жизненной сфере, в любой профессии. Научитесь держать удар и не замечать их существования.

Пришел к выводу, что cms никто не пользуется при создании заказных сайтов, но неужели для каждого сайта пишется свой движок?

Неправильный вывод. Используются, повсеместно. Сплошь и рядом. Вообще, есть 3 подхода:

1. Полный кастом. Долго и дорого. Выгодно разрабам - лочим клиента под себя в определенной степени, подвешиваем на саппорт и денюжка постоянно капает в карман. Не сильно выгодно заказчику, по той же причине - сложно сменить подрядчика, если что-то не нравится в работе. Дорого сопровождать и развивать. Для разрабов - куча работы и изобретения колеса снова и снова. На практике используется крайне редко, чаще всего хоть и строится с нуля, используются готовые библиотеки для разных задач. Чем больше этих библиотек и стороннего кода, тем быстрее проект перетекает во 2й подход.

2. Фреймворк. Средне-долго, средне-дорого. Здесь используется готовая основа, необходимые модули, остальное пишется под конкретные задачи. Экономически целесообразно. Это хороший вариант. Но работы бывает много, и велосипеды встречаются, и модули напильником дорабатывать приходится. А если использовать много готовых модулей, то плавно перетекаем в 3й подход.

3. CMS/CMF. Дешевле, быстрее. Тут, если сайт сильно типовой и его можно собрать без особого кодинга - отлично. Но часто и на CMS/CMF бывают весьма объемные и сложные задачи, сильно выходящие за рамки возможностей движка "из коробки" или готовых плагинов. Та же разработка кастомного функционала, доработка напильником сторонних плагинов и тд. В общем, не типовые сайты на базе CMS/CMF делать можно и ничто не мешает это делать. Главное понимать зачем, почему и как правильно. Понимать архитектуру CMS/CMF и как в нее встроиться. Этот вариант сильно выгодный клиенту, особенно если речь о WP, с его огромным рынком специалистов (впрочем, часто сомнительного уровня. Но это везде так, я встречал проекты на Laravel и Yii где от кода тошнило фонтаном).

В конечном итоге, все это PHP (или другой язык - не принципиально). И кастом, и фреймворк, и готовый движок. И все это можно сделать очень хорошо, а можно очень плохо. Вопрос не в инструменте, а в руках, которые его используют. Если вы возьмете кисть и краски Моне, вы не станете выдавать гениальные картины. Потому что не в кисти дело.

В общем, если WordPress нравится - изучайте его ядро, глубоко и качественно, изучайте глубоко и качественно сам PHP. SQL туда же. Те же фреймворки изучайте, там много интересного и полезного, что можно взять на вооружение. Учитесь решать задачи любой сложности элегантно, быстро, качественно. Учитесь документировать и рефакторить код. Оптимизировать. Использовать best practices. Учитесь создавать качественный продукт, решающий задачи клиента. И вот за это к вам будет стоять очередь, и будут хорошо платить. А не за то, что вы пишете на чистом си плюс плюс. Или на чем-то супер-современном. Enterprise-клиенты вообще такие legacy. А у них больше всего денег, кстати.