Karpion

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

Непонятно, являются ли пользователи системными (заведёнными в системе) или сайтовыми.
Если пользователи системные - то их надо включить в группу и дать доступ на запись в эти папки только этой группе (ну и возможно - владельцу).
Если пользователи сайтовые - то запросы на загрузку выполняются от имени какого-то юзера. Надо дать доступ только доступ на запись в эти папки только этому юзеру.

Есть такое хорошее правило:
"Никогда не давай прав больше, чем необходимо.".
Потому что дополнительные права не принесут пользы, ибо не нужны; а вот проблемы они принести могут запросто.

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

Поясню на примере шелла - мне кажется, это проще всего.

Допустим, есть некая программа, запускаемая с командной строки. И эта программа интерпретирует свои аргументы так, что звёздочка имеет какое-то особое значение. Например, find откуда_искать -name маска_для_поиска - и маска_для_поиска вполне может содержать звёздочку.
Однако, если я напишу маску_для_поиска просто так - то шелл увидит там звёздочку и станет интерпретировать её по-своему, в результате чего find получит не то, что я хотел ему передать, а что-то иное. И чтобы шелл не своевольничал - я должен экранировать звёздочку и прочие спец.символы.

Другой пример - форум с хранением содержимого в SQL-DB:
Понятно, что юзеры имеют законное право использовать в тексте любые печатные символы; в т.ч. и те, которые являются спец.символами в SQL. Соответственно, при формировании SQL-запроса - спец.символы надо экранировать, иначе возможна SQL-инъекция.

Как правило, начинать надо с построения модели угроз. Т.е. надо рассматривать возможные атаки на Ваш компьютер.

А как Вы себе представляете проверку сайта на безопасность? По каким признакам?

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

Ещё хороший вариант - выставить себе лимит платежей, тогда много не украдут.

И ещё: две линии защиты, а которых Вы сказали, надо привязывать к разным аппаратам. Если это SMS - то можно иметь простую звонилку, её труднее взломать.

Ну и главное - никому не сообщать пин-код и т.б. CVV. CVV хорошо бы заклеить/закрасить.

Откуда следует, что та сеть запаролена?

Надо смотреть, какие протоколы используются. Если протоколы надёжно шифруют трафик - то всё достаточно безопасно.

Ну, тут явно требуется ликбез.

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

Антивирусный сканер, ищущий вирусы только на диске - достаточно легко портируется на почти любую операционку, поскольку он работает исключительно стандартными операциями работы с файлами; нестандартными являются операции доступа к областям диска, которые не являются частью файловой системы, типа MBR.
Поиск вирусов в памяти и резидентная работа антивируса - портируются очень сложно, поскольку соответствующие механизмы сильно различаются в разных операционках.
К счастью, Вам для Вашей задачи нужен только поиск вирусов на диске (флешка в данном контексте эквивалентна диску).

Самый простой путь заключается в том, чтобы использовать простейший сканер с флешки - типа "DrWeb CureIt!". Это - минимальный Linux и программа от DrWeb.
Недостаток - эта система не имеет автоматического обновления, её нужно обновлять вручную.

В принципе, можно поставить на машину Linux; а в виртуалку поместить образ загрузочной флешки или загрузочного CD-ROM (реальный CD-ROM работает медленно, но для образов это неважно). Ну и сам Linux будет по мере необходимости скачивать свежую версию антивируса.

Всю информацию о железе - браузер получает от операционки.
Можно ли приказать браузеру "не слать эти данные" - не знаю.

Зависит от того, с какой целью Вы этого хотите.

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

Насколько я понимаю, дистрибутивы Linux делаются одинаково тщательно для обеих платформ.

Ввести Ваш номер - может кто угодно.

Вероятно, тот человек получил код активации на E-mail или как-то ещё.

Мне кажется, Вы сделали то, что называется "неправомочный доступ к чужому эккаунту"; это = преступление, оно наказуемо. ТО, что какой-то разиня ввёл Ваш номер телефона - не даёт Вам права перехватывать доступ к эуккаунту, менять пароль, etc.

Возможно, законный владелец эккаунта свяжется с Вами - помогите ему вернуть контроль над эккаунтом. Или сами свяжитесь с M$ и сообщите об ошибке.

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

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

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

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

Если учиться осталось недолго - лучше доучиться. Знания и диплом могут пригодиться.

Как тут уже выше сказали - надо изучать IT-техологии. Т.е. надо знать работу компьютера на всех уровнях - начиная от ассемблера и контроллеров до теоретических концепций. Причём это надо знать не досконально, но как минимум на уровне понимания, как оно работает. Например, MeltDown невозможно понять без знания ассемблера.
Надо знать работу сетей - тоже не досконально, но на уровне общих представлений. ТОже на всех уровнях.
И под это дело - надо неплохо знать математику.

Образование можно получить и в ВУЗе - но далеко не во всяком. Или на курсах - но тоже далеко не на всяких. Самообразование - нужно в любом случае; хотя бы потому, что технологии меняются, так что знания устаревают.

Вообще непонятно.

Сначала выясняем, что за два места хранения файлов, между которыми надо перекладывать эти файлы. Хорошо бы уяснить, зачем они вообще там хранятся - может, это надо хранить не в файле.

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

Также выясняем, какие операционки на обоих хранилищах.

А вообще, похоже, нужная Вам функциональность уже есть в программе rsync (она родом из Unux, есть порт на Windows).

Rashad31, тебя посадят. Так что не советую.

Linux можно поставить вирт.машину. А в W'10 - он и так есть.

Как я понял - виды угроз безопасности веб-сервера можно разделить на две группы — во-первых, связанные с ошибками администрирования, во-вторых, связанные с ошибками программной реализации сервера.

Я бы выделил как минимум три вида ошибок:

1. ошибки администрирования;
   
2. ошибки написания скриптов (как раз здесь находится SQL-инъекции);
   
3. ошибки в "стандартных" программах - Apache, Nginx, SQL-СУБД (встречаются весьма редко, зато затрагивают многих).
   

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

Входные данные должен фильтровать CGI-скрипт. Если он косячный - никакое администрирование не поможет (кроме "не устанавливать на сервер косячные скрипты").

Или пишут что ошибка администрирования - это разрешение использование методов PUT и DELETE, позволяющих удаленному пользователю редактировать и удалять странички с сервера.

Как правило, сервер выполняется от юзера с минимальными правами; а в доступном серверу каталоге все файлы делаются недоступными для записи от этого юзера. Хотя ненужные методы следует запретить.