Премини към съдържанието
  • Добре дошли!

    Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

    Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

     

Препоръчан отговор

публикувано (редактирано)

По-долното деактивира source routing-а на kernel-а, и машината става невидима за някой, който да речем използва ping със зададено record route поле в IP хедъра (примерно в Window$ - ping -r) за да проследи през какви машини минава пакета, докато стигне целта си.

 

С една дума, вашата машина остава прозрачна. По пътя на логиката, и traceroute (Window$ - tracert) няма да ви вижда.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
Редактирано от programings (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

При мен по подразбиране е нула :)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Да, на всяко едно ядро е така, мерки за сигурност по подразбиране, но ако нещо го позволи - това е файла и начина да се отмени. :)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

Общото правило за създаване на собствени ядра е "да изключите всичко не нужно."

 

Така нe само ще получите по малко ядро, но и ще избегнете грешки в недовършени части от изходния код на ядрото. Като общо правило трябва да включва изключването на модула за поддръжка - [ ] Enable loadable module support. Инжектиране на root kit по време на изпълнение, по този начин, ще бъде много по трудно зa всеки нарушител.

 

proc-Script.sh 

#!/bin/sh## DECLERATION of the VARIABLES ##echo="/bin/echo"## for GENTOO-Users ##depend() {use checkroot}## other SPECIAL OPTIONS for this script ### ...## BEGINNING to WORK ##$echo "Setting /proc options ..."$echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all$echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts$echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route$echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects$echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses   for i in /proc/sys/net/ipv4/conf/*; do      $echo "1" > $i/rp_filter   done$echo "1" > /proc/sys/net/ipv4/conf/all/log_martians$echo "0" > /proc/sys/net/ipv4/ip_forward$echo "DONE"exit 0 

Изходен код

Редактирано от ivoarch (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Като общо правило трябва да включва изключването на модула за поддръжка - [ ] Enable loadable module support. Инжектиране на root kit по време на изпълнение, по този начин, ще бъде много по трудно зa всеки нарушител.

Второто изречение е вярно, но първото не е много лесно за всяка машина. Особено ако определен драйвер идва само като външен модул. На мен ми се е случвало за различни неща.Предпочитам SELinux - само тия модули, които аз кажа, могат да се зареждат.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Общото правило за създаване на собствени ядра е "да изключите всичко не нужно." ....

Това е интересно твърдение, само че лично за мен е безсмислено. Преди години мярнах един тест, който сравняваше производителността на RHEL със готовото ядро и Генту(дженту). И резултата от перформънс тестовете беше равен, някъде в полза на едната, някъде в полза на другата. Не знам защо хората си мислят че къстъм ядрото ще е много по-малко и по-бързо :)

 

По-долното деактивира source routing-а на kernel-а, и машината става невидима за някой, който да речем използва ping със зададено record route поле в IP хедъра (примерно в Window$ - ping -r) за да проследи през какви машини минава пакета, докато стигне целта си.

 

С една дума, вашата машина остава прозрачна. По пътя на логиката, и traceroute (Window$ - tracert) няма да ви вижда.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

СОрс рутинга пред доста време беше добър начин за атакуване на отдалечени машини, само че поне последните конфигурации на маршрутизатори и операционни системи го забраняват по подразбиране. Но нищо не пречи да се нулира  за всеки случай. Но ще е по-добре това да се направи през /etc/sysctl.conf

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

И моите наблюдения са, че махането на модули не оказва почти никакво влияние върху работата на системата. Компилирането трябва да се прави с конкретна цел - задаване на определени параметри, а да се търси увеличена производителност с премахването на модули е безсмислена работа.

Затова въпреки първоначалните ми залитания, сега си работя само с щатни ядра. 

Редактирано от cybercop (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Това е интересно твърдение, само че лично за мен е безсмислено. Преди години мярнах един тест, който сравняваше производителността на RHEL със готовото ядро и Генту(дженту). И резултата от перформънс тестовете беше равен, някъде в полза на едната, някъде в полза на другата. Не знам защо хората си мислят че къстъм ядрото ще е много по-малко и по-бързо :)

Вярно, но това са аргумени срещу "орязването", като средство за вдигане на производителността, а не изцяло. Естествено, че няма да се вдигне производителността, то ако овърхеда на ядрото беше толкова голям... Но все пак може да имаш и други причини да орежеш ядрото. Като цяло (не винаги) колкото по-малко код, толкова по-сигурно и по-малко проблеми. Не е причина да преконфигурираш и прекомпилираш ядрото, но ако ще го правиш така или иначе, що да не махнеш това което не ти трябва.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Вярно, но това са аргумени срещу "орязването", като средство за вдигане на производителността, а не изцяло. Естествено, че няма да се вдигне производителността, то ако овърхеда на ядрото беше толкова голям... Но все пак може да имаш и други причини да орежеш ядрото. Като цяло (не винаги) колкото по-малко код, толкова по-сигурно и по-малко проблеми. Не е причина да преконфигурираш и прекомпилираш ядрото, но ако ще го правиш така или иначе, що да не махнеш това което не ти трябва.

Хм, това за големината на кода и грешките е вярно, но ако промениш размера с порядък :) Примерно размера на сорса на ядрото на QNX е (по спомени) към 80к и при него можеш да потвърдиш че има по-малко грешки. А при линукс системата за управление на модулите е достатъчно добра и ако човек знае какво му трябва няма смисъл да го вгражда когато може да го зареди динамично. Вярно е че има случаи при които се налага да се променят параметри, които са вградени (примерно такта за обхождане на ринга с процесите) но те са по-скоро изключение. Освен това ако ползваш нещатното ядро на RHEL и имаш проблем съпорта директно те отсвирва

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

То цялата работа с конфигуриране на ядрото е че имаш възможноста да махаш съпорт за определен хардуер.Пък най-много което можеш да спечелиш от към "производителност" (това е доста странно щото имаше един тук дето твърдеше че,бързото зареждане на ОС е много важно  :lol6: )

Общото правило за създаване на собствени ядра е "да изключите всичко не нужно."

 

Така нe само ще получите по малко ядро, но и ще избегнете грешки в недовършени части от изходния код на ядрото. Като общо правило трябва да включва изключването на модула за поддръжка - [ ] Enable loadable module support...

Това е доста странно има някои неща които искат "работа" за да работят както трябва.Примерно KMS.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

СОрс рутинга пред доста време беше добър начин за атакуване на отдалечени машини, само че поне последните конфигурации на маршрутизатори и операционни системи го забраняват по подразбиране. Но нищо не пречи да се нулира  за всеки случай. Но ще е по-добре това да се направи през /etc/sysctl.conf

 

Което от една страна е добре за сигурността, но от друга пък си е малко жалко, защото е чудесен способ за засичане например на ARP poisoning за да се види дали има man-in-the-middle.

Редактирано от programings (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

но ако ще го правиш така или иначе, що да не махнеш това което не ти трябва.

И аз съм на това мнение. Можеби защото съм минималист по рождение :)

 

Като цяло (не винаги) колкото по-малко код, толкова по-сигурно и по-малко проблеми.

(Да) Но да не забравяме също, че простотата е в сърцето на Unix философията.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

.... щото имаше един тук дето твърдеше че,бързото зареждане на ОС е много важно  :lol6: )

 

Дали е важно - не знам. Но определено е доста приятно да ти зареди системата за 10 секунди и да изключи за две. 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Дали е важно - не знам. Но определено е доста приятно да ти зареди системата за 10 секунди и да изключи за две. 

Жалко оня ден спря тока и бях само на 31 дена uptime.Стана ми много гадно щото системата ми зарежда не за 10 а за 30 секунди :(

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

ако човек знае какво му трябва няма смисъл да го вгражда когато може да го зареди динамично.

Ха, логически е точно обратното. Идеята на модулите е да не бараш самото ядро, при различен хардуер, ами да заредиш каквото ти трябва към момента. Ако знаеш какво точно ще ползваш, нещото се съпортва като вградено и (подчертавам) трябва да прекомпилираш ядрото, няма никаква причина да искаш да ти е модул.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Ха, логически е точно обратното. Идеята на модулите е да не бараш самото ядро, при различен хардуер, ами да заредиш каквото ти трябва към момента. Ако знаеш какво точно ще ползваш, нещото се съпортва като вградено и (подчертавам) трябва да прекомпилираш ядрото, няма никаква причина да искаш да ти е модул.

Може би не се изразих точно, идеята ми е че след като знам какво ми трябва мога да си ползвам системата за зареждане на модули. И по принцип не виждам смисъл да се прави "монолитно" ядро

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Можеби, няма да е зле всичkо това изписано до тук, да отида някаде в (линукс) като "тема за Компилиранe на Ядрото".

 

Темата може да включва:

 

Защо в тези дни потребителите на Linux  конфигурирате и компилирате ядрото?

За подобряване на производителността или на съвместимостта на хардуера? За да добавите поддръжка за файловата система или включване на експериментални възможности? Просто за забавление? Опит за абсолютно най-малко ядрото може би? Опит за изграждане на високо преносимо ядрото?Също така, какви са проблемите при повечето хора, когато компиларат ядрото?

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Може би не се изразих точно, идеята ми е че след като знам какво ми трябва мога да си ползвам системата за зареждане на модули. И по принцип не виждам смисъл да се прави "монолитно" ядро

Ми то от програмистка точка си е монолитно. Не е микроядро, независимо дали са модули или не. Аз пък не виждам смисъл, защо ще зареждам едни и същи модули, след като мога да си ги сложа в ядрото :) Но пак казвам, ако ще прекомпилирам ядрото. Но няма да седна да го прекомпилирам само за да не зареждам модули. 

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Можеби, няма да е зле всичkо това изписано до тук, да отида някаде в (линукс) като "тема за Компилиранe на Ядрото".

 

Темата може да включва:

 

Защо в тези дни потребителите на Linux  конфигурирате и компилирате ядрото?

За подобряване на производителността или на съвместимостта на хардуера? За да добавите поддръжка за файловата система или включване на експериментални възможности? Просто за забавление? Опит за абсолютно най-малко ядрото може би? Опит за изграждане на високо преносимо ядрото?Също така, какви са проблемите при повечето хора, когато компиларат ядрото?

Не виждам смисъл защото самото упражнение по компилиране на ядрото е интересно, може да е добро предизвикателство, останалото е безсмислено

А проблемите, които срещат хората при компилиране е че не четат и не мислят :)

Ми то от програмистка точка си е монолитно. Не е микроядро, независимо дали са модули или не. Аз пък не виждам смисъл, защо ще зареждам едни и същи модули, след като мога да си ги сложа в ядрото :) Но пак казвам, ако ще прекомпилирам ядрото. Но няма да седна да го прекомпилирам само за да не зареждам модули. 

Не, то е хибридно. И има много хляб да изяде ако реши да стане микроядро :) ТО не че микроядрата стават за всеки случай от живота, но за целите си си вършат добре работата

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Ок капитане, попитах понеже се писа доста за това, и стана интересна тема.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Не, то е хибридно. И има много хляб да изяде ако реши да стане микроядро :) ТО не че микроядрата стават за всеки случай от живота, но за целите си си вършат добре работата

Монолитно е, като стой та гледай. Ако модула крашне, крашва цялото ядро без право на обжалване. В Уиндоус не е задължително за сравнение.

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Монолитно е, като стой та гледай. Ако модула крашне, крашва цялото ядро без право на обжалване. В Уиндоус не е задължително за сравнение.

Зависи в кой ринг е модула. Ако е в 3 няма проблем и да крашне. Но ако е в 0 - си прав :)

А WIndows NT 3.5 слагаше всички модули в ринг 3 и беше железен

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

Да се върнем на темата ;)

 

Скрипт за първоначално гонфигуриране на git.

 

Какво е git? - може да искате да прочетете тази тема писана от колегата @flare

 

Начин на прилагане:

 

1. Запази някаде в path, като на-пример: setup-git.sh

2. Инсталирай git за вашата дистрибуция.

3 Изпълни скрипта.

~$ ./setup-git.sh username usermail 
#!/bin/shif [ ! $# -eq 2 ];then    echo "usage: sh $0 username usermail"    exit;fiusername=$1useremail=$2# User namegit config --global user.name $username# User mailgit config --global user.email $usermail# Set git to use the credential memory cachegit config --global credential.helper cache# Set the cache to timeout after 1 hour (setting is in seconds)git config --global credential.helper 'cache --timeout=3600'

Командите са взети от setup-git

Редактирано от ivoarch (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

Да се върнем на темата ;)

Бих допълнил, че използването на --global флага на git config, трябва да се обмисли. Много често имате различни потребителски имена за различните репо-та и в този случай е наложително да си конфигурирате потребителското име и поща за всяко поотделно. Затова в моя пример не съм го използвал. Git ще използва локалната конфигурация с предимство пред глобалната.

Глобалните конфигурации се намират в файла ~/.gitconfig примерно горните команди ще създадат нещо такова:

[user]    name = "<вашето-име>"    email = "<вашата-поща>"....
Редактирано от flare (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове
публикувано (редактирано)

Да така е, но затова нали има public_key ?

Май нещо нете разбрах, сори :)

 

В този случай май трябва да се използва --local вмсето --global, нещо такова май беше.

едит: Или просто нито едно от двете.

 

Бих допълнил, че използването на --global флага на git config, трябва да се обмисли. Много често имате различни потребителски имена за различните репо-та и в този случай е наложително да си конфигурирате потребителското име и поща за всяко поотделно. Затова в моя пример не съм го използвал. Git ще използва локалната конфигурация с предимство пред глобалната.

Глобалните конфигурации се намират в файла ~/.gitconfig примерно горните команди ще създадат нещо такова:

[user]    name = "<вашето-име>"    email = "<вашата-поща>"....
Редактирано от ivoarch (преглед на промените)

Сподели този отговор


Линк към този отговор
Сподели в други сайтове

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Гост
Напишете отговор в тази тема...

×   Вмъкнахте текст, който съдържа форматиране.   Премахни форматирането на текста

  Разрешени са само 75 емотикони.

×   Съдържанието от линка беше вградено автоматично.   Премахни съдържанието и покажи само линк

×   Съдържанието, което сте написали преди беше възстановено..   Изтрий всичко

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Добави ново...