Pagina: 1 2 volgende »
15/05/2016 16:24:22
Ik zie op Fail2Ban dat er nogal wat inbraakpogingen worden gedaan op 'plesk-postfix'. Nu wil ik dit daarom strenger gaan afstellen zodat er eerder wordt overgegaan tot een ban.
Ik heb begrepen dat Postfix een mailserver is. Volgens mij gebruik je dit dan vooral om vanaf je mailcliënt op je PC te connecten met de server. Klopt dat? Maar wat ik me afvraag is of dit ook gebruikt wordt bij webmail (bijv. Roundcube). Of heeft postfix daar niks mee te maken?
Gewijzigd op 15/05/2016 16:26:20 door
Ozzie PHP
17/02/2025 09:41:23
15/05/2016 16:36:59
Postfix is gewoon een SMTP server. Niet meer, niet minder. Je hebt hem nodig om vanaf je server mail te kunnen versturen/ontvangen. Roundcube heeft hem nodig, PHP heeft het nodig als je ermee mailt via de interne functies, etc etc.
Het is niet vreemd dat je meldingen krijgt over SMTP servers, het is waar het meest naar gezocht wordt: open relays. Die worden dan door de spammers misbruikt. Ik weet niet wat het nut is van strenger afstellen. Er wordt meestal niet meer dan 1 request gedaan, waarna heel simpel de reactie is "oke, die is dicht".
15/05/2016 16:44:14
Nee, er wordt niet maar 1 request gedaan. Ik heb nu een IP-adres dat keurig ieder half uur een inbraakpoging doet. Omdat er zoveel tijd tussenzit, wordt ie niet geband. :-s
Maar als ik je dus goed begrijp ... stel ik log via webmail (bijv. Roundcube) in op de server, dan is deze jail dus van toepassing? Want dan kan ik namelijk niet té streng zijn.
15/05/2016 16:48:57
Niet zozeer bij het inloggen, maar bij het versturen van mail. Maar omdat die requests van localhost komen zit er waarschijnlijk geen authenticatie tussen. Dat zou in ieder geval niet logisch zijn. Roundcube authenticatie zelf loopt via je IMAP server, bijvoorbeeld Courier of Dovecot. Als het ieder half uur is is het ook niet zinnig om er naar te kijken. Het zijn ook geen inbraakpogingen, als je goed kijkt zie je dat er geen poging tot inloggen wordt gedaan.
15/05/2016 16:56:04
>> Niet zozeer bij het inloggen, maar bij het versturen van mail.
Dus kan ik postfix gerust wat strakker afstellen dan lijkt me? Aangezien het dus niet gaat om het handmatig invoeren waarbij de kans op een vergissing groter is?
>> Het zijn ook geen inbraakpogingen, als je goed kijkt zie je dat er geen poging tot inloggen wordt gedaan.
Dit snap ik niet. In mijn log staat toch echt:
failed mail authenticatication attempt for user 'internet@xxxxxxx' (password len=9)
warning: unknown[xx.xxx.xxx.xx]: SASL LOGIN authentication failed: authentication failure
Dat lijkt me toch echt een inbraakpoging (om in te loggen op de mail bedoel ik dan).
15/05/2016 17:00:19
Ozzie, als jij de optie roundcube hebt, en je zit in Spanje aan een cocktail op het strand en verwacht dat je een belangrijke mail krijgt dan is het heel ongemakkelijk dat je dan zelf geband word op je mailserver he.
Het is een stukje vrijheid die je hebt natuurlijk. Als je die optie niet gebruikt/hebt kan je heb gewoon blokkeren he.
Ikzelf gebruik roundcube heel vaak, dus dat er ergens eens een poging word gedaan om in te loggen kan, maar die word ook gewoon geband. Alleen zou ik hem niet te strak afstellen als je zelf eens een tikfoutje maakt dan loop je het risico er zelf niet meer bij te kunnen. ;)
Gewijzigd op 15/05/2016 17:01:02 door
Bart V B
15/05/2016 17:01:41
Heel bijzonder, dat is niet het soort bots dat je normaal voorbij ziet komen. Aan de andere kant, op de meeste servers die ik inricht heb ik ook geen SASL op poort 25, ik ontvang er alleen mail op, als je mail wilt versturen moet dat via submission (587) die wel SASL heeft. Uiteraard werkt lokaal mailen via 25 dan nog wel. Maar zoals gezegd: heel bijzonder, want het is praktisch niet te gokken wat een geldige user zou kunnen zijn, afgezien van de gebruikelijke info@, service@ etc. Áls het al zo is dat je e-mailadressen als gebruikersnaam gebruikt, dat hoeft niet eens.
15/05/2016 17:05:31
>> Alleen zou ik hem niet te strak afstellen als je zelf eens een tikfoutje maakt dan loop je het risico er zelf niet meer bij te kunnen. ;)
Dat moet ik inderdaad voorkomen ;-) Hoewel ik dan zou kunnen inloggen op het panel en de ban ongedaan zou kunnen maken :-)
Maar dat stomme IP-adres stopt er dus telkens de nodige tijd tussen, waardoor hij niet wordt 'opgepikt' door Fail2Ban ... grrrr
>> Heel bijzonder ...
Nou, noem het maar gewoon irritant. Nou zit er ineens een uur tussen de laatste poging. De bot die er achter hangt is dus bewust zó ingesteld dat ie niet wordt opgemerkt. Aardig irritant!
15/05/2016 17:11:13
Ach, als er zoveel tijd tussen zit zou ik me er gewoon niet druk om maken. Er is iets als teveel nadruk leggen op dit soort idiote details, ga je bezig houden met belangrijke zaken ;-)
15/05/2016 17:14:19
Tja, dat zou je kunnen zeggen ... maar die klote bot gaat dag en nacht door. Die gaat m'n log met honderden regels per week vervuilen. Die moet dus keihard worden geband!
15/05/2016 17:22:43
Als hij in dit tempo doorgaat doet hij weinig bijzonders, en maakt hij ook geen kans. Misschien is een belangrijke les ook het leren prioritiseren van verschillende zaken. Als voorbeeld: fail2ban is op zichzelf leuk, maar voor dit soort zaken is het vrij zinloos. Wanneer je hoge frequenties gaat zien van inlogpogingen kan fail2ban mooi ingrijpen, maar die laagfrequente zooi kun je net zo goed met rust laten. Het heeft geen meerwaarde om er wat aan te doen. En honderden regels.. tsja, de logs roteren toch wel weg. Als het geen tienduizenden worden, zoals bij legitiem mailverkeer ook al snel gebeurt zou ik er niet verder naar kijken. Zonde van de tijd (ja, ook alle geldige mail wordt gelogd).
15/05/2016 17:25:11
Daar heb je inderdaad een punt.
>> tsja, de logs roteren toch wel weg
Roteert de 'secure' log eigenlijk ook automatisch, of moet je dat ergens instellen?
15/05/2016 17:27:31
De standaard logs (dus ook de secure logs) roteren vanzelf wel. Custom logs kun je ook nog instellen, als je dat wilt roteren moet je dat ook nog even instellen. Zie logrotate.conf.
15/05/2016 17:29:46
>> Zie logrotate.conf.
Ah oké ... maar daar zie ik die 'secure' log niet bij staan. Waar kan ik dat dan instellen?
15/05/2016 17:34:24
Hij hoeft er op zich ook niet te staan, je kan in /var/log heel mooi zien of rotatie plaatsvindt. Ik heb de standaard logs ook niet in logrotate.conf, maar ze roteren wel degelijk.
15/05/2016 17:37:24
Als een log geroteerd wordt gaat ie dan naar een apart mapje? Ik zie nu namelijk nog niks wat geroteerd is.
15/05/2016 18:15:34
Ze worden afhankelijk van de configuratie eerst hernoemd, eventueel gecomprimeerd, en de oudste logs verwijderd. Op mijn CentOS installaties worden er 4 weken aan logs bijgehouden; iedere week vindt een rotatie plaats, en hiervan worden 4 bestanden per stuk bewaard.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# use date as a suffix of the rotated file
dateext
De logrotate configuratie voor messages, secure, maillog etc bevindt zich hier in /etc/logrotate.d/syslog
15/05/2016 20:12:06
Ah, grappig ... die configuratie instellingen zijn bij mij precies hetzelfde! (ook CentOS)
>> De logrotate configuratie voor messages, secure, maillog etc bevindt zich hier in /etc/logrotate.d/syslog
Ah oké, ik zie het inderdaad. Bij mij staat er dit in:
Quote: missingok
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
Weet jij wat dat wil zeggen?
En zijn die settings (weekly, rotate 4 enz.) ook van toepassing op de logs messages, secure, maillog enz. ?
Wel nice trouwens dat dit al is geregeld. Ik had eigenlijk gedacht dat ik iets moest installeren om die rotatie voor elkaar te krijgen.
15/05/2016 20:16:09
Die postrotate herstart syslogd (stuurt een SIGHUP naar het pid dat te vinden is in /var/run/syslogd.pid), en negeert het slagen/falen ervan (|| true). De settings zijn globaal, maar zijn per onderdeel te veranderen.
15/05/2016 20:19:48
Hihihi ... ik snap werkelijk niks van wat je hier zegt :D
Zijn die instellingen om weekly te rotaten trouwens oke? Is het bijv. niet handiger om op 'size' te rotaten (als dat kan), of maakt dat niet zoveel uit eigenlijk?
15/05/2016 20:48:56
Je kan op size rotaten, op tijd, of een combinatie ervan. De standaard yum logrotate roteert jaarlijks of als ik het me goed herinner als het log 30kb bereikt.
