Server krijgt veel random get/post/connect requests

[KingHorse]

Goedenavond Forum,

Ik ben er vanochtend achter gekomen dat me server continue requests krijgt voor pagina's die niet bestaan, denk hierbij aan sites voor aparte sites, maar ook steam api of bing. Ieder IP vraagt steeds om een bepaalde pagina. Meestal in GET, maar POST komt ook vaak voor en heel soms CONNECT.

Hoe ik hier achter ben gekomen:
Gisteren was het subdomein geregeld voor het domein waar de server wordt vanaf benaderd volgende week, Server is er voor een live uitslagen van een paardenwedstrijd. Ik merkte op dat het lang duurde voordat de pagina ging laden. Dus ben gaan kijken naar de configuratie van Apache2. Hierbij Google Chrome dev opties gebruikt. Hierbij kwam naar voren dat de redirect van http naar https heel lang duurde, kon niks vinden wat het probleem is. HTTPS website waar iedereen naar moet worden geredirect is wel goed en vlot bereikbaar.(reden waarom ik dus dit niet heb op gemerkt)

Vanochtend weer even verder gegoogled en kwam bij apache status mod. Hierbij werd de rede van het trage reageren direct duidelijk, alle processen waren in gebruik door andere request(alle 150 ).

Ik doe zelf een ICT - studie. Dus aan ook aan me mede studenten gevraagd, die vermoede een slow lorus attack.

Huidige situatie:
Ik heb nu al wat aangepast voor een slow lorus attack, op moment is me server weer vlot bereikbaar, niet meer 10 seconden wachten, maar 1 a 2 seconden. (HTTP redirect naar HTTPS). Maar het aantal requests schaalt mee met de capiteit soort van, vanochtend zaten ze rond 35 per seconden. Na de aanpassingen richting 70 per seconden. En na meer aanpassingen pieken van 110(95 gem.).

Dus aan de bereikbaar ligt het dus niet meer, enkel dat ik het geen fijn gevoel vind is dat me server continue wordt "aangevallen".

Software:
Ubuntu 16.04
Apache/2.4.18
Lets encrypt

Server:
OVH VPS 1
1 vCore 2.4GHZ
2GB
10GB opslag
100mbit up/down

Mijn vermoede hoe iemand bij mijn server zijn gekomen is het .ml domein wat ik 3 maanden heb gebruikt. Deze stond ook geruime tijd hoog in google onder de officiële website van de organisatie. (iedere geval eerste pagina).

Mijn vraag is wat denken jullie wat voor aanval het is? En wat ik kan ik nu het beste doen in deze situatie?

Met vriendelijke groet,
Nick

[MAX3400]

Het is goed om te weten of de "aanval" plaatsvindt met een specifiek request (wat je dus zou kunnen filteren) of met een algemeen request (waardoor Apache eerst moet reageren). En eventueel zou het handig zijn als je inzichtelijk hebt of het bepaalde IP-ranges of herhalende IP's zijn.

Geen idee wat het budget is maar in volgorde van "proberen", zou je kunnen kijken naar

- iptables als je een specifiek request / port wil blokkeren zonder "discriminatie"
- fail2ban als je bepaalde IP's wil blokkeren die in tijd X meer dan Y verkeerde requests doen
- load-balancer / DDOS-bescherming (eventueel bij/via de hostingprovider)

Vergeet even niet: OVH is voor dit soort zaken een ruk-hoster. Zeker omdat je een VPS hebt, is de support erg laag en/of mag je premium bijbetalen voor bepaalde veiligheid/toezicht. Dit komt (voornamelijk) omdat bepaalde IP-ranges van OVH nogal blacklisted/verdacht zijn en ze dus zelf ook geen interesse hebben om hier wat tegen te doen.

[Thralas]

KingHorse schreef op vrijdag 22 december 2017 @ 18:03:
Ik ben er vanochtend achter gekomen dat me server continue requests krijgt voor pagina's die niet bestaan, denk hierbij aan sites voor aparte sites, maar ook steam api of bing. Ieder IP vraagt steeds om een bepaalde pagina. Meestal in GET, maar POST komt ook vaak voor en heel soms CONNECT.

Wat bedoel je met 'pagina's die niet bestaan'? Dat is niet duidelijk genoeg. Ik neem aan dat het volledige URLs naar de desbetreffende services zijn?

Want de CONNECT requests bevestigen het eigenlijk al: 'men' denkt blijkbaar dat je een proxy draait.

Mijn vermoede hoe iemand bij mijn server zijn gekomen is het .ml domein wat ik 3 maanden heb gebruikt. Deze stond ook geruime tijd hoog in google onder de officiële website van de organisatie. (iedere geval eerste pagina).

Dat is een slechte uitleg als het proxygedeelte klopt. Of je hebt zelf Apache's mod_proxy heel erg verkeerd geconfigureerd, óf de vorige eigenaar van je IP draaide een open proxy.

En wat ik kan ik nu het beste doen in deze situatie?

Als je zelf nooit een open proxy hebt gedraaid: 2x klikken in het OVH control panel om een VPS met een ander IP te spawnen en daar alles heen verkassen. Problem solved.

[KingHorse]

Thralas schreef op vrijdag 22 december 2017 @ 18:55:
[...]


Wat bedoel je met 'pagina's die niet bestaan'? Dat is niet duidelijk genoeg. Ik neem aan dat het volledige URLs naar de desbetreffende services zijn?

Want de CONNECT requests bevestigen het eigenlijk al: 'men' denkt blijkbaar dat je een proxy draait.


[...]


Dat is een slechte uitleg als het proxygedeelte klopt. Of je hebt zelf Apache's mod_proxy heel erg verkeerd geconfigureerd, óf de vorige eigenaar van je IP draaide een open proxy.


[...]


Als je zelf nooit een open proxy hebt gedraaid: 2x klikken in het OVH control panel om een VPS met een ander IP te spawnen en daar alles heen verkassen. Problem solved.

Goedemorgen,

Verkeerd verwoord, naar pagina's die niet op mijn server staan.

Een virtualhost is een proxy naar nginx, die haal ik eruit, wordt niet gebruikt. .ml domein verwijderd, TTL was 5 minuten, dus redelijk snel offline. Server heb ik uitgezet, want de logs groeien te hard, 250 MB in 3 uur. Straks alles opruimen wat niet nodig is, even kijken wat er gebeurd, nog steeds spam, dan even die tip doorvoeren, en het domein laten bijwerken.

Bedankt allemaal zover!

Gr. Nick
Edit: Even mijn ip gegoogled, deze stond op een free proxy list die dagelijks wordt bij gewerkt, op die vandaag niet meer, maar weet niet wat er gebeurt als ik me server weer aanzet, denk dat in notime ik daar weer verschijn.

[ Voor 8% gewijzigd door KingHorse op 23-12-2017 09:54 ]

[Thralas]

KingHorse schreef op zaterdag 23 december 2017 @ 08:42:
Een virtualhost is een proxy naar nginx,

Klinkt alsof je daar zelf het een en ander verkeer hebt ingesteld.

Gr. Nick
Edit: Even mijn ip gegoogled, deze stond op een free proxy list die dagelijks wordt bij gewerkt, op die vandaag niet meer, maar weet niet wat er gebeurt als ik me server weer aanzet, denk dat in notime ik daar weer verschijn.

..want anders wordt je echt meteen van zo'n lijst af gegooid.

[Miepermans]

KingHorse schreef op vrijdag 22 december 2017 @ 18:03:
~~~~
Dus aan de bereikbaar ligt het dus niet meer, enkel dat ik het geen fijn gevoel vind is dat me server continue wordt "aangevallen".
~~~~
Met vriendelijke groet,
Nick

Welcome to the real world.

Dit is standaard, er zijn 100-en sites en diensten ter wereld die continu het hele web afscannen naar nieuwe content, nieuwe vulnerabilities en nieuwe mogelijkheden.

Neem een voorbeeld aan Google, minimaal 2 keer per dag worden mijn eigen servers afgestruind door de web-crawlers van Google. Je moet wat als je geindexeerd wenst te blijven.

Hoe komen sites als Shodan en dergelijken anders aan die mooie overzichten van mogelijke fouten in systemen, websites met default passwords in wordpress en soortgelijke issues?

<zeikmodus>
Puur als tip trouwens, je gebruikt in je post echt meermaals het woord "me" als vervanging voor "mijn". Niet echt tof en het komt echt niet professioneel over.
</zeikmodus>

[Enforcer]

Inderdaad, er zijn genoeg mensen actief op deze gehele aardkloot die het hele internet scannen op blackholes/exploits/etc... Jouw ipadres komt dan vanzelf ook aan de beurt dus zo verwonderlijk is dat niet. Als je je daaraan stoort dan moet je inderdaad gaan filteren en blacklisten zoals al eerder werd omschreven. Anders gewoon lekker met rust laten. Ik krijg dagelijks 100en requests met bruteforce phpmyadmin passwords om de oren, pfSense regelt het lekker verder

[KingHorse]

Miepermans schreef op zaterdag 23 december 2017 @ 14:16:
[...]


Welcome to the real world.

Dit is standaard, er zijn 100-en sites en diensten ter wereld die continu het hele web afscannen naar nieuwe content, nieuwe vulnerabilities en nieuwe mogelijkheden.

Neem een voorbeeld aan Google, minimaal 2 keer per dag worden mijn eigen servers afgestruind door de web-crawlers van Google. Je moet wat als je geindexeerd wenst te blijven.

Hoe komen sites als Shodan en dergelijken anders aan die mooie overzichten van mogelijke fouten in systemen, websites met default passwords in wordpress en soortgelijke issues?

<zeikmodus>
Puur als tip trouwens, je gebruikt in je post echt meermaals het woord "me" als vervanging voor "mijn". Niet echt tof en het komt echt niet professioneel over.
</zeikmodus>

Bedankt voor de tip, zal er om denken. Tja, het is helaas wat het is.

Ik heb nu ovh gevraagd om een nieuw ip. Aantal requesten is nu 500 per seconden. Wel apache aangepast, dus ze komen er niet door heen(zelf getest), maar wel dat mijn logs te groot worden. Binnen 4 uur 800MB. (server dus weer uit)

Bedankt!

[ddkiller0900]

KingHorse schreef op zaterdag 23 december 2017 @ 17:40:
[...]

Bedankt voor de tip, zal er om denken. Tja, het is helaas wat het is.

Ik heb nu ovh gevraagd om een nieuw ip. Aantal requesten is nu 500 per seconden. Wel apache aangepast, dus ze komen er niet door heen(zelf getest), maar wel dat mijn logs te groot worden. Binnen 4 uur 800MB. (server dus weer uit)

Bedankt!

Voor een klant van mij heb ik ook meegemaakt dat de server (door de klant gehost bij Ovh) continu werd aangevallen. Het was zo erg dat de switch waar de host op was aangesloten problemen begon te vertonen, waardoor Ovh uiteindelijk de VPS heeft verhuisd naar een andere host en een ander IP heeft gegeven. Zoals eerder al aangegeven kan je het beste je server goed afschermen met firewall rules (iptables) waar dat kan. Bescherm je ook tegen syn attacks, xmas attacks etc.

Wat je logging betreft zou ik gebruik maken van logrotate zodat je in ieder geval weet dat je logfiles niet groter worden dan wat jij hebt ingesteld.

[ThinkPad]

Verwacht je verkeer alleen uit NL of ook uit het buitenland? Anders misschien firewall ertussen zetten/regels aanpassen om countryblocking te kunnen doen? Nu is dat natuurlijk wel te omzeilen als ze een proxy gebruiken, maar scheelt al veel verkeer denk ik.

[Rob]

Om het groeien van je logs tegen te gaan, kun je logging van bepaalde requests uitschakelen.
Je bent wel je logging kwijt,maar ik verwacht dat je daar nu al weinig mee ging doen

De NGINX proxy klinkt al als het probleem.Die stond naar alle waarschijnlijkheid verkeerd geconfigureerd.

Wel apache aangepast, dus ze komen er niet door heen(zelf getest), maar wel dat mijn logs te groot worden.

Als je iets opzet/bouwt, dan ben je zelf niet een goeie tester. Je weet teveel van het systeem en laat daardoor tests links liggen. Laat iemand mee testen.

Wat serveert je server nu op de requests die gedaan worden?

[KingHorse]

ThinkPadd schreef op dinsdag 26 december 2017 @ 11:47:
Verwacht je verkeer alleen uit NL of ook uit het buitenland? Anders misschien firewall ertussen zetten/regels aanpassen om countryblocking te kunnen doen? Nu is dat natuurlijk wel te omzeilen als ze een proxy gebruiken, maar scheelt al veel verkeer denk ik.

95% nederlands, maar lees op facebook waarschijnlijk ook uit andere landen.

Rob schreef op dinsdag 26 december 2017 @ 12:24:
Om het groeien van je logs tegen te gaan, kun je logging van bepaalde requests uitschakelen.
Je bent wel je logging kwijt,maar ik verwacht dat je daar nu al weinig mee ging doen

De NGINX proxy klinkt al als het probleem.Die stond naar alle waarschijnlijkheid verkeerd geconfigureerd.


[...]


Als je iets opzet/bouwt, dan ben je zelf niet een goeie tester. Je weet teveel van het systeem en laat daardoor tests links liggen. Laat iemand mee testen.

Wat serveert je server nu op de requests die gedaan worden?

De requests kregen de standaard webpagina terug. Goede tip!

Onder tussen dus een nieuwe server opgezet, de oude staat nog aan om instellingen over te zetten mocht iets niet werken.(apache uit) Was een domme fout van mij, had beter moeten lezen Bedankt voor alle tips.

De website is te bereiken op --webserer is offline-- FTP gaat nog niet helemaal goed, soms een rechten fout, moet me hier even goed in verdiepen. En de programmamaker vragen voor de support van SFTP, want tja FTP is niet bepaalt veilig(geen belangerijke gegevens hoor.)

[MAX3400]

KingHorse schreef op dinsdag 26 december 2017 @ 19:41:
[...]

...En de programmamaker vragen voor de support van SFTP, want tja FTP is niet bepaalt veilig(geen belangerijke gegevens hoor.)

Programmamaker? Je hebt toch een VPS? Dan installeer je zelf toch een "secure FTP" server zoals vsftpd?

[CyBeR]

KingHorse schreef op zaterdag 23 december 2017 @ 17:40:
[...]
Aantal requesten is nu 500 per seconden.

Euh, wat?

[Thralas]

CyBeR schreef op dinsdag 26 december 2017 @ 19:56:
[...]

Euh, wat?

Dat was op z'n oude machine. Omdat 'ie een open proxy draaide.

Twee personen schieten hierboven in de 'welkom op het internet'-modus, maar er is veel meer aan de hand als je CONNECT requests ziet en jezelf op een open proxy list terugziet (gooien ze je ook zo weer vanaf).

Blijft dus zaak voor TS om z'n proxy setup grondig te herzien, anders gebeurt exact hetzelfde nogmaals.

[KingHorse]

MAX3400 schreef op dinsdag 26 december 2017 @ 19:47:
[...]

Programmamaker? Je hebt toch een VPS? Dan installeer je zelf toch een "secure FTP" server zoals vsftpd?

het zit zo, de hoofdvereniging van de paardensport(KNHS) heeft een programmeur in armen genomen om een systeem te maken om wedstrijdgegevens geautomatiseerd te verwerken. Dit heet concours 3.5 (http://concours35.nl)

2 jaar terug werd er een ander systeem gebruikt bij deze wedstrijd waarbij live uitslagen waren. Deze is vervangen door bovenstaand programma, omdat het beter samenwerkt met de KNHS. In dit programma zit de de mogelijkheid om startlijsten/uitslagen te uploaden naar een ftp server. Enkel werkt dit dus enkel met ftp, en is het zo slecht in elkaar gezet dat het programma vast loopt als deze upload(windows reageert niet titel wordt toegevoegd). 17 december een test dag gehad ging redelijk. Deze week een test week, en dan kijken of dit werkbaar is in de toekomst.

dus Ik zat zo te denken misschien kan ik hier een php pagina voor schrijven om deze html bestanden makkelijk weer te geven. De website is naar mijn mening nog ver van af en heeft nog te veel fouten, als het een succes wordt moet alles worden herschreven, normale database link(geen txt bestand) en dus kijken of dat deel van het programma kan worden verbeterd.
Zoals jullie al door hebben heb ik nog veel te leren, vandaar de test.

Hoop dat dit de boel op helderd

[ Voor 10% gewijzigd door KingHorse op 26-12-2017 21:22 ]

[CyBeR]

Thralas schreef op dinsdag 26 december 2017 @ 20:19:
[...]


Dat was op z'n oude machine. Omdat 'ie een open proxy draaide.

Twee personen schieten hierboven in de 'welkom op het internet'-modus, maar er is veel meer aan de hand als je CONNECT requests ziet en jezelf op een open proxy list terugziet (gooien ze je ook zo weer vanaf).

Mja CONNECT reqs zien is niet vreemd maar de "welkom op het internet" reqs (internetruis) zijn er geen 500 per seconde. Eerder 500 per uur.

500 reqs per seconde trek ik net aan op m'n drukst bezochte website…

[KingHorse]

CyBeR schreef op dinsdag 26 december 2017 @ 21:32:
[...]


Mja CONNECT reqs zien is niet vreemd maar de "welkom op het internet" reqs (internetruis) zijn er geen 500 per seconde. Eerder 500 per uur.

500 reqs per seconde trek ik net aan op m'n drukst bezochte website…

Dit zei apache op basis van het aantal request en uptime volgens mij.(server status pagina)

[valkenier]

KingHorse schreef op dinsdag 26 december 2017 @ 19:41:
[...]


De website is te bereiken op https://live.indoorbeukers.nl/ FTP gaat nog niet helemaal goed, soms een rechten fout, moet me hier even goed in verdiepen. En de programmamaker vragen voor de support van SFTP, want tja FTP is niet bepaalt veilig(geen belangerijke gegevens hoor.)

*kuch*
wget http://live.indoorbeukers.nl
--2018-01-04 11:44:46-- http://live.indoorbeukers.nl/
Herleiden van live.indoorbeukers.nl (live.indoorbeukers.nl)... 54.38.40.124
Verbinding maken met live.indoorbeukers.nl (live.indoorbeukers.nl)|54.38.40.124|:80... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 196 [text/html]

geen redirect naar https


wget https://live.indoorbeukers.nl
--2018-01-04 11:45:11-- https://live.indoorbeukers.nl/
Herleiden van live.indoorbeukers.nl (live.indoorbeukers.nl)... 54.38.40.124
Verbinding maken met live.indoorbeukers.nl (live.indoorbeukers.nl)|54.38.40.124|:443... verbonden.
FOUT: kan certificaat van live.indoorbeukers.nl (uitgegeven door ‘emailAddress=[e-mail],CN=shapid.info,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--’) niet controleren:
Kan de autoriteit van de uitgever niet lokaal verifiëren.
FOUT: naam '‘shapid.info’' in certificaat komt niet overeen met gevraagde hostnaam '‘live.indoorbeukers.nl’'.

wget https://shapid.info
--2018-01-04 12:43:20-- https://shapid.info/
Herleiden van shapid.info (shapid.info)... 54.38.40.124
Verbinding maken met shapid.info (shapid.info)|54.38.40.124|:443... verbonden.
FOUT: kan certificaat van shapid.info (uitgegeven door ‘emailAddress=[e-mail],CN=shapid.info,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--’) niet controleren:
Kan de autoriteit van de uitgever niet lokaal verifiëren.
Gebruik '--no-check-certificate' om een onbeveiligde verbinding met shapid.info te maken.


Shapid.info verwijst naar het zelfde ip als live.indoorbeukers.nl, maar met de certificaten deugt het dus ook niet, en je je index.html creëert loops.

maar goed ik geloof dat je evenement inmiddels achter de rug is.

[ Voor 19% gewijzigd door valkenier op 04-01-2018 12:49 ]

[KingHorse]

valkenier schreef op donderdag 4 januari 2018 @ 11:50:
[...]


*kuch*
wget http://live.indoorbeukers.nl
--2018-01-04 11:44:46-- http://live.indoorbeukers.nl/
Herleiden van live.indoorbeukers.nl (live.indoorbeukers.nl)... 54.38.40.124
Verbinding maken met live.indoorbeukers.nl (live.indoorbeukers.nl)|54.38.40.124|:80... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 196 [text/html]

geen redirect naar https


wget https://live.indoorbeukers.nl
--2018-01-04 11:45:11-- https://live.indoorbeukers.nl/
Herleiden van live.indoorbeukers.nl (live.indoorbeukers.nl)... 54.38.40.124
Verbinding maken met live.indoorbeukers.nl (live.indoorbeukers.nl)|54.38.40.124|:443... verbonden.
FOUT: kan certificaat van live.indoorbeukers.nl (uitgegeven door ‘emailAddress=[e-mail],CN=shapid.info,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--’) niet controleren:
Kan de autoriteit van de uitgever niet lokaal verifiëren.
FOUT: naam '‘shapid.info’' in certificaat komt niet overeen met gevraagde hostnaam '‘live.indoorbeukers.nl’'.

wget https://shapid.info
--2018-01-04 12:43:20-- https://shapid.info/
Herleiden van shapid.info (shapid.info)... 54.38.40.124
Verbinding maken met shapid.info (shapid.info)|54.38.40.124|:443... verbonden.
FOUT: kan certificaat van shapid.info (uitgegeven door ‘emailAddress=[e-mail],CN=shapid.info,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--’) niet controleren:
Kan de autoriteit van de uitgever niet lokaal verifiëren.
Gebruik '--no-check-certificate' om een onbeveiligde verbinding met shapid.info te maken.


Shapid.info verwijst naar het zelfde ip als live.indoorbeukers.nl, maar met de certificaten deugt het dus ook niet, en je je index.html creëert loops.

maar goed ik geloof dat je evenement inmiddels achter de rug is.

Ja het evenement is al afgelopen, zaterdagavond 30 december ging de laatste combinatie de baan in en op 31 december rond een uur of 11 alles van de servers afgehaald, configs op geslagen, en servers verwijderd, dus IP is al reeds in gebruik door een andere persoon Ik heb de webmaster reeds geïnformeerd dat het subdomein eruit kan, zeker omdat het nu naar iets heel anders verwijst. Bedankt voor je voor tijd om te kijken!!

[valkenier]

Aha, nou dat verklaart veel....

[KingHorse]

valkenier schreef op donderdag 4 januari 2018 @ 21:50:
Aha, nou dat verklaart veel....

Excuses voor het niet goed vermelden

[valkenier]

Ah joh, allang goed.