CentOS 7 - fail2ban / ssh - Wat doe ik fout?

[WeHoDo]

Relevante software en hardware die ik gebruik
VPS met CentOS 7
SSH
fail2ban

Wat ik al gevonden of geprobeerd heb
How-to's gelezen op CentOS fora's en andere step-by-step Youtube videos.

Mijn vraag:
Ik heb een nieuw geïnstalleerd VPS met CentOS 7 (Zonder Plesk).
Om direct deze server goed te beveiligen, heb ik het standaard SSH poort 22 aangepast naar een andere poort.

vi /etc/ssh/sshd_config
port 1234
systemctl restart sshd.service

Vervolgens heb ik ook fail2ban geinstalleerd:
yum install epel-release
yum install fail2ban
systemctl enable fail2ban

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
vi /etc/fail2ban/jail.local

In dit bestand heb ik een paar dingen aangepast:
Bantime 600 naar 3600

En aangepast / toegevoegd:

[sshd]
enabled = true
port = 1234
logpath = /var/log/secure

Het bestand uiteraard opgeslagen met :wq.
Vervolgens reboot ik de server, maar ik kom niet meer ingelogd op ssh via poort 1234.

Wat doe ik fout?
Ik heb ook op een virtuele machine op mn laptop centos 7 geïnstalleerd en hetzelfde uitgevoerd, en dan werkt alles wel na een reboot. Kan er een verschil zitten tussen een VPS install en een local install op mn laptop?

[MAX3400]

[sshd]
maxretry = 5
port = ssh

Tenminste, ik zie nu niet hoeveel retries/pogingen je toestaat dus kan me voorstellen dat nu al het SSH-verkeer afgevangen wordt.

Andersom, heb je al gekeken of er in je iptables een verschil bestaat tussen je lokale en VPS inrichting?

[WeHoDo]

MAX3400 schreef op maandag 27 augustus 2018 @ 20:58:
[sshd]
maxretry = 5
port = ssh

Tenminste, ik zie nu niet hoeveel retries/pogingen je toestaat dus kan me voorstellen dat nu al het SSH-verkeer afgevangen wordt.

Andersom, heb je al gekeken of er in je iptables een verschil bestaat tussen je lokale en VPS inrichting?

Met maxretry heb ik niks aan aangepast, en zou standaard 5 moeten zijn.
# "bantime" is the number of seconds that a host is banned.

bantime = 3600

# A host is banned if it has generated "maxretry" during the last "findtime"

# seconds.

findtime = 600

# "maxretry" is the number of failures before a host get banned.

maxretry = 5


Iptables van virtueel en vps zijn beide leeg.

[canonball]

probeer eerst eens fail2ban met poort 22, het nut van een andere poort is beperkt. Een firewall is wel zinvol.
Ik weet niet of centos7 standaard selinux aan heeft staan, maar daar kan het in zitten.

[MAX3400]

Kan je misschien proberen om in je jail.conf eens je eigen WAN-IP op te nemen?

code:

ignoreip=xxx.yyy.zzz.aaa

Ik dacht, maar oude kennis, dat alleen 127.0.0.1 nog voor SSH toegestaan was als je je default jail aanzette.

[deagan1337]

systemctl stop firewalld

kun je dan wel connecten?

[WeHoDo]

Herinstalleer even de VPS, heb nu teveel dingen aangepast.
Be right back, alvast bedankt voor de respons.

[belrpr]

Is volgens mij ook de firewall.
Kon je na aanpassen van de poort en voor de activatie van fail2ban wel connecteren.

[WeHoDo]

belrpr schreef op maandag 27 augustus 2018 @ 21:13:
Is volgens mij ook de firewall.
Kon je na aanpassen van de poort en voor de activatie van fail2ban wel connecteren.

Kan ik je helaas niet goed op antwoorden, had ze allebei aangepast en toen een reboot.
Zal nu, als de VPS weer up is, het stap voor stap doen en telkens rebooten.

Dus eerst poort aanpassen, reboot, dan fail2ban installeren, reboot etc.

[Hero of Time]

Typisch geval van firewall en selinux. Vooral die laatste, als deze bij de VPS standaard aan staat (sommige hosters hebben 'm standaard uit, puur om 'lastige' calls tegen te gaan ). Je kan niet zomaar je ssh daemon op een andere poort draaien. Reden dat je het pas na een reboot merkt, is omdat je bestaande ssh sessie niet wordt gesloten bij een herstart van sshd.

[WeHoDo]

VPS is up en heb direct de poort aangepast. Reboot en kan nog steeds via SSH inloggen.

Vervolgens Selinux gechecked:
sestatus
SELinux status: disabled

Ga nu fail2ban installeren met ssh port nog op 22.

[ Voor 14% gewijzigd door WeHoDo op 27-08-2018 21:23 ]

[canonball]

Maar aangezien je zo bezig bent met security, ga je als alles werkt toch wel selinux aanzetten en werkend maken?

[WeHoDo]

canonball schreef op maandag 27 augustus 2018 @ 21:25:
Maar aangezien je zo bezig bent met security, ga je als alles werkt toch wel selinux aanzetten en werkend maken?

Uiteraard, alleen omdat ik al niet verder kwam met fail2ban, nog niet naar selinux gekeken.
Op mn debian vps-en heb ik ook hetzelfde aangepast en werkte het wel. Lijkt erop dat er iets met CentOS zelf is.

Ben nu bezig met rebooten...

[Hero of Time]

Firewall in principe, want bij Debian heb je die ook niet standaard, terwijl dat bij CentOS wel standaard erop staat.

Enne, als je toch zo veel met security doet, schakel dan password login uit en doe het alleen met een keypair. Kunnen ze proberen te bruteforcen wat ze willen met wachtwoorden, zelfs als ze het juiste wachtwoord raden komen ze er alsnog niet in.

[WeHoDo]

Snap er even niets meer van.
VPS opnieuw geinstalleerd.
SSH poort aangepast.
Reboot
Kan inloggen
Vervolgen SSH pport toegevoegd op IPtables.
Reboot.
Kan inloggen.
Installeren van fail2ban.
En aangepast:

[sshd]
enabled = true
port = ssh
logpath = /var/log/secure
backend = %(sshd_backend)s

Moet ik hier port = ssh aanpassen naar de nieuwe poort: 1234?

[Hero of Time]

Ja, want het zet namelijk specifiek die poort dicht voor degene die fout inlogt. Zo kan je niet meer met SSH erbij, maar als het tevens een webserver is nog wel gewoon de site bezoeken. Als ik F2B even goed herinner, is alweer eventjes geleden dat ik er mee heb gespeeld.

Btw, SSH poort aanpassen is wel erg security through obscurity. En in sommige gevallen kan het zelfs issues opleveren, al kan ik er zo even geen direct herinneren/bedenken.

[ Voor 24% gewijzigd door Hero of Time op 27-08-2018 22:17 ]

[MAX3400]

Mogelijk overbodig maar zet in ieder geval (tijdelijk) je eigen WAN-IP als exception erin. Is best handig want als je een keer zelf het wachtwoord verkeerd intikt, mag je een uur uit je neus gaan eten tot je eigen rule-set je weer toelaat.

[WeHoDo]

Heb nu fail2ban werkend, echter wel met default port 22.
Zodra ik de ssh poort aanpas, gaat het mis en kom ik er niet meer in.
Via recovery mode kan ik de regels weer aanpassen.

Zal de hoster even benaderen of wellicht de SSH port niet aangepast kan worden.
Lijkt me vreemd, maar toch.

[True]

Je kunt echt wel de SSH port aanpassen.

Werkt SSH ook niet als je fail2ban niet aan hebt staan en je SSH op een andere port configured?
Heb je een vorm van firewall draaien welke native CentOS is die dit misschien stopt?

[WeHoDo]

Bedankt zover, ik ga morgen hiermee verder

[_eXistenZ_]

Een berichtje wat ik hier even mis: je poort aanpassen staat bekend als security trough obscurity en het gedachtegoed dat dit veiliger zou zijn is erg gevaarlijk, want het is niet waar.

Iedereen met een port scanner ziet direct weer welke ports open staan en kan vanaf dat punt gelijk weer verder met connecten.

Jij past gelukkig fail2ban toe dus het wordt behoorlijk veilig maar je kunt de combinatie met het aanpassen van de port wel achterwege laten.

[Hero of Time]

_eXistenZ_ schreef op dinsdag 28 augustus 2018 @ 07:57:
Een berichtje wat ik hier even mis: je poort aanpassen staat bekend als security trough obscurity en het gedachtegoed dat dit veiliger zou zijn is erg gevaarlijk, want het is niet waar.

*kuch* Hero of Time in "CentOS 7 - fail2ban / ssh - Wat doe ik fout?"

[agile_tester]

Toen ik mijn CentOS VPS aan het inrichten was, heb ik alle wijzigingen eerst in een virtual box image getest.
Dus snapshot maken > wijziging testen in vb > wijziging doorvoeren in VPS.
Dat heeft mij uiteindelijk veel tijd bespaard.
Bovendien gebruik ik de vb image nu nog steeds om CentOS updates te testen, vóórdat ik mijn VPS update.

[HollowGamer]

agile_tester schreef op dinsdag 28 augustus 2018 @ 09:03:
Toen ik mijn CentOS VPS aan het inrichten was, heb ik alle wijzigingen eerst in een virtual box image getest.
Dus snapshot maken > wijziging testen in vb > wijziging doorvoeren in VPS.
Dat heeft mij uiteindelijk veel tijd bespaard.
Bovendien gebruik ik de vb image nu nog steeds om CentOS updates te testen, vóórdat ik mijn VPS update.

Zeker een goed idee om een test machine te hebben; helaas is het niet altijd hetzelfde, zeker bij dit soort zaken, of is de VM bereikbaar vanaf WAN?

[WeHoDo]

agile_tester schreef op dinsdag 28 augustus 2018 @ 09:03:
Toen ik mijn CentOS VPS aan het inrichten was, heb ik alle wijzigingen eerst in een virtual box image getest.
Dus snapshot maken > wijziging testen in vb > wijziging doorvoeren in VPS.
Dat heeft mij uiteindelijk veel tijd bespaard.
Bovendien gebruik ik de vb image nu nog steeds om CentOS updates te testen, vóórdat ik mijn VPS update.

Dit gaat helaas niet op, omdat ik 2 dezelfde os-en heb. 1 op VPS en 1 op virtueel.
De VPS OS reageert anders dan de virtuele.

Op virtueel pas ik gewoon alles aan en na reboot werkt het ook.
Dezelfde rules en config gebruik ik ook op de VPS en na reboot kom ik er niet meer in.

Anyway, ik heb nu fail2ban werkend, maar wel op de standaard SSH poort.
Als ik aan de reactie hierboven lees, maakt het niet uit voor de veiligheid om deze SSH poort aan te passen, ipv poortscanners?

[mennoo]

Een poort nummer aanpassen heeft niet heel veel zin. Het heeft bijvoorbeeld veel meer zin om:
-Root inlog via ssh uit zetten
-alleen nog inloggen via een ssh-key

[Vesper64]

Poort veranderen heeft wel degelijk nut, al is het beperkt. Poortscans beperken zich over het algemeen tot de meest populair poorten (om tijd te besparen). Daarnaast kan je poortscans natuurlijk ook detecteren en naar handelen.

Dat buiten beschouwing gelaten. Staat SELinux op 'enforcing' zo ja (getenforce), dan moet je ook tegen SELinux zeggen dat je de ssh poort wijzigt. Meer te vinden op http://sharadchhetri.com/...t-number-selinux-enabled/

[WeHoDo]

Het lijkt erop dat de rules die ik aanmaak voor iptables, opgeslagen heb, na een reboot weg zijn.
Als ik iptables -S doe, zie ik geen enkele rules meer, behalve die fail2ban standaard heeft aangemaakt.
Alle andere poorten, zoals 80 en 443 zijn foetsie.

[Ingegno]

WeHoDo schreef op dinsdag 28 augustus 2018 @ 10:41:
Het lijkt erop dat de rules die ik aanmaak voor iptables, opgeslagen heb, na een reboot weg zijn.
Als ik iptables -S doe, zie ik geen enkele rules meer, behalve die fail2ban standaard heeft aangemaakt.
Alle andere poorten, zoals 80 en 443 zijn foetsie.

Waarom gebruik je geen firewalld?

firewalld-cmd --permanent --add-port=[poort]/[protocol]
firewalld-cmd --reload

[WeHoDo]

Lijkt nu opgelost.

Deze stonden uit.
/etc/sysconfig/iptables-config
IPTABLES_SAVE_ON_RESTART="yes"
IPTABLES_SAVE_ON_STOP="yes"

Vreemd, want op mn virtuele omgeving staan deze standaard aan.

Nope, weer niet.

Ga het anders oplossen, dan maar geen fail2ban.

[ Voor 16% gewijzigd door WeHoDo op 28-08-2018 11:15 ]

[Hero of Time]

Dus omdat je obscurity wilt toevoegen en persé SSH op een andere poort wilt draaien, gooi je een pakket er maar uit dat wel iets aan echte security doet? Lijkt mij nou niet echt een verstandige keus.

[pennywiser]

niet je eigen ip gewhitelist in ftb?

[WeHoDo]

Hero of Time schreef op dinsdag 28 augustus 2018 @ 11:30:
Dus omdat je obscurity wilt toevoegen en persé SSH op een andere poort wilt draaien, gooi je een pakket er maar uit dat wel iets aan echte security doet? Lijkt mij nou niet echt een verstandige keus.

nee, liever niet. Kan nu even niets anders, omdat ik de rest moet testen / inrichten.

Dit zal niet de uiteindelijke server worden. Maar om goed te beginnen met testen, wilde ik de veiligheid ook al goed hebben.

Uiteindelijk moet fail2ban wel gaan draaien, ook op een aangepaste poort, omdat deze standaard poort elders niet werkt ivm blokkade en vpn niet gemaakt kan worden.

PS. mijn linux kennis is niet 100%, maar overige configuraties zijn wel gelukt.

[ Voor 5% gewijzigd door WeHoDo op 28-08-2018 11:41 ]

[Hero of Time]

Je neemt een VPS af om mee te testen, dit wordt niet de uiteindelijke server voor je doel. Waarom neem je dan niet lokaal een VM met Virtualbox, stelt er een Host-Only adapter in als extra en test zo je hele configuratie? Kan je bij een foutieve configuratie iig nog via de console erbij.

[WeHoDo]

Hero of Time schreef op dinsdag 28 augustus 2018 @ 11:46:
Je neemt een VPS af om mee te testen, dit wordt niet de uiteindelijke server voor je doel. Waarom neem je dan niet lokaal een VM met Virtualbox, stelt er een Host-Only adapter in als extra en test zo je hele configuratie? Kan je bij een foutieve configuratie iig nog via de console erbij.

Omdat het uiteindelijk wel op deze vps moet draaien.
Zoals eerder, heb al een VM met daarop een centos waar de tools opstaan.
Hierop werkt alles, alleen in de vps, waarmee we nu testen niet.
Als ik moet uitgaan van VM dat alles goed is en vervolgens op de VPS alles omzet, dan kom ik er te laat achter. Nu kom ik erachter dat er al in het begin proces al iets niet werkt.

[WeHoDo]

Probleem is opgelost.
Vanuit de hoster wordt telkens bij een reboot de standaard firewall regels actief, waardoor je eigen config wordt overschreven. Evenals de DNS en wat andere instellingen. Nu deze zijn uitgeschakeld, ben ik weer up and running.