PDA

Bekijk Volledige Versie : IP adres bannen



Arto
24/06/06, 21:16
Iemand probeert via SSH inloggen
Ik heb zijn ip adres, hoe kan ik deze ip adres compleet bannen van het server?

lifeforms
24/06/06, 21:21
Wat voor besturingssysteem draait er op je server?

(En waarschijnlijk is het gewoon een virus dat zich via SSH verspreidt, je kan beter SSH gewoon alleen maar openzetten voor bekende IP-adressen)

smurf
24/06/06, 21:22
iptables -I INPUT -s ipadres -j DROP

Arto
24/06/06, 21:23
Het gaat om een Linux CentOs 4.2
Ondaks ik Brute Force Detection heb krijg bijna elke dag zo'n 10 emails dat het ip probeert te loggen op mijn server.


iptables -I INPUT -s ipadres -j DROP

http://www.bigbold.com/snippets/posts/show/1252

iptables -A INPUT -s ip.address -j DROP

Welke is het juiste of wat is het verschil?

Jurian
24/06/06, 21:27
Wen er maar vast aan, als je alle IP's die proberen in te loggen via SSH wil gaan blokkeren, dan kan je wel iemand daarvoor gaan aannemen want da's een dagtaak :-p

Een nuttigere oplossing is om het aantal ssh connectie pogingen per seconde te limiteren. Deze 'attacks' zijn bijna altijd scriptjes die gewoon een hele stapel login+password combinaties proberen, mijn ervaring is dat 't veel effectiever is om ze enorm te vertragen, dan om ze te proberen te blokkeren.

Dan kom je dus op zoiets, er vanuit gaande dat je netfilter/iptables gebruikt:

# SSH :: Maximum 3 per minute, except from our office
iptables -A INPUT -p TCP -s $NETBLOCK_OFFICE --dport 22 -j ACCEPT
iptables -A INPUT -p TCP --dport 22 -m limit --limit 3/min -j ACCEPT
iptables -A OUTPUT -p TCP --sport 22 -j ACCEPT

Let op dat je je kantoor (of een andere server met een vast IP) wel toestaat, zonder limiet, anders kan je ongewenste effecten krijgen :-p

Tevens gaan deze rules er vanuit dat je default policy voor zowel de INPUT als OUTPUT chains, DROP is, maar dat lijkt me logisch.

smurf
24/06/06, 21:28
-A, --append chain rule-specification
Append one or more rules to the end of the selected chain. When
the source and/or destination names resolve to more than one
address, a rule will be added for each possible address combina-
tion.

-I, --insert chain [rulenum] rule-specification
Insert one or more rules in the selected chain as the given rule
number. So, if the rule number is 1, the rule or rules are
inserted at the head of the chain. This is also the default if
no rule number is specified.

XBL
24/06/06, 21:48
Heb je naast BFD geen APF (makkelijk te installeren/configuren firewall) geïnstalleerd staan? BFD kan namelijk automatisch blokkeren, indien je APF geïnstalleerd hebt.

Beste oplossing is gewoon enkel je eigen IP's toe te laten; dan heb je geen last van bruteforce attacks.

Jochem

Arto
24/06/06, 21:51
Ok dat snap ik, ik heb een vaste ip maar het kans bestaat natuurlijk dat Wanadoo na een tijd mijn ip veranderd.
Dat was namelijk 1 keer gebeurd.
En als dat nu weer gaat kan ik niet inloggen :)

XBL
24/06/06, 21:55
Dan kan je gebruik maken van een techniek als port knocking, om te limiteren tot een beperkt aantal mensen die mogen inloggen. Maar inderdaad vervelend als je provider geen vast IP levert.

Jochem

localh
24/06/06, 22:43
ik heb alleszins goeie ervaringen met http://denyhosts.sourceforge.net/

SSH 1 verwijderen uit sshd.conf + RootPermitLogin no kan ook altijd interessant zijn
en uiteraard een deftig password gebruiken ;)

Arto
24/06/06, 23:04
Ik heb permit root login gewijzigd in /etc/ssh/sshd_config :

#PermitRootLogin no#

service sshd restart

Maar ik kan toch inloggen op SSH

swedendedicated
24/06/06, 23:05
waarom niet de ssh port veranderen... wel eerst firewall aanpassen :D dan kunnen ze er nooit in.

localh
24/06/06, 23:13
#PermitRootLogin no#

Je moet wel ff de hash (comment) weghalen.
Dit moet er dus staan:

PermitRootLogin no

Vergeet zeker niet een gewone user aan te maken! :)

royen99
24/06/06, 23:18
waarom niet de ssh port veranderen... wel eerst firewall aanpassen :D dan kunnen ze er nooit in.

Dat noemen ze security by obscurity en is dus geen security. (af te raden).

APF en BFD samen is beter aan te raden (en zowieso nooit root logins toestaan, eerst inloggen als een gewone gebruiker, en hierna ' # su - ' naar root.

systemdeveloper
24/06/06, 23:30
Misschien een tip: voor een klant heb ik eens iets gebouwd dat redelijk veilig is en wel nog een beetje 'security by obscurity' :)

Gebruik een trigger om een script op je server te starten (bv. stuur een email naar je server, log in op een bepaalde pagina van je site, etc...). Zorg dat een scriptje hier de sshd start op een random port en vervolgens het poortnummer, via sms (clickatell api of zo) naar je mobiel stuurt. Als je klaar bent met je ssh, log je uit met 'killall -9 sshd'.

In dat geval heb je sshd alleen maar draaien op het moment dat je het ook echt nodig hebt. Geen sshd is de beste beveiliging :)

localh
24/06/06, 23:43
Mooie oplossing maar het moet uiteindelijk allemaal werkbaar blijven hé ;)

Imho is sshd bij een (web)server zelden of nooit het zwakste punt.

SSH2 login via user met een deftig pass en dan su nr root (ook deftig pass :-) + eventueel iets als denyhosts of APF/BFD is meer als voldoende.

Arto
24/06/06, 23:50
Je moet wel ff de hash (comment) weghalen.
Dit moet er dus staan:

PermitRootLogin no

Vergeet zeker niet een gewone user aan te maken! :)


Dat was ook mijn bedoeling,
PermitRootLogin no

staat dus tuusen # en #


Nog even over APF firewall.
Ik heb wel BFD maar geen APF
Dit wil eigenlijk wel installeren, maar het standaard config kan ik daar last van krijgen?
Bijv mijn stream dat ie wordt geblokt?

systemdeveloper
24/06/06, 23:56
Mooie oplossing maar het moet uiteindelijk allemaal werkbaar blijven hé ;)

Imho is sshd bij een (web)server zelden of nooit het zwakste punt.

SSH2 login via user met een deftig pass en dan su nr root (ook deftig pass :-) + eventueel iets als denyhosts of APF/BFD is meer als voldoende.

Wil je veiligheid of gebruikersgemak? Ik heb nog wel gekkere dingen gebouwd :)

Persoonlijk heb ik niet vaak iets te zoeken op een shared webserver. Dat ding draait... of het draait niet. Ik hoef er niet 5 keer per dag op in te loggen (afkloppen...)

Maar je weet ook wel hoe het werkt met zwakke punten: Staat je poort publiekelijk open, dan wordt ie vroeg of laat gelogd door een scriptkiddie (of erger.. een echte hacker :P )
Komt er ooit een exploit voor je ssh-versie, kun je wel snel het haasje zijn. En als sshd niet actief is, kun je hekpogingen toch loggen.

Trust nobody :)

Sander-
25/06/06, 00:45
Dat noemen ze security by obscurity en is dus geen security. (af te raden).

APF en BFD samen is beter aan te raden (en zowieso nooit root logins toestaan, eerst inloggen als een gewone gebruiker, en hierna ' # su - ' naar root.

Nonsens, waarom af te raden?? Tuurlijk het is niet DE oplossing voor het probleem, maar verminderd het aantal attacks op de SSH poort wel drastisch, in ons geval bleven er van de 2500 attempts nog slechts 300 per dag over. Als je die oplossing gaat aanvullen met andere maatregelen zoals APF/BFD en Logwatcher, dan kun je dit probleem bijna geheel tackelen.

Daarnaast geldt hetzelfde als voor Apache etc, zoveel mogelijk proberen versies te maskeren, is ook security by obscurity, maar die "maatregel" zorgt er ook weer voor dat die 100'en scriptkids die een botje gedownload hebben afhaken. En ook de wat gevorderdere hacker moet wel hele speciale intresse in je machine hebben wil ie er echt veel voor gaan doen.

localh
25/06/06, 00:46
nuja, de beste beveiliging is nog altijd... je server offline halen :D

Sander-
25/06/06, 00:50
nuja, de beste beveiliging is nog altijd... je server offline halen :D

Als je een goede kluis hebt ;)

localh
25/06/06, 00:55
En ook de wat gevorderdere hacker moet wel hele speciale intresse in je machine hebben wil ie er echt veel voor gaan doen.

De nagel op de kop.
En dan bestaat er nog zoiets als social engineering ;)
Je zou er van verwondert staan op hoeveel plaatsen je gevoelige info kan loskrijgen mits de juiste connecties/woorden....
Nu gaan we off topic zeker ;)

Sander-
25/06/06, 01:14
De nagel op de kop.
En dan bestaat er nog zoiets als social engineering ;)
Je zou er van verwondert staan op hoeveel plaatsen je gevoelige info kan loskrijgen mits de juiste connecties/woorden....
Nu gaan we off topic zeker ;)

Waren we al even, maar ben het totaal met je eens... Gewoon lief zijn voor je medemens met bovengemiddelde computerkennis + je klanten is al vet goeie security :P

liber!
25/06/06, 01:33
Wat ook goed helpt tegen ongewenste ssh logins is het draaien van ssh op een niet standaard poort.

Neo123
25/06/06, 01:37
ik heb de poort veranderd en ik moet zeggen dat het ernstig rustig is op mijn webserver ;)

ErikKosters
25/06/06, 01:55
1. SSH op andere poort draaien.
2. Geen login van root direct aanvaarden.
3. APF goed aanscherpen.
4. BFD goed instellen.

5. Ben er al klaar mee :)

Showeb
25/06/06, 02:20
Wat ook een aanrader is is om een beheerserver te gebruiken en alleen de beheerserver toegang geven naar je andere servers.

of nog beter is om remote console + SSL te gebruiken en SSH helemaal uitschakelen.

Curry
27/06/06, 23:32
Dat noemen ze security by obscurity en is dus geen security. (af te raden).
Dat is natuurlijk een wat onzinnige instelling. Security by obscurity als enige security is per definitie af te raden inderdaad. Security by obscurity als extra maatregel bovenop bestaande degelijke security om bruteforce attacks te verminderen is absoluut een prachtige techniek.

Het idee is simpel: zolang automated scripts maar niet bij voorbaat weten waar ze moeten hameren gaan ze een stuk minder hameren. En merendeel van de inbraakpoging gebeurt echt automated hoor. Bovendien is er uit een port scan niet simpel af te leiden of op poort 5498 (insert random getal) een SSH-daemon zit te luisteren of een andere service die binaire troep verstuurt als je connect.

_arno_
28/06/06, 08:47
Wat ook praktisch is is om alleen maar je eigen ip te allowen op je sshd port.

Jurian
28/06/06, 09:30
Dan wel altijd zorgen dat je er minstens 2 IP's in hebt staan, anders heb je probleempje als je IP voor wat voor reden dan ook veranderd / als je ISP een storing heeft en je ergens anders wil inloggen om een probleem op te lossen oid :)

Curry
28/06/06, 09:54
Dan wel altijd zorgen dat je er minstens 2 IP's in hebt staan, anders heb je probleempje als je IP voor wat voor reden dan ook veranderd / als je ISP een storing heeft en je ergens anders wil inloggen om een probleem op te lossen oid :)
Tip: check je WLANs thuis en hobbel even langs www.whatismyip.com. Ik heb altijd 2 open WLANs beschikbaar met dank aan buurtleden die niet snappen dat draadloze technologie niet ophoudt bij je eigen buitenmuur, en da's toch altijd een handige uitwijk als je thuis zelf even niet zou kunnen ;)

_arno_
28/06/06, 10:12
Dan wel altijd zorgen dat je er minstens 2 IP's in hebt staan, anders heb je probleempje als je IP voor wat voor reden dan ook veranderd / als je ISP een storing heeft en je ergens anders wil inloggen om een probleem op te lossen oid :)
Uiteraard! heb zelf totaal 3 beschikbare ip's vanaf verschillende isps waarmee ik erop kan.
Vrienden zijn altijd handig ;)

FallingSky
28/06/06, 10:51
ik zou gewoon ssh toegang verbieden vanaf alle ip's behalve je zaak, thuis etc.

en natuurlijk een andere poort werkt ook goed.

Of een tweede optie:

script 3 keer fout inloggen automatische ddos naar het afkomstige ip.
(dat zal wel weer illigaal zijn maar ze leren het wel af)

Netbyte
28/06/06, 11:25
ik zou gewoon ssh toegang verbieden vanaf alle ip's behalve je zaak, thuis etc.

en natuurlijk een andere poort werkt ook goed.

Of een tweede optie:

script 3 keer fout inloggen automatische ddos naar het afkomstige ip.
(dat zal wel weer illigaal zijn maar ze leren het wel af)

Zoiets kan prima als je vaste ip's hebt, thuis en op het werk, wat meestal niet altijd het geval is. Huurlijn met een eigen ASN, ideaal!. Of een aparte ssh server, waarmee je dan weer verder kan ssh'en via een intranet, geen idee of het heeel handig is.

Ddos is overbodig, daar maak je meer stuk mee dan alleen de gebruiker!

Jurian
28/06/06, 17:16
Mensen die DDoSen (of het aanbevelen) mogen wat mij betreft opgesloten worden en de rest van hun leven verboden om een computer aan te raken.

Je DDoS gaat via de netwerken van onschuldige providers, die je daarmee vaak op hoge kosten jaagt, alleen maar om even stoer te doen. Mensen die het probleem niet willen begrijpen, die zelf DDoSen, of die het goedkeuren, hebben geen respect voor 't eigendom van anderen en snappen schijnbaar niet hoe gruwelijk veel schade ze onschuldige derden aandoen met hun asociale, idiote gedrag.

Je moet gewoon met je vieze tengels van andersmans spullen afblijven.

Arto
28/06/06, 18:38
Ik heb mijn root mysql pass vergeten.
Ik wil namelijk 1 ip weer verwijderen maar ik ben vergeten welke het ip het precies was.
Hoe kan ik mijn root wachtwoord voor mysql vernieuwen

crazycoder
28/06/06, 18:47
Ik heb mijn root mysql pass vergeten.
Ik wil namelijk 1 ip weer verwijderen maar ik ben vergeten welke het ip het precies was.
Hoe kan ik mijn root wachtwoord voor mysql vernieuwen
http://www.google.nl/search?client=firefox-a&rls=org.mozilla%3Anl-NL%3Aofficial_s&hl=nl&q=reset+password+root+mysql&meta=&btnG=Google+zoeken

digi
28/06/06, 20:01
Ik heb mijn root mysql pass vergeten.
Ik wil namelijk 1 ip weer verwijderen maar ik ben vergeten welke het ip het precies was.
Hoe kan ik mijn root wachtwoord voor mysql vernieuwen

staat in je DA config.

Maar hoe beheer jij je server eigenlijk, en wat draait daar op, hostingklanten??