Forum Debian Users Gang

Failban? Psad? lepiej iptables - hashlimit lub recent, na forum i necie jest masa przykładów.
(recent był też w howto na starym dugu, o ile pamiętam).
A port najlepiej jakiś 5 cyfrowy - z ostatniego totolotka. :D
root?  zamiast wyłączania, lepiej without-password, wtedy pójdzie tylko po kluczu, ale np u mnie pyta o hasło, choć i tak nie zaloguje hasłem.
Czyli w konfigu sshd:

PermitRootLogin without-password

Do tego limit prób logowania, np:

MaxAuthTries 2

rozłączy po 2 próbach.


Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2013-04-06 16:38:30)

mam rozumiec ze te zmiany co mi proponujecie w pliku sshd_config mam odhaszowac i wpisac nowe parametry, bo puki co wiekszosc wpisow tam jest zahaszowania,
sory za lamerskie podejscie ale niewiele z tym mialem do czynienia do tej pory. (spodziewajcie sie wiecej glupich pytan).

a czy klucze rsa mam generowac z roota czy ze zwyklego konta.???

zrobilem sobie klucze skopiowalem na server potem do pliku .ssh/authorized_keys

potem:

ssh-agent bash
ssh-add .ssh/id_rsa

przy probie logowania dostaje

no such identity: /home/przemo/.ssh/id_dsa: No such file or directory
no such identity: /home/przemo/.ssh/id_ecdsa: No such file or directory

i tradycyjnie pytanie o haslo???

Ostatnio edytowany przez pink (2013-04-06 18:08:32)

enether napisał(-a):

recent i haslimit bardziej do ograniczania połączeń ....

O to właśnie chodzi, jednym i drugim możesz obciąć połączenia NEW tcp np do 5 na godzinę, albo 20 na miesiąc.

Albo hardcorowo:
Tablica ipset np banany:

ipset create banany hash:ip

iptables -t raw -I PREROUTING -i eth0 -p tcp -m multiport --dports {porty_pułapki}   -j SET  --add-set banany  src

iptables -t raw -I PREROUTING -i etho -m set --match-set banany src -j DROP

Jakie  porty pułapki? porty wrażliwych usług, np ssh, mssgl, mysql, pgsql, albo takie, po których standardowo leci nmap, albo cały zakres od 1023 do 10156.
Kłania się podstawowa znajomość /etc/services.
Poza tym na skanery portów bardzo sympatyczny jest TARPTI z xtables-addons, można też przy pomocy hashlimit objąć wszystkie porty, i w ten sposób dziubdziuś po próbie skanowania nie znajdzie żadnych usług, oprócz tych, które wyłączymy z ochrony.
:D

@enether
W czym psad czy failban są lepsze od powyższego rozwiązania?

Bo to jest zrobione samym firewallem, bez żadnych dodatkowych demonów, które trzeba aktualizować i pilnować.

Ostatnio edytowany przez Jacekalex (2013-04-06 18:40:06)

enether napisał(-a):

Tak na szybko to tyle. W każdym razie -> UWAŻAJ robiąc którąkolwiek z powyższych czynności. Bardzo łatwo stracić dostęp do maszyny przez przypadek :P

no i stalo sie.

 iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request ctstate NEW
UDP        udp  --  anywhere             anywhere             ctstate NEW
TCP        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW
REJECT     all  --  anywhere             anywhere             reject-with icmp-proto-unreachable
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request limit: avg 30/min burst 8
DROP       icmp --  anywhere             anywhere             icmp echo-request
REJECT     tcp  --  anywhere             anywhere             recent: SET name: TCP-PORTSCAN side: source mask: 255.255.255.255 reject-with tcp-reset
REJECT     udp  --  anywhere             anywhere             recent: SET name: UDP-PORTSCAN side: source mask: 255.255.255.255 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain TCP (1 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere             recent: UPDATE seconds: 60 name: TCP-PORTSCAN side: source mask: 255.255.255.255 reject-with tcp-reset
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

Chain UDP (1 references)
target     prot opt source               destination         
REJECT     udp  --  anywhere             anywhere             recent: UPDATE seconds: 60 name: UDP-PORTSCAN side: source mask: 255.255.255.255 reject-with icmp-port-unreachable
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain

tu jest iptables

Wiem, bawiłem się. Konfiguruje się nieco mozolnie. Tyle że jak na zabezpieczanie dajmy na to małego VPS'a na upośledzonym OpenVZ to po pierwsze overkill, po drugie awykonalne technicznie. Podobnie jak bardziej wyrafinowane cudeńka w iptables.

No a wracając do kolegi pink'a:

To iptables na serwerze czy na kliencie?

Czyli na twoim PC/Lapku. Troszkę overkill. Wszystkie rady których do tej pory udzielaliśmy odnosiły się do konfiguracji serwera.

Ze strony klienta opcji zabezpieczeń dużo mniej. Ot pilnuj klucza prywatnego i zrób sobie firewall podstawowy oraz powyłączaj zbędne usługi jeżeli jakieś masz.
Możesz pogrzebać w /etc/ssh/ssh_config  (nie sshd_config)  by ustalić domyślne zachowania klienta ssh, jak choćby w jakiej kolejności ma próbować algorytmów szyfrujących.


Tutaj dla przykładu prosty firewall który u mnie na lapku zdaje egzamin.

iptables -P INPUT ACCEPT
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "netfilter: "
iptables -A INPUT -j DROP

Krótki opis: Wpuszcza jedynie połączenia nawiązane i powiązane z ruchem wychodzącym, wpuszcza wszystko na loopbacku oraz przepuszcza ICMP Echo Request.
Wszystko inne jest logowane (rsyslog ustawiony by leciało gdzie indziej niż do sysloga) a następnie dropowane.

Ostatnio edytowany przez enether (2013-04-06 21:55:46)

W kwestii kluczy - lepiej niż załoga G tego nie ujmę, więc zarzucę tylko linkiem
http://www.gentoo.org/doc/pl/articles/openssh-key-management-p1.xml
(oraz części następne)

ssh-agent i keychain można używać, ale nie ma takiego obowiązku.
Raczej dla bezpieczeństwa lepiej przenieść klucze z domyślnej lokalizacji ~/.ssh, w jakąś niestandardową, albo zablokować dostęp innych programów do folderu z kluczami przy pomocy jakiegoś systemu ACL.

W ogóle najpierw trzeba ustalić, czy klucz ssh działa, a dopiero później odpalać ssę-agenta i keychain.

Ssh-agent natomiast się przyda przy Gnome-keyring czy Kwallet.
Sznurki:
https://wiki.archlinux.org/index.php/GNOME_Keyring#SSH_Keys
https://wiki.archlinux.org/index.php/KDE_Wallet

enether napisał(-a):

Krótki opis: Wpuszcza jedynie połączenia nawiązane i powiązane z ruchem wychodzącym, wpuszcza wszystko na loopbacku oraz przepuszcza ICMP Echo Request.
Wszystko inne jest logowane (rsyslog ustawiony by leciało gdzie indziej niż do sysloga) a następnie dropowane.

Na te logi firewalla masz osobny dysk, czy starcza osobna partycja?

Kod:

iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Jak Ci ktoś kiedyś przyśle kilka tysięcy pakietów ICMP, to pokochasz moduł limit firewalla całym sercem.
W normalnych warunkach ICMP się wpuszcza najwyżej X/s, modułem limit, albo 3/s per pacjent hashlimitem.

Ostatnio edytowany przez Jacekalex (2013-04-07 10:17:54)

Jacekalex napisał(-a):

enether napisał(-a):

Krótki opis: Wpuszcza jedynie połączenia nawiązane i powiązane z ruchem wychodzącym, wpuszcza wszystko na loopbacku oraz przepuszcza ICMP Echo Request.
Wszystko inne jest logowane (rsyslog ustawiony by leciało gdzie indziej niż do sysloga) a następnie dropowane.

Na te logi firewalla masz osobny dysk, czy starcza osobna partycja?

Kod:

iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

Jak Ci ktoś kiedyś przyśle kilka tysięcy pakietów ICMP, to pokochasz moduł limit firewalla całym sercem.
W normalnych warunkach ICMP się wpuszcza najwyżej X/s, modułem limit, albo 3/s per pacjent hashlimitem.

Tak, zdaję sobie z tego doskonale sprawę. Ale w myśl ogólnej zasady "skoro działa nie ruszać" jestem zbyt leniwy by to poprawić.
Poza tym to lapek, nie serwer. Okazji do DoS'owania go specjalnie nie ma. W sumie muszę logi polimitować, bo mniej miłe od odcięcia sieci jest zapchanie dysku, więc przy okazji dorzucę limit na pakiety.

Można prosić o sugestię w kwestii w miarę logicznego i wydajnego logowania pakietów per źródło? Dajmy na to 60 pakietów per IP na minutę?
Bo można by w sumie dorzucić do linijki z -j LOG jeszcze -m limit --limit 60/m ale to będzie miało zastosowanie globalne, tzn 60 wpisów do logu ogólnie, nie per IP.


EDIT:

-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 10/sec --limit-burst 20 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -m limit --limit 1/sec --limit-burst 20 -j LOG --log-prefix "netfilter: "

I zobaczymy jak to się będzie sprawować.

Ostatnio edytowany przez enether (2013-04-07 20:39:13)