My server very rarely sees any dodgy attempts to access it and has been this way for over 6 months since I set it up.
I am a total newbie to all of this so please go easy on me and avoid too much jargon
In the last 48 hours though it's seeing a lot more - and I notice something common to them all, despite them being from all over the world, and trying different ports / accounts.
Here is an example of one:
[align=left]lfd on <MYSERVERNAME>: blocked 173.12.152.114 (US/United States/173-12-152-114-northgulf<DOT>hfc<DOT>comcastbusiness<DOT>net)
2013-02-20 17:50:11 [7017] dovecot_login authenticator failed for 173-12-152-114-northgulf<DOT>hfc<DOT>comcastbusiness<DOT>net ([192.168.2.33]) [173.12.152.114]:2722 I=[<MYSERVERIP>]:25: 535 Incorrect authentication data (set_id=catalog)[/align]
<MYSERVERNAME> = My server's name
<DOT> = . (because I am not allowed to post working URLs)
<MYSERVERIP> = My server's IP
The internal IP shown (which I've bolded) I assume is the IP of the attacker on their own local network?
The odd thing is, in all ~10 failed entry attempts today, and around the same number yesterday, that IP address is _precisely_ the same (192.168.2.33).
Is there some known network exploit that targets that IP or am I looking at the same person/bot trying their thang but routing it all over the world so they can retry.
Can I somehow make a rule to block any attempts which mention that local IP? I figure for 99.9999999% of ordinary people on the web (this is a web server primarily) they will be on 192.168.1.1 style IPs locally (Windows/Linux/Mac standard) so likely that rule won't be an issue perhaps, except for this attacker.
Thank you!!
Bob
LFD block reports
Re: LFD block reports
Hang on a mo. That IP is my server's local IP isn't it. I bet it is. I'm being a numpty, right?
Re: LFD block reports
That is botnet-related SMTP Auth brute forcing. It's been going on for months now, off and on. I say botnet-related because the traffic will come on all at once, and from many different IP addresses all over the place, and will persist for a day or so. Then all of that will stop for days or even a week or two. Then it'll all start back up again. Given the # of different IPs you see trying to brute force, and the fact that the whole event turns off / turns on all at once, I suspect there it is botnet related.
Those messages get annoying when it is happening. I usually just firewall the 20-30 IPs. Of course, as new IPs join in down the road, eventually you have added a lot of IPs just to stop yourself from getting those notices. That's really not the way to go.
I just decided I would set up a message rule that dumps those specific warnings into a special folder. i continue to get the notices, and I check on them occasionally, but I really don't care about failed attempts at smtp auth as a general rule. And I don't want to add tons of IPs to the firewall, especially when they aren't always actively trying to brute force.
192.168.2.33 is characteristic of a certain infected bunch of client machines trying to brute force you, likely all commanded by one source. Although 192.168.2.33 could indeed be a valid address of some machine who is having trouble authing, 9999 times out of 100000 it won't be and instead would be indicative of what I refer to as the botnet-related smtp auth brute forcing.
M
Those messages get annoying when it is happening. I usually just firewall the 20-30 IPs. Of course, as new IPs join in down the road, eventually you have added a lot of IPs just to stop yourself from getting those notices. That's really not the way to go.
I just decided I would set up a message rule that dumps those specific warnings into a special folder. i continue to get the notices, and I check on them occasionally, but I really don't care about failed attempts at smtp auth as a general rule. And I don't want to add tons of IPs to the firewall, especially when they aren't always actively trying to brute force.
192.168.2.33 is characteristic of a certain infected bunch of client machines trying to brute force you, likely all commanded by one source. Although 192.168.2.33 could indeed be a valid address of some machine who is having trouble authing, 9999 times out of 100000 it won't be and instead would be indicative of what I refer to as the botnet-related smtp auth brute forcing.
M