Redigering af min /etc/hosts.deny

1. Filen hedder /etc/hosts.deny, ikke host.deny

2. Ikke alle tjenester bruger tcp-wrappers. sshd f.eks. ikke som standard. Apache heller ikke.

3. Du kan bruge iptables for at blokere alle pakker fra 117.25.128 / 24, fx:

     iptables -I INPUT -s 117.25.128.0/24 -j DROP  

4. Endnu bedre kan du bruge fail2ban til at overvåge en logfil (såsom apaches access.log og / eller error.log) og bloker automatisk IP-adresser, der forsøger at angribe din server.

Fra debian fail2ban pakkebeskrivelse:

Fail2ban overvåger logfiler (f.eks. /var/log/auth.log, /var/log/apache/access.log) og forbyder midlertidigt eller vedvarende adresser, der er udsat for fejl, ved at opdatere eksisterende firewallregler.

Fail2ban tillader nem specifikation af forskellige handlinger, som for eksempel at forbyde en IP ved hjælp af iptables eller værter. Nægtelsesregler eller blot sende en underretnings-e-mail.

Som standard leveres den med filterudtryk for forskellige tjenester (sshd, apache, qmail, proftpd, sasl osv.), men konfigurationen kan let udvides til overvågning af enhver anden tekstfil. Alle filtre og handlinger er angivet i konfigurationsfilerne, så fail2ban kan vedtages til brug sammen med en række filer og firewalls.

Kommentarer

• Ok ja jeg ' Jeg redigerer flisen. Ah okay, ja, jeg prøvede iptables -A INPUT -s 117.25.128.0/24 -j DROP men det blokerede ' det heller ikke.
• -I INPUT indsætter den nye regel øverst i INPUT-kæden. -A INPUT tilføjer det til bunden af kæden. hvis -A INPUT ikke fungerede ', skal der have været en anden regel tidligere i kæden, der tillod disse pakker.
• ahhh okay, jeg ' m forudsat at forrang er top til bund så?
• yep. første matchende regel vinder.
• Perfekt, det ser ud til at fungere! Tak skal du have. Hurtigt spørgsmål dog så mange af anmodningerne kommer fra den samme henvisning dvs. (item.taobao.com) med forskellige klient-IP ' s, så jeg ' antager, at de ' bruger en eller anden form for omdirigering. Er der en måde at blokere ved henvisning eller blokere med 117. * Brug som et jokertegn?

Hvad angår dit originale spørgsmål. Min Apache i debian er ikke konfigureret med libwrap, så den hører ikke hosts.deny. [Det forrige svar nævner det allerede – virkeligheden er, at tcpwrappers ikke er indbegrebet af sikkerhed, som det var i 90erne, specielt når det kommer til sortliste]. Du bliver nødt til at køre den ikke som en dæmon, men fra (x) inetd, hvilket vil bremse den (betydeligt).

Du kan blokere / tillade adgang på Apache-niveau og gøre behøver ikke tcp-indpakninger til Apache [eller iptables for den sags skyld]. Du har ikke nævnt ssh, men jeg lader aldrig ssh-servere være åbne direkte udad. Dog fortsæt med at læse videre.

Vi har en vhost med 300 + domæner og også lignende problemer med taobao, baidu og ofte endda med google edderkopper. Især baidu edderkopper kan være ret aggressive og vedholdende.

Som du allerede har fundet ud af, har de servere, og selvom du blokerer en IP, vises de igen snart fra nogle andre IP-adresser.

Det er overhovedet ikke praktisk at forsøge at vedligeholde lis ts af IP-adresser / netblokke i hånden.

Hvad det fungerer for os ret godt, er modsecurity, der blokerer brugeragentstrenge permanent, mens mod_evasive blokerer midlertidigt IPer, der misbruger.

Denne opsætning udover at bremse edderkopper fra søgemaskiner har den også fordelen ved at nedbringe zombier, der prøver at gætte adgangskoder på CMSer.

Den relevante del af vores modsecurity.conf

SecRule REQUEST_HEADERS:User-Agent "Yandex" phase:1,deny,nolog,id:"6972" SecRule REQUEST_HEADERS:User-Agent "ichiro" phase:1,deny,nolog,id:"6973" SecRule REQUEST_HEADERS:User-Agent "Baiduspider" phase:1,deny,nolog,id:"6974" SecRule REQUEST_HEADERS:User-Agent "Baiduspider/.*" phase:1,deny,nolog,id:"6975" SecRule REQUEST_HEADERS:User-Agent "Baiduspider-video" phase:1,deny,nolog,id:"6976" SecRule REQUEST_HEADERS:User-Agent "Baiduspider-image" phase:1,deny,nolog,id:"6977" SecRule REQUEST_HEADERS:User-Agent "sogou spider" phase:1,deny,nolog,id:"6978" SecRule REQUEST_HEADERS:User-Agent "YoudaoBot" phase:1,deny,nolog,id:"6979" SecRule REQUEST_HEADERS:User-Agent "bingbot(at)microsoft.com" phase:1,deny,nolog,id:"6980" SecRule REQUEST_HEADERS:User-Agent "msnbot(at)microsoft.com" phase:1,deny,nolog,id:"6981" SecRule REQUEST_HEADERS:User-Agent "BLEXBot/1.0" phase:1,deny,nolog,id:"6982" SecRule REQUEST_HEADERS:User-Agent "Bot.*" phase:1,deny,nolog,id:"6984" SecRule REQUEST_HEADERS:User-Agent "AhrefsBot.*" phase:1,deny,nolog,id:"6985" 

Og vores mod-evasive.conf

DOSHashTableSize 2048 DOSPageCount 10 DOSSiteCount 300 DOSPageInterval 2.0 DOSSiteInterval 1.0 DOSBlockingPeriod 600.0 DOSLogDir /var/log/apache2/evasive DOSWhitelist 127.0.0.1 DOSWhitelist 1xx.xxx.xxx.xx 

Jeg glemte også en meget reel mulighed. Hvis du ikke beskæftiger dig med Kina eller kører din hjemmeserver, skal du bare blokere hele landet. Niveauet for angreb og malware, der kommer fra dem, har berettiget mange fagfolk til at gøre det.

http://www.cyberciti.biz/faq/block-entier-country-using-iptables/

Jeg glemte også at tilføje en fodnote til dette ret lange svar.Ofte foreslår folk mig på arbejde at bruge robots.txt til denne slags problemer. Pointen er, at robots.txt kun er et forslag til fjernprogrammer. Rogue-aktører ignorerer dem bestemt, og det er ikke garanteret, at andre webcrawlere ærer dem i dag. Fra vores tests synes Baidu for eksempel ikke at ære dem. (robots.txt svarer det til at spørge en gangster, kild mig venligst i stedet for at slå mig)

Kommentarer

• Tak mand! ja jeg ' m def vil bruge mod_evasive, de konfigurerende filindstillinger fungerer godt for dig?
• De fungerer ganske godt, de fleste af vores vhosts har ikke meget besøgende. Ellers er du nødt til at øge dospagecount (maks. Besøg på en enkelt side fra en IP) og dossitecount (max besøg på og IP) i overensstemmelse hermed.
• Se til mine første linjer igen tak.
• Fik det giver mening, jeg ' Jeg læser om indstillingerne. Tak igen for al din hjælp!
• (tag det ikke forkert, bare foreslå at blokere adresser på webserver eller Apache kunne være en bedre titel) … alligevel var det ikke for denne kommentar, jeg kom her igen, læs svaret igen tak. Udover kommentarer i begyndelsen finder du noget mere interessant i sidste ende.