CentOS iptables toch verkeer

[Martine]

Goedenavond Tweakers,

Gisteravond even bezig om een hobby vps in te richten, op de vps draait CentOS 6.3 met DirectAdmin. Omdat ik binnen de kortste keren mailtjes van DirectAdmin van de Brute Force Monitor kreeg wou ik dit graag simpel met iptables oplossen. Het veemde is; het werkt niet.

Regeltje uit de Brute Force Monitor van DirectAdmin, hier zijn er inmiddels honderden van.
Dec 31 20:26:16 klanten sshd[10809]: Failed password for invalid user teamspeak from *ip* port 39181 ssh2

Nadat ik mij in iptables had ingelezen ben ik gisteravond aan de slag gegaan. In de veronderstelling dat ik vanmorgen geen mailtjes meer zou krijgen, want de poorten die open staat zijn 22 (ssh), 80 (http) en 2222 (directadmin login)

Er komen in de eerste instantie alleen wat html websites op te staan, niet veel soeps. En wat backup data van mijn computer. Dus alles mag dicht, behalve de eerste vermelde poorten.

code:

iptables -vnL --line-numbers
Chain INPUT (policy DROP 131 packets, 7796 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      879 90086 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
3        1   104 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
5        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
6       64  3832 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
7        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2222 
8        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1018 packets, 167K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Zoals ik het nu bekijk wordt alles gedropt, behalve poort 22,80 en 2222. Tevens is lokaal verkeer op local interface toegestaan.

Maar waarom? Waarom krijg ik nog steeds poging tot inloggen? En hoe is dat mogelijk op poort 39181, want deze is toch gesloten?

Wie kan mij een beetje in de goede richting leiden.

Alvast bedankt!

[Keiichi]

port 39181 is de poort van de andere kant.

Probeer je eens te verdiepen hoe tcp/ip werkt en dan pas een firewall ontwerpen.

[Verwijderd]

Het lijkt me duidelijk dat je poort 22 en 2222 beter wilt afschermen. Je bent zelf de enige gebruiker, gooi ze dus achter een IP restrictie. Let wel op want als je dan een fout maakt heb je jezelf ook buitengesloten.

[Martine]

Juistem, ik ga nog even verder spitten. Als dat verkeer dan ook daadwerkelijk binnen komt.

Mezelf buiten sluiten heb ik al gedaan, gelukkig kan ik bij de hoster de console opstarten waarme ik de wijzigingen weer ongedaan kan maken. In ieder geval bedankt voor de tip!

[Megamind]

Als je directadmin gebruikt installeer dan configfirewall en bespaar jezelf een hoop ellende.

[Martine]

Mijn gedachtegang om het zelf te doen, is dat ik uiteindelijk weet hoe het werkt. Het gaat slechts om een paar poorten die open mogen zijn.

[Hero of Time]

Als je bruteforce aanvallen krijgt op je SSH, moet je gewoon SSH op een andere poort draaien, en met IP restricties werken. Er zijn veel scanners/botjes/scriptkiddies die standaard poorten en fouten proberen om toegang te krijgen tot een server en zo deze in te zetten voor wat dan ook. Door een afwijkende configuratie te draaien, ben je de simpele zielen voor. Dan blijft alleen nog maar de wat uitgebreidere beveiliging over.

Wil je meer leren over iptables e.d., dan kan je dat ook met een (of desnoods twee voor onderling) VM op je eigen systeem doen. Ik ben eens met directadmin aan de slag geweest om firewall regels toe te passen, maar werd telkens uitgesloten van de server (met een belletje naar de hoster voor een reboot). Eigen VM gemaakt, daar mee gespeeld en werkend gemaakt. Omdat je alles 'lokaal' hebt, kan je jezelf niet uitsluiten. Met je VPS heb je dan nog wel shell toegang via een andere weg, maar het is toch net iets langzamer allemaal. En je moet wel altijd toegang hebben tot je VPS, itt lokaal wat je ook onderweg zonder internet kan doen.

[Rainmaker]

With ^^

Draai SSH op een non-standard port. Normaal is security through obscurity geen goed idee, maar het helpt tegen scriptkiddies.

Gewoon password auth uitzetten op SSH, enkel en alleen key authentication gebruiken.

Overigens; als alle brute-force attacks vanuit dezelfde ip adres(sen) komen, kun je ook gewoon verkeer blokkeren met als source die IP adressen.

Ook mailen naar abuse@provider van de andere werkt meestal wel.

[Keiichi]

Je kan ook fail2ban als extra 'beveiliging' inzetten.

[Verwijderd]

SSH op een andere poort draaien is gewoon bullshit. Je draait ook geen webserver op een andere poort om aanvallen te voorkomen.

Als je last hebt van load, veroorzaakt door een brute force attack, dan moet je bijvoorbeeld connection rate limiting gebruiken als de service publiek beschikbaar moet zijn. Als je service alleen door jezelf wordt gebruikt, dan beperk je bijvoorbeeld toegang op basis van IP adres. Dat helpt wél tegen bijvoorbeeld ex-werknemers. Of beter nog: je maakt de service alleen bereikbaar via een VPN verbinding.

Als iemand wil bruteforcen dan lopen je logs toch wel vol, of het nou is van gedropte connections of van mislukte inlogpogingen. Daar heb je grep -v voor.

Password authenticatie uitzetten is een mogelijkheid. Eigenlijk moet je dan zeggen dat je elke vorm van authenticatie die je niet gebruikt onmogelijk maakt. Zo heb ik op bijna al mijn systemen password authenticatie en public key authenticatie uit staan, aangezien ik Kerberos gebruik. Daarnaast heb ik services draaien die alleen via interne IP adressen bereikbaar zijn. En tussen mijn router thuis en mijn colocated server is er een IPsec verbinding die die interne IP adressen routeert.

[FitzJac]

En deze niet te vergeten tegen brute forcing:
SSHGuard

[Martine]

Als er in principe alleen maar een paar hobby websites op komen te staan, en eventueel een domeinnaam met een pop emailbox, dan is het onderstaande toch voldoende om ongewenste gasten buiten de deur te houden?
Er wordt gewerkt met wachtwoorden van 25 karakters lang en niet voor de hand liggende gebruikersnamen, dan valt een inbraak toch allemaal wel een beetje mee?

Momenteel zien de iptables er als volgt uit;

code:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       15  1397 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
2        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
3        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 
4        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
5        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
6        1    52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
7        0     0 ACCEPT     tcp  --  *      *       *mijnip*       0.0.0.0/0           tcp dpt:21 state NEW 
8        0     0 ACCEPT     tcp  --  *      *       *mijnip*       0.0.0.0/0           tcp spt:20 state RELATED,ESTABLISH
ED 
9        0     0 ACCEPT     tcp  --  *      *       *mijnip*       0.0.0.0/0           tcp dpt:22 
10       0     0 ACCEPT     tcp  --  *      *       *mijnip*       0.0.0.0/0           tcp dpt:2222 
11       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
12       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 14 packets, 3346 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Is het voldoende zo?

Ps; Ook ga ik nog even naar de link van FitzJac kijken.

[Verwijderd]

Regels 7 en 8 kun je het best verwijderen. Je bent zelf de enige gebruiker en bent dus vrij om protocollen en software te kiezen. Gebruik dan SFTP of SCP en niet FTP, poort 22 staat toch al open voor jouw IP.
Hetzelfde geldt voor regel 11. Gebruik POP3S of IMAPS, dus niet poort 110 maar 993 of 995.

Als je dan toch bezig bent met beveiliging, leer dan af om niet-versleutelde verbindingen te gebruiken.

[hommer]

Misschien een domme vraag maar waar zijn de regels 5/6 en 9/10 goed voor?

Google geeft me heel veel voorbeelden met die regels er in maar nergens een goede uitleg. Ik mag hopen dat het niet van van die regels zijn die door iedereen gecopieerd worden maar door niemand begrepen?

Ik heb hezelfde overigens ook opgelost door SSH op een niet standaard poort te draaien en daarop dan nog fail2ban te draaien. Heerlijk rustig.

[Hero of Time]

hommer schreef op donderdag 02 januari 2014 @ 07:47:
Misschien een domme vraag maar waar zijn de regels 5/6 en 9/10 goed voor?

Google geeft me heel veel voorbeelden met die regels er in maar nergens een goede uitleg. Ik mag hopen dat het niet van van die regels zijn die door iedereen gecopieerd worden maar door niemand begrepen?

Ik heb hezelfde overigens ook opgelost door SSH op een niet standaard poort te draaien en daarop dan nog fail2ban te draaien. Heerlijk rustig.

Regel 5 is voor loopback verkeer. Als je alles van je loopback interface blockt, kan je nare gevolgen krijgen. Een hoop services zullen dan niet fatsoenlijk werken.
Regel 6 is HTTP, alles mag naar poort 80 verbinding maken.

Regel 9 is SSH, nummer 10 is voor z'n DirectAdmin. Staat in de TS

[init6]

Rainmaker schreef op woensdag 01 januari 2014 @ 23:13:
With ^^

Draai SSH op een non-standard port. Normaal is security through obscurity geen goed idee, maar het helpt tegen scriptkiddies.

Gewoon password auth uitzetten op SSH, enkel en alleen key authentication gebruiken.

Overigens; als alle brute-force attacks vanuit dezelfde ip adres(sen) komen, kun je ook gewoon verkeer blokkeren met als source die IP adressen.

Ook mailen naar abuse@provider van de andere werkt meestal wel.

Public private keypair instellen, password logins disablen en deny root acces op SSH logins is meer dan genoeg idd. Een port veranderen lost niets op. Ik heb een fail2ban monitor draaien op port 22 en na 10-100 attempts geven ze het dan wel op.

[hommer]

Hero of Time schreef op donderdag 02 januari 2014 @ 12:48:
[...]

Regel 5 is voor loopback verkeer. Als je alles van je loopback interface blockt, kan je nare gevolgen krijgen. Een hoop services zullen dan niet fatsoenlijk werken.
Regel 6 is HTTP, alles mag naar poort 80 verbinding maken.

Regel 9 is SSH, nummer 10 is voor z'n DirectAdmin. Staat in de TS

Sorry, mijn regelnummering is blijkbaar anders.
Ik bedoelde de regels met de TCP flags. Ik heb de man van iptables nog door zitten lezen maar ik krijg de indruk dat het een combinatie is van de SYN, ACK, FIN, etc bits maar de combinatie 0x00 en 0x3F lijkt me niet logisch en/of voorkomend normaal verkeer.
Waar zijn die regels voor?

[Verwijderd]

Het zijn ongeldige combinaties van TCP flags. Daarom wordt dat verkeer ook stilletjes gedropt (zie "target" kolom).

[hommer]

Dat had ik ook gelezen, dank je. Maar ik wil graag het nut van de regel begrijpen.

Waarom zouden die gedropt moeten worden in de firewall? Immers de combinatie is ongeldig, dan doet de kernel er toch ook niets mee? Als we moeten filteren op alle mogelijke ongeldige combinaties om de kernel te beschermen dan moet de lijst veel langer zijn.

Ik zie het nut van die regels nog niet, is er een goede reden voor?

[Verwijderd]

Vroeg in de firewall droppen zodat er bij bijvoorbeeld een DDoS aanval zo weinig mogelijk CPU cycles aan verloren gaan.

[vanaalten]

Als het een ongeldige combinatie is, hoe weet je dan wat het OS ermee gaat doen? Crashen, potentieele lekken voor virussen en zo? Dan liever inderdaad maar droppen.

[hommer]

vanaalten schreef op donderdag 02 januari 2014 @ 23:05:
Als het een ongeldige combinatie is, hoe weet je dan wat het OS ermee gaat doen? Crashen, potentieele lekken voor virussen en zo? Dan liever inderdaad maar droppen.

Het argument dat ongeldige info gedropt moet worden vind ik persoonlijk een vreemde. Het zou een heel slecht OS zijn als het daar niet mee om kan gaan, en CentOS is dat zeker niet. Dat je met dit soort regels intelligenter denkt te zijn dan kernel ontwikkelaars vind ik wel vrij arrogant. Bij alles wat op een OS afkomt zijn er meer foute dan goede combinaties dus dat vind ik een vreemd argument.

Sorry voor de flame, bedankt voor het verhelderen. Mijn gevoel dat het nutteloze regel is is bevestigd. Het lijkt me meer een regel om interessant te doen; door iedereen gecopieerd en door niemand begrepen.

[vanaalten]

Nou ben ik absoluut geen expert op dit gebied, maar: als je uitgaat van foutloze software, dan heb je toch al geen firewall meer nodig?

Ik heb op mijn server geen directadmin draaien, poort 2222 wordt niet gebruikt, geen daemon of wat dan ook die daar naar luistert. In principe zou ik die poort gewoon open kunnen zetten.
Even goed heb ik hier wel een POP3S daemon draaien, uiteraard beveiligd met een wachtwoord en encryptie en zo. Maar goed, die gebruik ik tegenwoordig niet meer, doe alles via IMAP. Uitgaande van foutloze software en een sterk wachtwoord zou ik die poort ook open kunnen zetten, toch?

En toch doe ik dat niet, simpelweg omdat ik er niet op vertrouw dat het OS en al die services foutvrij zijn. Duizenden regels code, daar MOETEN bugs in zitten. De regelmatige security updates bevestigen dat.

Daarom kies ik liever voor dubbele of driedubbele bescherming: als de firewall doorbroken is, dan mogen ze de volgende beschermingslaag (OS, services) proberen te doorbreken. Maar ik vertrouw niet op 1 laag.