Изпечатай

[ώ€β€$ţ๏๏ℓ$]

Здрасти. Пуснал съм триял сървър и за по-удобно искам да си остана с роот достъп докато се упражнявам.
Все пак искам да забраня достъп през ssh освен от моето ип.
Вършат ли ми работа следните команди:
sudo ufw enable

Код:

ufw allow proto tcp from xxx.xxx.xxx.xxx to any port 80
ufw allow proto tcp from any to any port 80
ufw allow proto tcp from xxx.xxx.xxx.xxx/yy to any port 80

Код:

Status: active

To                         Action      From
--                         ------      ----
22                         LIMIT       Anywhere
443                        ALLOW       Anywhere
80                         ALLOW       Anywhere
80/tcp                     ALLOW       xxx.xx.xx.11
22 (v6)                    LIMIT       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)

Кои други портове трябва да забраня?

[Acho]

Или пък с директивата:

AllowUsers acho mitko vanko

поставена в sshd_config на твоята дистрибуция. Само описаните юзери ще могат да се логват по ssh. Даже недей като root да влизаш през ssh-a. Влез си с нормалния юзер и после стани root.

[ώ€β€$ţ๏๏ℓ$]

Забелязвам , че всички правят това... Толкова ли лесно се разбива тази парола дори да е силна?
То мисълта ми беше да забраня достъпа през firewall само до моето ип...сигурно може да се спуфне?
Просто да има някаква минимална защита докато се човъркам по командите и тн...
Плюс това го ребилдвам през 1-2 два да пробвам различни дистрибуции...

п.с Някой може ли да ми каже какво е ttyS0 и tty1? (firewall правилата които съм създал?)

Код:

root@Worddrop:~# who -a
           system boot  2017-03-30 23:40
LOGIN      ttyS0        2017-03-30 23:40              1565 id=tyS0
LOGIN      tty1         2017-03-30 23:40              1564 id=tty1
           run-level 5  2017-03-30 23:40
root     - pts/0        2017-03-31 17:21   .         24146 (ййй.йй.йй.йй)
root@Worddrop:~# who -l
LOGIN    ttyS0        2017-03-30 23:40              1565 id=tyS0
LOGIN    tty1         2017-03-30 23:40              1564 id=tty1
root@Worddrop:~# who -u
root     pts/0        2017-03-31 17:21   .         24146 (ййй.йй.йй.йй)

[ddantgwyn]

Забелязвам , че всички правят това... Толкова ли лесно се разбива тази парола дори да е силна?
То мисълта ми беше да забраня достъпа през firewall само до моето ип...сигурно може да се спуфне?

В такъв случай не ограничавай достъпа по IP адрес.

Влизай на сървъра само с ключ и забрани влизането отдалечено изобщо с парола. Инсталирай и denyhosts за да ограничиш до 3-4-5 опитите за влизане през ssh и това е -- може вече да спиш почти спокойно.   

[ώ€β€$ţ๏๏ℓ$]

Все пак ме интересува кои други портове могат да се ограничат при горния вариант и защо не е надежден?
Няма ли да намали опитите за свързване към сървъра ?
Ограничил ли съм порт 80 правилно или мога ли да му поставя маска пр. 212.212.xxx.xxx и как ?


1) Смених юзъра, сложих му права ALL през visudo и го добавих в sudo групата? И 2-те неща ли се правят или само едното стига за правилен достъп?
2) Спрях root достъпа и спрях root usera с passwd -l root

При една комбинация с Last Pass (не че ползвам ) има ли смисъл от криптиращ ключ при положение , че е горе долу същото?
(при положение , че паролата се праща криптирана ...)

Сега ще видя и с ключа как стават нещата , но един път май го оплесках и после нямах достъп. Както и denyhosts , но ми се стори по-лесно да огранича с ип...

[growchie]

абе хора, за вас iptables няма ли?
iptables -A INPUT -p tcp --dport 22 -s tvoeto_ip -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

След това трябва само iptables-save и готово. Ако спазиш реда няма да има проблеми, правилата се траверсват едно след друго и като има меч веригата не се обработва нататък. По-умното е политиката ти на INPUT веригата да е DROP и тогава само първия ред ти трябва.

ufw?! що за перверзия, обвивка на iptables

[go_fire]

Чакайте сега. Нали говорим за ssh? Ами той си има директива по IP. Ама ми е интересно, ако реши да влезе от друго, как ще стане последовател на Любо Пенев.

[growchie]

80 е нттп, 22 ссх. Го_файър правилно отбеляза за портовете. Иначе, никога, никога, никога не оставяйте root логин-и към 22 порт. Брут форс скриптовете ще ви побъркат машините да се тестват с всякакви глупости за пароли. Лично аз забранявам изцяло 22 порт и просто си правя редирект от някой друг. Неудобството е, че трябва да се указва порт при ssh от клиента но поне диска ти не оре да проверява фалшиви логини.

[deant01]

освен да ограничиш с ключ, потребител и руут, може да нагласиш ssh да не е на порта по подразбиране, а на някакъв който само ти знаеш, примерно 2744. Така дори някой да сканира за отворен порт на 22, няма да види нищо и няма разни ботове да пробват да се логнат. Както казаха колегите, ограничаване по IP не е много удобно в случай, че някой ден си на майната си, а ти трябва спешен достъп.

[ώ€β€$ţ๏๏ℓ$]

Махнах Ufw

Код:

sudo ufw disable
sudo apt-get remove ufw
sudo apt-get purge ufw
iptables -F
iptables -Z
reboot

Така ли се прави?

Ще пробвам директно с iptables след това , още са са ми сложни ии трябва ли да ги направя persistent?

Относно порта и AllowUser достъпа тук ли се сменят/добавят?.

Виждам, че и PasswordAuthentication като цяло може да се спре и да пусне за определено ип.
PasswordAuthentication no  - в конфига и най-отдолу:
Match Address 1.2.3.4
    PasswordAuthentication yes

Каква е разликата между AllowUser и Match user? И в кои случаи се ползва MatchUser?

п.с За порта си прав , веднага се мяркат разни китайски ип-та и тн. Само даkf не се налага да настройвам още нещо заради него , пък и с port scanner едва ли ще остане скрит за дълго...

[pennywise]

В SSH с MatchUser се правят настройки за единичен потребител, може и за група с MatchGroup, ето първия линк от гугъл - https://security.stackexchange.com/questions/18036/creating-user-specific-authentication-methods-in-ssh

Няма проблем с позлване на пароли стига да не е за руут и да не ползваш стандартния порт и паролите да са над 8 символа.
Като видя SSH на 22 и леко ми се повдига. Особено на CentOS и други като се логнеш и ти изпише колко невалидни опита са направени.
Огромна част са ботове които пробват да brute-force-нат руут от някой стандартен лист с пароли.

Че даже и намерих един такъв, ето снимка за радост на окото-


Паролите понякога са удобни а в някой случаи и необходими.

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

[ddantgwyn]

Брут форс скриптовете ще ви побъркат машините да се тестват с всякакви глупости за пароли. Лично аз забранявам изцяло 22 порт и просто си правя редирект от някой друг. Неудобството е, че трябва да се указва порт при ssh от клиента но поне диска ти не оре да проверява фалшиви логини.

Не мисля, че тези скриптове са някакъв особен проблем. Изобщо не я разбирам тази обсесия по махането на порт 22, особено ако си инсталирал denyhosts и си забранил влизането с парола.

[ddantgwyn]

Няма проблем с ползване на пароли стига да не е за руут и да не ползваш стандартния порт и паролите да са над 8 символа.

Като видя SSH на 22 и леко ми се повдига. Особено на CentOS и други като се логнеш и ти изпише колко невалидни опита са направени.

Огромна част са ботове които пробват да brute-force-нат руут от някой стандартен лист с пароли.

А на мен леко ми се повдига като чета, че на някой друг му се повдига по такъв повод. Погледни какво ще ти каже nmap с ключове -Т5 -А -- дали няма да лъсне порта, на който слуша ssh

Паролите понякога са удобни а в някой случаи и необходими.

Това е така.

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

А има ли някакъв проблем тези файлове да се прибират от страна на сървъра, а не от страна на клиента?

[growchie]

Запазването на правилата на iptables е реализирано по различен начин от различните дистрибуции, но в общи линии повечето имат save  опция в init скрипта си, така че може да е нещо от сорта на service iptables save или rc-service iptables save или направо /etc/init.d/iptables save или нещо подобно.

Тия скриптове ти пълнят логовете с простотии и накрая няма да разбереш ако има наистина инцидент.
Скрити портове се откриват ако има разлика в политиките на отказване на пакетите. Ако примерно си дал -j REJECT за порт другият хост ще получи icmp host unreachabe и ако настройката на машината за невалидни портове просто е да DROP пакета без отговор, излиза при сканиране.

Файърлола може да си го преглеждаш с iptables -L -v това е за filter таблицата. Ако ще се занимаваш с манипулиране на пакетите или с nat и пренасочване на портовете ти трябват съответно -t mangle и -t nat като парамети веднага след iptables. Много внимавай като си играеш да не се заключиш от машината.
Файърлол в линукс директно може да се управлява и с nftables което е новото нещо, но не препоръчвам да се месят понеже няма начин да разбереш с единия инструмент дали няма правила записани от другия.

[pennywise]

А на мен леко ми се повдига като чета, че на някой друг му се повдига по такъв повод. Погледни какво ще ти каже nmap с ключове -Т5 -А -- дали няма да лъсне порта, на който слуша ssh

Сменянето на порта е нещо съвсем тривиално което спестява шум и дразненето да видя 300 000 провалени опита за логин за 2 седмици. Естесвено, че ако някой иска ще разбере на кой порт слуша ще го направи. В общи линии е доста обезкуражаващо да се пробваш ако видиш, че порт не е стандартния. Просто можеш да си спестиш за 3 секунди работа над 90% от тривиалните "атаки". Отделно може да ползваш fail2ban - той ще се погрижи за iptables и ще банва ИП-та според определните правила, ако някой толкова е изтерясал на тема сигурност.
Мен лично ме дразни да ползвам стандартния 22-ри, според мен е лоша практита, но това си е мое лично мнение.

А има ли някакъв проблем тези файлове да се прибират от страна на сървъра, а не от страна на клиента?

Да ,има. Много от клиентските машини(да не кажа всички) са зад firewall и позволят ssh достъп само от определени единични машини - relay/jumpbox както искаш им кажи.