Bekijk Volledige Versie : Opeens berichten van niet bestaande hostnaam?
Een van de servers begint opeens berichten te sturen uit naam van de verkeerde hostnaam.
Dat doet zowel CSF/LFD firewall alsook Directadmin update notificaties.
Van csf krijg ik bijv. dit bericht:
lfd on server.rtvpresident.com: blocked 201.73.178.100 (BR/Brazil/-)
van: root@server.rtvpresident.com
aan: root@server.rtvpresident.com
Nu komt de grap, deze hostnaam bestaat helemaal niet, wel die domeinnaam, maar dat is op een geheel andere server.
De juiste hostnaam is server15.hosting010.nl
Als ik in de header van de mail ga kijken zie je het volgende:
Return-path: <root@server.rtvpresident.com>
Envelope-to: technical@hostingfun.nl
Delivery-date: Mon, 09 Sep 2013 13:30:33 +0200
Received: from mail by server15.hosting010.nl with spam-scanned (Exim 4.80.1)
(envelope-from <root@server.rtvpresident.com>)
Het return-path en de envelope-from is dus fout, terwijl de "received: from" de juiste hostnaam bevat.
Ook in /etc/sysconfig/network en in /etc/hosts staat de juiste hostnaam vermeld.
Het commando "hostname" geeft ook de juiste hostnaam weer.
Het is een server met Directadmin ingeregeld. Waar zou deze opeens de niet bestaande hostnaam server.rtvpresident.com vandaan kunnen toveren?
Kevin Bentlage
09/09/13, 21:13
Is de user waarvan de domeinnaam wordt gebruikt in de mails toevallg geen admin user? Ik heb dit zelfde grapje ook eens gehad, alles doorzocht bleek de user admin rechten te hebben waardoor deze alle notificaties ontving. :sneaky2:
De user waarvan de domeinnaam wordt gebruikt is een admin, maar dat heeft er volgens mij niet mee te maken, want deze domeinnaam komt op deze server met dit vreemde euvel nergens voor. Ook in geen enkel bestand in /var/named/*.db komt hij voor.
Daarnaast gaat het hier niet alleen om een domeinnaam maar een complete hostnaam, waar haalt hij die vandaan?
Overigens worden berichten van de custombuild crontab en csf/lfd via de root user verzonden, niet via een gewone user voor zover mij bekend.
Als je naar het custombuild script kijkt in de crontab wordt ook gewoon de hostnaam aangeroepen.
Dus ik vind het een heel vreemd iets. Maar toch alvast bedankt voor het meedenken!
Edit: Aanvulling. De hostnaam server.rtvpresident.com kom ik ook niet tegen in Exim's mainlog of rejectlog. Alleen in /var/log/maillog is hij terug te vinden bijv. als volgt:
Sep 9 02:25:28 server15 spamd[1903]: spamd: processing message <E1VIpHc-0002NE-Sm@server.rtvpresident.com> for hostingfun:504
Kevin Bentlage
09/09/13, 21:57
Oke, duidelijk.
Heb je onder "Administrator Settings" in DirectAdmin ook de juiste hostname geset?
Jazeker, net nog even opnieuw gesaved, just to be sure. Meteen daarna kreeg ik weer een berichtje van LFD toevallig dat er weer een chinees geblokkeerd was.
Zelfde probleem.
Het is echt geen DA probleem, want DA heeft niets met CSF/LFD te maken. En beiden hebben ze hetzelfde probleem. Het gebeurt alleen met berichten die door root verzonden worden, gewone gebruikers hebben er dus geen last van.
systemdeveloper
09/09/13, 22:44
Is het vps toevallig een clone van een ander vps? (Of door jou gedaan, of door de hoster die het opleverde?)
En check even je /etc/hosts of daar ook de juiste hostname staan.
VPS? Niet echt. Het is een dedicated server en die zjin allemaal door mij zelf ingeregeld.
De /etc/hosts file is ook goed....
Ook in /etc/sysconfig/network en in /etc/hosts staat de juiste hostnaam vermeld.
Volgens mij heb ik het gefixed. Een tijdje geleden stond er een /public_html directory in de directory van root. Geen idee hoe die er gekomen is maar die heb ik weggehaald.
Nu stond er een Maildir directory:
drwx------ 2 root root 4.0K Jun 1 22:14 Maildir
Deze verwijderd en hups... de berichten komen nu weer met de juiste hostnaam binnen.
Heel vaag, want hier staat een datum van 1 juni bij, en het probleem begon zich pas vanaf zaterdagavond rond 22.15 voor te doen.
Gaat nu dus weer goed:
Return-path: <root@server15.hosting010.nl>
Envelope-to: root@server15.hosting010.nl
Delivery-date: Mon, 09 Sep 2013 23:00:22 +0200
Received: from root by server15.hosting010.nl with local (Exim 4.80.1)
(envelope-from <root@server15.hosting010.nl>)
De envelope-to gaat nu wel weer naar root, terwijl hij eerst naar mijn technical email adres ging. Maar dat maakt niet uit want m'n technical is de alias van root.
Die Maildir was leeg, blijft dus de vraag hoe hij nu aan die andere hostnaam kwam.
systemdeveloper
10/09/13, 00:01
Er zijn genoeg manieren om in een account van een user (dus ook root) dingen te regelen om dubieuze (andere) dingen te regelen (no pun intended). Een beetje slim met forwarders of rc bestandjes knutselen en password files staan zo op een website tenslotte.
Dus als je zelf al niet weet hoe dingen in je root directory terecht komen, dan wordt het tijd om dat soort dingen eens uit te gaan zoeken.
Te vroeg gejuicht, krijg net weer een berichtje van CSF/LFD van de verkeerde afzender.
Wat wel apart is, is het feit dat het wel een domein van ons is, alleen van een andere server.
Maar ik geloof niet in een hack, want dit is het enige rare (root mails met andere hostnaam in het return-path en afzender) wat er op die server gebeurt.
Verder staat SSH op een andere poort en is SSH niet toegankelijk middels wachtwoord.
De reden dat ik die public_html en die Maildir directory in mijn /root dir had staan weet ik inmiddels ook weer. Ik heb tijdelijk eens een backup gemaakt voor een user en dat even naar /root gecopieerd als reserve.
Ik had wel die public_html weggehaald, maar ben klaarblijkelijk vergeten de Maildir te verwijderen.
Ik zal dadelijk eens de kernel updaten en rebooten eens kijken wat er dan gebeurt.
Aha, ik ben er uit.
De berichten komen van een oude server van ons. Klaarblijkelijk heeft de oude hoster die weer aangezet en is nog niet opnieuw ingeregeld.
Ik zag het zojuist in die laatste mail, komt via extern binnen:
Received: from [46.xxx.xx.xx] (helo=server.rtvpresident.com)
En die server hebben we al maaaanden niet meer.
Dus ik ga even die hoster eens flink aan zijn oren trekken.
systemdeveloper
10/09/13, 01:09
Haha, wel eerst checken of het je eigen mail is, he ;)
Misschien een heel voor de hand liggende tip, maar aangezien *nix configs met name uit tekstbestanden bestaat, werkt dit aardig.
grep -rl "blabla" /etc
grep -rl "blabla" /usr/local/etc
Daarmee krijg je hetgeen je zoekt meestal wel boven water.
Hoe bedoel je of het mijn eigen mail is? Aan de headers is te zien dat ie van ons is geweest... :)
De hostnaam die gebruikt is, is inderdaad in het verleden gebruikt, en het ip adres herkende ik ook al.
Dus ja, betreffende hoster heeft gewoon een dedi uit het verleden zaterdagavond aan gezet zonder te formatteren.
Ohja, dat commando had ik eerder deze avond al gebruikt op de /etc, /var/named en /home directory.
De mijne is ietsie anders, maar werkt ook uitstekend:
grep -H zoekwoord /home/* -R | cut -d: -f1
systemdeveloper
10/09/13, 02:05
Van elke dubieuze mail moet je EERST kijken of die wel echt van een server komt die je ZELF actief in gebruik hebt. Beetje voor de hand liggend ook wel aangezien je dat redelijk wat tijd kan besparen :)
Hoe bedoel je of het mijn eigen mail is? Aan de headers is te zien dat ie van ons is geweest... :)
De hostnaam die gebruikt is, is inderdaad in het verleden gebruikt, en het ip adres herkende ik ook al.
Dus ja, betreffende hoster heeft gewoon een dedi uit het verleden zaterdagavond aan gezet zonder te formatteren.
Dus met andere woorden je zegt gewoon je dedicated server op zonder zelf ook maar iets te verwijderen of er op zijn minst voor te zorgen dat de server niet meer kan booten. Het is nu niet dat een 'rm -Rf /' zo moeilijk is of even een /boot verwijderen was in dit geval ook al genoeg geweest, als je er blijkbaar toch niks om geeft dat iemand anders je data kan recycleren. Maar het beste is nog altijd even via remote kvm (ipmi, ilo, drac, ...) even booten met dban tool en de hdd even volledig wissen.
@systemdeveloper: Ja doe ik normaal ook altijd, nu ook, was alleen vergeten naar het ip te kijken omdat het zo hetzelfde uitzag als een mail van de juiste server en ik van de juiste server net die dagen geen firewall mails gehad heb.:)
Beetje teveel aan m'n hoofd gehad, volgende keer inderdaad toch wat aandachtiger kijken.
@The-Boss: Ja normaliter remove ik altijd de home directory's, root en etc directory en dan een shutdown. Alleen bij deze server is dat niet gebeurt omdat de huurder er nog wat mee wilde spelen tot einde contracttijd.
Tot nu toe is ons zoiets ook nog nooit gebeurt maar het blijkt dus dat sommige dedi-verhuurder/hosters minder slim zijn dan hun naam doet vermoeden en servers gewoon (na een behoorlijke tijd) weer aanzetten zonder opnieuw te initialiseren. ;)