Afdrukvoorbeeld
Als provider kan je de specifieke IP in een null-route gooien, dan komt het verkeer niet meer van / naar je server voor dat IP.
Het is wel zaak dat je even vraagt bij de provider waar het vandaan komt of hun die klant kunnen aanspreken. Hiervoor is het wel handig om fw logs etc mee te sturen.. of een netflow/sflow nfdump export. Een beetje ISP kan je die zo aanleveren op verzoek.
Hey allen,
Even een update.
De Coloprovider heeft het ip adres vanmorgen in een null-route gegooid.
Dus het is weer rustig op de server.
Hopelijk is het hierbij klaar, of die clown komt straks met een ander ip langs.
Maar dat zien we dan wel weer.
En oja die gast aanmelden bij z'n provider, het word mij niet duidelijk waar het ip van is.
Misschien iemand anders een idee?? IP> 109.230.245.206.
Met whowis kom ik alleen bij een wazige site uit.
https://apps.db.ripe.net/search/quer...#resultsAnchor
Het abuse adres is niet in gebruik.
Dat lijkt inderdaad normaal, maar als je kijkt op www.exetel.de (genoemd wordt abuse@exetel.de voor deze IP reeks) zie je een template website met lorem ipsum .Citaat:
Oorspronkelijk geplaatst door Lo-nrd
Maar de betreffende route heeft AS197043 als origin (32 bits AS nummer nu in productie...) . De route is wel actief en heeft inderdaad dat AS als origin.
Het abuse contact voor AS197043 is
remarks: -- please report spam/abuse to abuse@optimate-server.de -
remarks: ----- reports to other addresses won't be processed -----
Deze site lijkt wel gebruikt te worden. Ik zou dus abuse@optimate-server.de contacteren.
Bedenk wel dat een DoS ook gespoofed kan zijn, waarbij dit netwerk dan niet werkelijk de bron is. Aan de andere kant, zo'n verlaten ogende website (exetel.de) kan natuurlijk gehacked zijn en gewoon de werkelijke bron.
Oke bedankt,
Ik zal de mail naar dat e-mail adres toesturen.
De bedrijfsnaam lijkt wel op het Nederlandse Ecatel (grote Spamhoster).Citaat:
Oorspronkelijk geplaatst door visser
Hier zeker ook geen fan van Ecat#l/link#p, maar dat is wel erg kort door de bocht om dat direct aan te nemen.Citaat:
Oorspronkelijk geplaatst door dennis0162
Daar was ik weer even.
Ik heb toch even getest met de ip ban, en nu kom ik er achter dat het niet lijkt te werken.
Ik heb me zelf ook even in de iptables gezet, maar wat blijkt ik kom overal gewoon bij.
Deze config staat nu erbij in Iptables:
-A INPUT -s 109.230.245.206 -j DROP
-A INPUT -s 77.BEN.IK.147 -j DROP
Ik restart in webmin (NOOB) op het moment want ik word er niet wijs uit hoe nu de iptables in console te restarten.(Apply Configuration)
Ik heb 2 servers draaien, 1 met debian lenny en 1 met debian squeeze.
Op beide servers lukt het me niet
Het rare is al ik bijvoorbeeld poort 21 uit de iptables haal en restart (Apply Configuration) in webmin kom ik dus niet meer in mijn ftp server. Zoals het hoort.
Maar met een ip droppen werkt dat dus niet, kom gewoon overal bij ssh ftp web enz.
Het moet wel zo werken, maar misschien dat vooraan in de iptables config een expliciete permit staat, om te voorkomen dat mensen zichzelf ophangen wanneer ze alle admin (of alle) toegang afsluiten.Citaat:
Oorspronkelijk geplaatst door Lo-nrd
Op de commandline, als root :
iptables -nvL
laat alle huidige iptables regels zien.
Kijk daar goed door alle regels om te zien of de drop regel die je hebt opgegeven er goed in staat, en of niet verkeer wat je wilt laten droppen door een eerdere regel ge-permit wordt.
Voor de plek waar iptables gestart/herstart kan worden,
cd /etc/rc3.d
ls (of grep iptables *) en kijk door welk startup script iptables gezet wordt.
(eventueel ook in /etc/rc5.d kijken, als runlevel 5 de default mocht zijn).
Het zou nog kunnen dat iptables via-via gestart wordt, maar kijken in de rcx.d directory is wel de handigste manier om te starten.
Zo zie ik mij ip staan in via command iptables -nvL
0 0 DROP all -- * * 77.251.4.147 0.0.0.0/0
In geen enkele rcx.d zie ik iets staan van iptables/firewall
Er zijn ook geen hits op die regel ( de 0 0 zijn packets en bytes die gematched hebben)Citaat:
Oorspronkelijk geplaatst door Lo-nrd
Maar je laat alleen die regel zien, en mijn vraag/idee is dus dat voor (boven) die regel het verkeer al geaccepteerd is, of naar een andere chain gestuurd is.
Ik zeg toch ook nergens dat het Ecatel is.Citaat:
Oorspronkelijk geplaatst door dreamhost_nl
Ik zal zo even alles pasten!Citaat:
Oorspronkelijk geplaatst door visser
Bijdeze.Citaat:
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*nat
:PREROUTING ACCEPT [14:1710]
:POSTROUTING ACCEPT [1:286]
:OUTPUT ACCEPT [1:286]
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*mangle
:PREROUTING ACCEPT [34:2495]
:INPUT ACCEPT [34:2495]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [33:4887]
:POSTROUTING ACCEPT [33:4887]
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
# Generated by iptables-save v1.4.2 on Fri Feb 19 15:46:21 2010
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Accept traffic from internal interfaces
-A INPUT ! -i eth0 -j ACCEPT
# Accept traffic with the ACK flag set
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
# Allow incoming data that is part of a connection we established
-A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow data that is related to existing connections
-A INPUT -m state --state RELATED -j ACCEPT
# Accept responses to DNS queries
-A INPUT -p udp -m udp --dport 1024:65535 --sport 53 -j ACCEPT
# Accept responses to our pings
-A INPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT
# Accept notifications of unreachable hosts
-A INPUT -p icmp -m icmp --icmp-type destination-unreachable -j ACCEPT
# Accept notifications to reduce sending speed
-A INPUT -p icmp -m icmp --icmp-type source-quench -j ACCEPT
# Accept notifications of lost packets
-A INPUT -p icmp -m icmp --icmp-type time-exceeded -j ACCEPT
# Accept notifications of protocol problems
-A INPUT -p icmp -m icmp --icmp-type parameter-problem -j ACCEPT
# webmin
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 15050,22
# Allow connections to our IDENT server
-A INPUT -p tcp -m tcp --dport auth -j ACCEPT
# Respond to pings
-A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
# webmin en FTP en web
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 10000,21,80
# FTP
-A INPUT -p tcp -m tcp --dport 49152:49162 -j ACCEPT
# TEAMSPEAK
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 9987,9988,10011,30033
# ban test
-A INPUT -s 77.mijn.ip.147 -j DROP
COMMIT
# Completed on Fri Feb 19 15:46:21 2010
Citaat:
Oorspronkelijk geplaatst door Lo-nrd
Daar zie je min of meer precies staan wat ik zei :Citaat:
Oorspronkelijk geplaatst door Lo-nrd
Eerst wordt alle SSH (en tcp/15050, webmin) verkeer geaccepteerd, en pas daarna wordt verkeer van jouw IP gedropt.
iptables werkt de regels in volgorde af, en de eerste match telt.
Dus met deze rulebase is het logisch dat je ssh verkeer niet gedropt wordt.
(noch ander verkeer wat geaccepteerd werd boven de drop regel).
Om je ban effectiever te maken moet je 'm als _eerste_ regel opnemen, zolang je zeker bent dat je er nog op een andere manier goed bij kunt.
met iptables -nvL moet je ook de counters voor de andere regels, die wel matchen, met oplopende waarden zien (paar keer iptables -nvL achter elkaar).
Jeetje dat wist ik niet..
Dat werkt dus.
Ik heb ff iemand anders gebant ( vriend) en die komt nergens meer bij.
Ik heb de ban nu onder de eerste regel staan, is dit ook goed?
Citaat:
# Accept traffic from internal interfaces
-A INPUT ! -i eth0 -j ACCEPT
# BAN
-A INPUT -s 109.230.245.206 -j DROP
# Accept traffic with the ACK flag set
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
# Allow incoming data that is part of a connection we established
-A INPUT -m state --state ESTABLISHED -j ACCEPT
# Allow data that is related to existing connections
-A INPUT -m state --state RELATED -j ACCEPT
# Accept responses to DNS queries