Если вы не хотите мириться с блокировкой любимых вам сайтов, то и не нужно этого делать. Вот эти волшебные строчки помогут преодолеть маленькие запреты на вашем пути (для ростелекома):
iptables -A INPUT -p tcp -m tcp --sport 443 --tcp-flags RST RST -j DROP
iptables -A INPUT -p tcp -m tcp --sport 80 -m string --string "Location: http://warning.rt.ru" --algo bm --to 65535 -j DROP
А так же можно увеличить TTL, если иногда подключаетесь через точку доступа смартвона, чтобы провайдеры не срезали трафик.
sysctl net.ipv4.ip_default_ttl=65
А для сохрания TTL после перезагрузки нужно проправить /etc/sysctl.conf.
Для транзитных пакетов:
iptables -t mangle -A POSTROUTING -o usb0 -j TTL --ttl-set 65
В первой части статьи мы рассматривали больше физическую защиту. Но куда более опасной является сама сеть, ведь от туда гораздо легче добраться до вашего сервера, чем пробираться в серверную и пытаться исполнить свои черные замыслы. Скорее всего персонально вас ломать никто не будет, просто Вы попадете под «горячую» руку очередного бота сканирующего все подряд. В плане исключения на вас может кто-то сильно рассердиться и захочет таким образом отомстить.
Сколько не говори о необходимости использования надежных и уникальных паролей, всегда лень будет брать свое, что в свою очередь может очень негативно сказаться на вашей безопасности. Стоит добавить пару слов по выбору пароля. Длина не менее 8-ми символов, а лучше не менее 12. Должен включать числа, буквы разного регистра, знаки препинания и арифметические знаки. Не следует забывать о периодической смене. Читать далее…
В последнее время стал все больше внимания уделять безопасности и решил посвятить этому небольшой цикл статей. Эта статейка будет вводной и совсем коротюсенькой, но в последствии объемы будут наращиваться. Ну что ж приступим…
Первое с чего следует начать это физическая защита сервера. Но это как правило актуально различным компаниям и организациям, а домашнему серверу вполне будет достаточно стоять в уголке комнаты и преспокойно себе жужжать. Но даже дома не следует пренебрегать лишней защитой, враг не дремлет и всегда там, где его не ждешь.
Читать далее…
Уже магическое число 12309 знает любой уважающий себя линуксоид. Это страшный сон любого, для кого высокая активность I/O — норма жизни. И это главный довод для особо упоротых, кричащие «Linux не для декстопов».
Не знаю уже кому верить. Поэтому я решил. Посмотреть, как ведет себя мой ноутбук и делать из этого выводы о правдивости бага.
Итак. Мое железо — Samsung R560-ASSA, Core2M P7450, ICH9M, nVIDIA M9600GS, Hitachi 250 GB 5400 SATA-II, 3 GB RAM. Остальное железо мало влияет на проявление бага. К сожалению, другого оборудования, где установлен Linux, у меня нет. Настольник, на котором стояла Мандрива 2009.0 до Мандрива 2010.1 (версия ядер 2.6.29 до 2.6.32) (на данный момент Win7, которой я полностью недоволен, используется как чисто игровая машинка). Железо такое: AMD Athlon 64 X2 4600+, SB600, nVIDIA 8800GT, Seagate 7200.11 320 GB SATA-II, 4 GB RAM. В общем, баг в настольнике не наблюдался вообще. Так что говорить нечего. Да, забыл сообщить, что всегда и везде была файловая система ext4 (в настольнике до 2.6.31 был reiserfs3.6)
Читать далее…
Перед тем, как описать проблему и её решение, я вкратце расскажу, о чем будет идти речь в записях с тегом [manual]. А речь будет идти о проблемах тех людей, которые искали решение на форумах. Я же беру самые актуальные и описываю проблему здесь. И естественно решение этой самой проблемы.
Сегодня рассмотрим довольно часто возникающую проблему с Skype. Наверняка, многие знают, что с версии 2.1.0.81 Skype работает с микрофоном якобы только через Pulseaudio. Действительно, установка последнего решает эту проблему (проверено на себе). Но многие считают, что PA не нужен и оставляют православную ALSA в качестве основной звуковой подсистемы. И тут возникает проблема — в Skype микрофон перестает работать. Но, как оказалось, причина не в том, что приложение не умеет работать с ALSA, а в том, что нужный ползунок в системе находится в режиме «mute». Решение действенно как минимум для snd_hda_intel.
Читать далее…
Итак, Mandriva становится историей. Последние новости о ней явно указывали на её организационные и финансовые проблемы и было не ясно, что же с ней произойдет в дальнейшем. Разработчики раз за разом уходили от стана Mandriva Community, больше стало разговоров о расформировании дистрибутива, продаже её (тут даже проходила новость, что систему хочет приобрести один из российских бизнесменов. Но раньше всего из-за этой неразберихи должно было произойти то, что произошло накануне: Mandriva была «форкнута». Встречайте — Mageia Linux! (Дальше под катом)
Читать далее…
Текст новости (взято с ЛОР):
Разработчики из компании Collabora представили проект kdbus, в рамках которого создан экспериментальный прототип шины для межпроцессного обмена сообщениями D-Bus, работающий на уровне Linux-ядра. Встраивание D-Bus в ядро позволило существенно повысить производительность за счет уменьшения числа копирования областей памяти и минимизации числа переключения контекста между ядром и процессом-демоном, работающим на прикладном уровне. В kdbus для отправки сообщений реализован новый тип сокетов AF_DBUS, который напоминает Unix-сокеты и позволяет доставлять сообщения приложению-получателю напрямую, без задействования процесса-посредника (dbus-daemon). Изменения внутренней структуры организации обмена Читать далее…
Новые комментарии