Brute force attacks 192.168.2.33 reject from exim.conf how to?

jonn

jonn

Verified User
Joined
Mar 29, 2009
Messages
107
Location
Queensland, Australia.
the server is getting hammered all day for weeks by multiple ip's with the noticeable 192.168.2.33 ip along side each.
Probably been seen before, though here is the example of one anyway.

Code: 
1356232501000978.188.150.50anna1exim12012-12-23  04:14:37 login authenticator failed for ([192.168.2.33])  [78.188.150.50]: 535 Incorrect authentication data (set_id=anna)
I'm wondering is it okay to use exim to block sender_helo_name 192.168.2.33 to identify as a bad bot and reject. Or is that a bad idea.
I assuming I would add the ip to /etc/virtual/bad_sender_hosts_ip

Cheers beers.
 
Don't worry about replying to the post above, didn't make a difference.
I am now trying via firewall on temp blocking to see what happens over the next week.
Must be a way to stop this F word.


Cheers beers.
 
okay so I have managed to stop the bot in its tracks for now.
removed firewall ips because that was pointless exercise anyway, obviously all spoofed ip's.
this is a new bot that seems to bypass firewall detection rules.
opened exim.conf and added a line under acl_check_helo: under the first {match...} \
Code: 
{match{$sender_helo_name}{192.168.2.33}} \

works a treat ... will keep a watch and report.

cheers beers..
 
Hello,

This block is used as private address space. Why are you seeing the IP on your server? Isn't the IP faked?
 
I got the same problem. 192.168.2.33.

Can someone explain if the above method is a good practice? Datacenter told me it wouldn't be possible to block a private IP.

Another blogger suggest this

I'd appreciate if someone can tell me which method is better.
 
Last edited:
The reason you can't block it with a firewall if it's the same as the example in your link isn't because it's a private IP#; it's because the packets aren't coming from the private IP#; they're coming from a routable IP# (which you can block) and the private IP# is only in the helo part of the smtp connection. You can set an ACL (it may be a default or once have been a default) to block helo with any IP#, or with specific IP#, and in fact I'd see that as best practice.

Code: 
1356232501000978.188.150.50anna1exim12012-12-23  04:14:37 login authenticator failed for ([192.168.2.33])  [78.188.150.50]: 535 Incorrect authentication data (set_id=anna)
Click to expand...
The IP# in the parenthesis is simply the identifier for the helo, the IP# in the brackets is the actual IP# sending the message.

Jeff
 
It's possible add to exim.conf SpamBlocker.exim.conf.2.0-release ?

There is a way to add this solution to - SpamBlocker.exim.conf.2.0-release


Thanks
Sal
 
I have the old SpamBlocker.exim.conf.2.0-release that have not the line acl_check_helo:
my question was, there is a way to add also in the old SpamBlocker.exim.conf.2.0 the ACL to reject attack from 192.168.2.33 ?

Sal
 
You can create new ACLs if you want; you just need to be sure you create them in the right order and using the correct code and syntax.

Probably easier to convert to the new version.

Jeff
 
My exim version is 4.67 , if I update SpamBlocker.exim.conf.2.0 to SpamBlocker.exim.conf.4.1, I have to replace also the exim.pl?

Thanks for your help,
Sal
 
I still can't figure out how to add that solution to exim.conf

From the blog post I mentioned above, I have added the following to exim.conf but now exim panic log states "option "acl_smtp_helo" unknown"

What am I doing wrong here?

acl_smtp_helo = acl_smtp_helo
drop
condition = ${if match{$sender_helo_name}{192.168.2.33}}
message = "REJECTED - Bad Bad Bot"

accept
Click to expand...
 
benzema said:
Can someone explain if the above method is a good practice? Datacenter told me it wouldn't be possible to block a private IP.
Click to expand...

Why not? Are they a part of routing table?

From the blog post I mentioned above, I have added the following to exim.conf but now exim panic log states "option "acl_smtp_helo" unknown"
Click to expand...

SpamBlocker 4.1 has already that acl, just update the section:

Code: 
#EDIT#25:
acl_check_helo:
  # accept mail originating on this server unconditionally
  accept  hosts = @[] : @
  # deny if the HELO pretends to be this host
    deny message = Bad HELO - Host impersonating hostname [$sender_helo_name] 
      condition = ${if or { \
                            {match{$sender_helo_name}{$smtp_active_hostname}} \
                            {eq{$sender_helo_name}{[$interface_address]}} \
                          } {true}{false} }
  # deny if the HELO is an IP address
    deny message = HELO is an IP address (See RFC2821 4.1.3)
         condition   = ${if isip{$sender_helo_name}}
  # deny if the HELO pretends to be one of the domains hosted on the server
    deny message = Bad HELO - Host impersonating domain name [$sender_helo_name]
        condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
        hosts = ! +relay_hosts
  accept
 
Thanks. It turns out I don't have that version of spamblocker. I guess I better update.

zEitEr said:
Why not? Are they a part of routing table?



SpamBlocker 4.1 has already that acl, just update the section:

Code: 
#EDIT#25:
acl_check_helo:
  # accept mail originating on this server unconditionally
  accept  hosts = @[] : @
  # deny if the HELO pretends to be this host
    deny message = Bad HELO - Host impersonating hostname [$sender_helo_name] 
      condition = ${if or { \
                            {match{$sender_helo_name}{$smtp_active_hostname}} \
                            {eq{$sender_helo_name}{[$interface_address]}} \
                          } {true}{false} }
  # deny if the HELO is an IP address
    deny message = HELO is an IP address (See RFC2821 4.1.3)
         condition   = ${if isip{$sender_helo_name}}
  # deny if the HELO pretends to be one of the domains hosted on the server
    deny message = Bad HELO - Host impersonating domain name [$sender_helo_name]
        condition = ${if match_domain{$sender_helo_name}{+local_domains}{true}{false}}
        hosts = ! +relay_hosts
  accept
Click to expand...
 
Hi again,

So I have updated the exim.conf file and edited the hole check part accordingly.

Is there any way to check if it's blocking 192.168.2.33 ?
 
I have a doubt, there is someone that may help me?
If I update the exim.conf from 2.0 to 4.1 I have to change also the exim.pl?
My exim version 4.67

Thanks
Sal
 
For most functionality you should always use the latest version of exim.pl, and indeed the most recent version of exim supported by CustomBuild.

Jeff
 
benzema said:
Hi again,

So I have updated the exim.conf file and edited the hole check part accordingly.

Is there any way to check if it's blocking 192.168.2.33 ?
Click to expand...

As a follow up, I can confirm that the above method worked. Thanks to everyone who assisted.
 
You must log in or register to reply here.
Back
Top