kan ikke blokere 2 ip adresser i .htaccess

Hvad skriver du i din htaccess? Hvordan ved du at de ikke bliver blokeret?

Order Deny,Allow
Deny from 178.119.148.239
Deny from 81.165.131.53

Hej

Jeg har en lang liste med standard blokering som du viser.

Aktiviteten fremgår af min logfil: http://finnholbek.dk/showlog.php?autorefresh=0

Uden at kende din fulde htaccess kan det være svært at sige om der kan være en anden fejl.

Har du overvejet af flytte blokeringen ind i php som et forsøg ? (Er din løsning homemade?)

filen indeholder nogle 301 omdirigeringer og en længere stribe blokerede adresser efter denne model, som har fungeret uden problemer i mange år:

# allow all except those indicated here
<Files *>
order allow,deny
allow from all
deny from 178.119.148.239
</Files>

Pröv at sätte allow from all under ip-adresserne du blokerer.
Har du <files *> ... med?

beklager jeg fik hentet linjer fra forkert fil, her er min række med blokeringer:

## USER IP BANNING
<Limit GET>
order allow,deny
deny from 5.9
deny from 23.31.32.173
deny from 31.170.110.227
deny from 40.77.167.33
deny from 46.161
deny from 51.254.32.77
deny from 51.255.65
deny from 61.43.173
deny from 60.13.132.38 
deny from 61.50.213.229
deny from 63.141.226.178
deny from 63.249.66.204
deny from 69.30.198.178
deny from 69.30.198.202
deny from 69.30.214.46
deny from 69.197.177.26
deny from 71.13.87.122
deny from 78.46.156.169
deny from 80.91.162.98
deny from 81.165.131.53
deny from 81.165.131
deny from 80.223.101.142 
deny from 81.171.107.68
deny from 83.84.71.116
deny from 85.105.130
deny from 85.166.192.173
deny from 92.113.68.92
deny from 94.228.34.250
deny from 104.171.124.88
deny from 104.171.124
deny from 107.150.59.98
deny from 104.236.90.4
deny from 104.131.220
deny from 110.53.183.62
deny from 121.40.174.149
deny from 128.220.117.40
deny from 130.225.26.136   
deny from 136.243
deny from 139.196
deny from 142.54.184.90
deny from 144.76
deny from 146.185
deny from 148.251
deny from 151.80.31.109
deny from 155.133.82.87
deny from 162.243.38.29
deny from 162.243.197.76
deny from 173.208.223.27
deny from 173.209.43.16
deny from 173.234.153.122
deny from 176.9.58.227
deny from 176.31.126.56
deny from 178.119.148.239
deny from 178.119.148
deny from 180.175.78.41
deny from 185.56.80.138
deny from 185.130.6.103
deny from 188.165.196.25
deny from 188.40.112.210
deny from 188.143.232
deny from 192.243.55
deny from 198.245.49.215
deny from 199.58.86.209
deny from 202.46.51.85
deny from 203.133.170
deny from 204.79.180.112
deny from 216.244.66
deny from 218.161.43.218
   
allow from all
</Limit>

det virker på alle andre end 178.119.148.239, inklusive min egen ip.

har aldrig oplevet noget lignende.

Har du prøvet at lade være med at smide det i Limit GET således at det er en fuld blokering uanset hvordan de kommer ?

Hej Leif

Glimrende forslag. Som om der var en effekt i 5-10 minutter, men så vendte den tilbage som om intet var hændt.

Kan den køre på en eller anden form for "fup-proxy" eller lignende?

Mvh. Finn

Har du kigget i serveren/websider access log ?

er det her du mener: http://finnholbek.dk/showlog.php?autorefresh=1

#11 det kan jeg ikke vide da det er en php side som læser nogle data. Fx på mit webhotel ville du ligge i en mappe som hedder logs som kan ses via ftp og hedde access.log

det ser ud til at der er andre der har problemer med disse to adresser, når man tjekker hva. værktøjet her: https://www.ultratools.com/tools/ipWhoisLookupResult

178-119-148-239.access.telenet.be.
d51a58335.access.telenet.be.

begge adresser udløser denne rapport:

Source:  whois.ripe.net
IP Address:  178.119.148.239

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%      To receive output for a database update, use the "-B" flag.

% Information related to '178.119.0.0 - 178.119.255.255'

% Abuse contact for '178.119.0.0 - 178.119.255.255' is 'abuse@pandora.be'

inetnum:        178.119.0.0 - 178.119.255.255
netname:        TELENET
descr:          Telenet N.V. Residentials
remarks:        INFRA-AW
country:        BE
admin-c:        PS396-RIPE
tech-c:        PS396-RIPE
status:        ASSIGNED PA
mnt-by:        TELENET-DBM
created:        2011-03-29T13:44:15Z
last-modified:  2011-06-08T07:03:12Z
source:        RIPE

role:          Technical Internet
address:        Telenet Operaties N.V.
address:        Liersesteenweg 4
address:        B-2800 Mechelen
address:        Belgium
remarks:        trouble:      IMPORTANT: To report intrusion attempts, hacking,
remarks:        trouble:      IMPORTANT: spamming, or other unaccepted behavior
remarks:        trouble:      IMPORTANT: by a Telenet/Pandora customer, please
remarks:        trouble:      IMPORTANT: send a message to abuse@pandora.be
remarks:        trouble:      IMPORTANT: Voor het rapporteren van inbraakpogingen,
remarks:        trouble:      IMPORTANT: hacking, spamming, of ander onaanvaardbaar
remarks:        trouble:      IMPORTANT: gedrag van een Telenet/Pandora klant, gelieve
remarks:        trouble:      IMPORTANT: een bericht te zenden naar abuse@pandora.be
admin-c:        TNRA1-RIPE
tech-c:        TNRA1-RIPE
nic-hdl:        PS396-RIPE
mnt-by:        TELENET-DBM
created:        1970-01-01T00:00:00Z
last-modified:  2014-05-26T12:29:39Z
source:        RIPE # Filtered
abuse-mailbox:  abuse@pandora.be

% Information related to '178.118.0.0/15AS6848'

route:          178.118.0.0/15
descr:          Telenet N.V. Customers
origin:        AS6848
mnt-by:        TELENET-OPS-MNT
created:        2011-07-04T13:51:06Z
last-modified:  2011-07-04T13:51:06Z
source:        RIPE

% This query was served by the RIPE Database Query Service version 1.88 (WAGYU)

Der står ikke noget i den som viser at andre har problemer, du kan slå alle ip adresser op og få en ripe rapport

De her linjer kommer ikke frem ved test af andre harmløse adresser:

remarks:        trouble:      IMPORTANT: To report intrusion attempts, hacking,
remarks:        trouble:      IMPORTANT: spamming, or other unaccepted behavior
remarks:        trouble:      IMPORTANT: by a Telenet/Pandora customer, please
remarks:        trouble:      IMPORTANT: send a message to abuse@pandora.be

En del har abuse info:
role:            WEBPARTNER Technical Contact
address:        Telia Danmark A/S
address:        Holmbladsgade 139
address:        DK-2300 København S
phone:          +45 70 26 23 00
fax-no:          +45 70 26 23 01
e-mail:          cis-noc@dk.telia.net
admin-c:        SNOC11-RIPE
tech-c:          SNOC11-RIPE
mnt-by:          TJANTIK-MNT
nic-hdl:        WTC2-RIPE
abuse-mailbox:  abuse@telia.dk
remarks:        ************************************************************
remarks:        *** In case of abuse, please contact abuse@telia.dk ***
remarks:        ************************************************************
created:        2003-02-18T22:06:24Z
last-modified:  2015-07-16T08:36:04Z
source:          RIPE
Login to update RIPEstat

route:          195.184.96.0/19
descr:          WEBPARTNER A/S

Der er tilsyneladende ingen adgang til access-log på serveren (One com.)

Har eksperimenteret med PHP-blokering, og igen en slags midlertidig virkning i 5 minutters tid, men så fandt den åbenbart ind igen.

Det må åbenbart være en avanceret robot der på en eller anden måde er i stand til at sløre sin adresse over for værktøjerne.

https://www.one.com/da/support/guide/advanceret/logfiler

Ja der har jeg været inde flere gange, ingen knap, men en rude med beskeden:


File system path

/customers/c/c/a/finnholbek.dk//httpd.www/

Så ville jeg kontakte one.com for at tjekke om det er korrekt at logfilerne ikke er der

ja det er også planen.

Ved ikke, kikkede efter at lave en txtfil med ip'er som skulle bannes, ( ved at det kunne man engang ), men fandt denne side:
https://httpd.apache.org/docs/2.4/howto/access.html
" Allow, Deny, and Order directives, provided by mod_access_compat, are deprecated" ...........
Ikke at de ikke stadig virker, men man skal starte på at undgå at bruge dem.

Hej Leif, de er der ikke mere, supporten svarer: "Okay ja, du kan ikke se log filer mere direkte - denne funktion er ikke tilgængelig mere".

så jeg må gå ud fra programmets oplysninger: http://finnholbek.dk/showlog.php?autorefresh=1

Så må jeg melde pas

Hej Leif

Supporten har vist heller ikke nogle ideer til hvad man kan gøre.
Tak fordi du prøvede.

Venlig hilsen Finn

Jeg forstår ikke, at du ikke kan blokere med php ?

if ($_SERVER["REMOTE_ADDR"] == "178.119.148.239") {
header("Location:http://www.computerworld.dk/eksperten/spm/1014051?k=8241051");
exit;
}

Hey, det er så netop forsøgt, og loggen siger

Fri 09 Dec 2016 20:12:41 Individuelle oplysninger om Alexander Grieg (I80808) udført af 178-119-148-239.access.telenet.be.
Fri 09 Dec 2016 20:12:37 Aner til: (I67081 ) udført af 178-119-148-239.access.telenet.be.
Fri 09 Dec 2016 20:12:29 Individuelle oplysninger om Kresina a peasant (I29023) udført af crawl-66-249-76-134.googlebot.com.
Fri 09 Dec 2016 20:12:24 Individuelle oplysninger om Anders Hansen Lilliefeld (I34064) udført af crawl-66-249-76-134.googlebot.com.
Fri 09 Dec 2016 20:12:19 Spindesiden: Eler (den skaldede) Reventlow (II7812) udført af crawl-66-249-69-206.googlebot.com.
Fri 09 Dec 2016 20:12:05 Individuelle oplysninger om Pål Tandberg (I19319) udført af 178-119-148-239.access.telenet.be.

stadigvæk ingen effekt på php-koden, den er åbenbart immun over for alt.

tak for forsøget showsource.

Efter 20 min. uden besøg fra adressen (for første gang i 14 dage), tør jeg efterhånden tro på at dette var den rigtige løsning:

deny from 178.119.148.239 (virker ikke)
deny from 178-119-148-239.access.telenet.be (det VIRKER sgu !!!!)

Interessant ikke?

"Interessant ikke? " -> jo da, og kom jeg på datamatiker uddannelsen, ville jeg gå efter DB opbygning og netværk.
Men sgu da fint at det formodentlig virker.
Evt. en
deny from *.telenet.be
ville måske også gøre det ?
Omend at det jo så vil være enhver telenet.be som udelukkes.

Men da du stillede spm, forvekslede du så ikke 178.119.148.239 med 178-119-148-239 ???

Jeg har altid troligt oversat ip.-adresserer til punktummer (vha. diverse værktøjer og standarter) og det har altid virket.

Men anyway, der ER altså åbenbart forskel på bindestreger og punktum i visse tilfælde (?)