6

My company's email server is under attack from the following IP address blocks

92.63.193.0 5.188.9.0

Here are the corresponding WHOIS records for each network

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '5.188.9.0 - 5.188.9.255'

% Abuse contact for '5.188.9.0 - 5.188.9.255' is '[email protected]'

inetnum:        5.188.9.0 - 5.188.9.255
netname:        WebShield
descr:          WebShield Network
country:        RU
org:            ORG-WS171-RIPE
admin-c:        KIV106-RIPE
tech-c:         KIV106-RIPE
status:         ASSIGNED PA
mnt-routes:     MNT-HS
mnt-routes:     MNT-NFORCE
mnt-routes:     MNT-PINSUPPORT
mnt-by:         MNT-PINSUPPORT
mnt-by:         MNT-PIN
created:        2018-01-15T23:04:19Z
last-modified:  2018-01-22T02:02:33Z
source:         RIPE

organisation:   ORG-WS171-RIPE
org-name:       Barbarich_Viacheslav_Yuryevich
org-type:       OTHER
address:        Russia
address:        Marks
address:        5-ya liniya, d.17
abuse-c:        ACRO5735-RIPE
admin-c:        BVY17-RIPE
tech-c:         BVY17-RIPE
mnt-ref:        MNT-PIN
mnt-ref:        MNT-PINSUPPORT
mnt-by:         MNT-PINSUPPORT
created:        2017-04-01T16:43:45Z
last-modified:  2018-05-01T21:23:09Z
source:         RIPE # Filtered

person:         Kucharavenka Ihar Valerievich
address:        Lesi Ukrainki, 9
address:        Kiev
address:        Ukraine
phone:          +380 95 5037029
nic-hdl:        KIV106-RIPE
mnt-by:         MNT-PINSUPPORT
created:        2017-03-03T17:13:11Z
last-modified:  2017-10-30T23:40:32Z
source:         RIPE # Filtered

% Information related to '5.188.9.0/24AS43350'

route:          5.188.9.0/24
descr:          NFOrce Entertainment B.V. - Customer 2976
origin:         AS43350
mnt-by:         MNT-NFORCE
created:        2018-01-23T05:46:00Z
last-modified:  2018-01-23T08:17:27Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.91.2 (ANGUS)

And for 92.63.193.0 

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '92.63.193.0 - 92.63.193.255'

% Abuse contact for '92.63.193.0 - 92.63.193.255' is '[email protected]'

inetnum:        92.63.193.0 - 92.63.193.255
netname:        WRDSTR-NET
country:        RU
admin-c:        ACRO15210-RIPE
tech-c:         ACRO15210-RIPE
status:         ASSIGNED PA
mnt-by:         ITDELUXE-MNT
created:        2016-08-15T11:56:43Z
last-modified:  2018-05-21T02:46:56Z
source:         RIPE
mnt-routes:     MNT-WORLDSTREAM
org:            ORG-ISEB1-RIPE
abuse-c:        ACRO15210-RIPE

organisation:   ORG-ISEB1-RIPE
org-name:       IP Starcev Eugenii Borisovich
org-type:       OTHER
address:        443112, Russian Federation, Samara, Sergeya lazo str, office 2
abuse-c:        ACRO15210-RIPE
mnt-ref:        ru-patent-media-1-mnt
mnt-ref:        ITDELUXE-MNT
mnt-by:         ru-patent-media-1-mnt
created:        2018-04-02T06:25:14Z
last-modified:  2018-05-04T11:57:05Z
source:         RIPE # Filtered

role:           Abuse contact role object
address:        443112, Russian Federation, Samara, Sergeya lazo str, office 2
abuse-mailbox:  [email protected]
nic-hdl:        ACRO15210-RIPE
mnt-by:         ru-patent-media-1-mnt
created:        2018-04-02T06:24:01Z
last-modified:  2018-05-04T11:57:27Z
source:         RIPE # Filtered

% Information related to '92.63.193.0/24AS49981'

route:          92.63.193.0/24
origin:         AS49981
mnt-by:         MNT-WORLDSTREAM
created:        2018-05-04T12:00:44Z
last-modified:  2018-05-04T12:00:44Z
source:         RIPE

% This query was served by the RIPE Database Query Service version 1.91.2 (BLAARKOP)

Basically in the log files on our mail server, we are seeing attackers at the two IP ranges listed above attempting to brute force crack several email accounts on our email server. After 5 attempts however, the attacker ends up locking the account out and then the user ends up coming to me to resolve the issue.

I am trying to block those two ranges in my cisco ASA firewall (5510) but I am having some difficulty setting the line numbers in the ASA to allow me to properly block any and all traffic coming from those address blocks.

Here is the evidence that we are being attacked (mail server log file, greped)

2018-05-21 00:00:28,653 INFO  [ImapServer-4610] [ip=5.188.9.185;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:00:56,831 INFO  [ImapServer-4609] [ip=92.63.193.15;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:01:42,382 INFO  [ImapServer-4610] [ip=92.63.193.15;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:02:03,121 INFO  [ImapServer-4609] [ip=5.188.9.175;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:02:06,372 INFO  [ImapServer-4611] [ip=5.188.9.190;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:04:44,422 INFO  [ImapServer-4610] [ip=92.63.193.10;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:04:48,833 INFO  [ImapServer-4611] [ip=5.188.9.165;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:04:50,571 INFO  [ImapServer-4612] [ip=92.63.193.50;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:05:00,122 INFO  [ImapServer-4613] [ip=92.63.193.30;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:05:25,441 INFO  [ImapServer-4613] [ip=92.63.193.45;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:07:18,692 INFO  [ImapServer-4614] [ip=5.188.9.165;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:07:33,221 INFO  [ImapServer-4612] [ip=5.188.9.185;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:07:50,551 INFO  [ImapServer-4611] [ip=92.63.193.15;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:09:06,453 INFO  [ImapServer-4611] [ip=92.63.193.15;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:09:13,611 INFO  [ImapServer-4612] [ip=5.188.9.150;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:09:22,232 INFO  [ImapServer-4614] [ip=5.188.9.190;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:09:47,261 INFO  [ImapServer-4614] [ip=5.188.9.185;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:10:17,533 INFO  [ImapServer-4614] [ip=92.63.193.45;] imap - authentication failed for [[email protected]] (account lockout)
2018-05-21 00:12:35,901 INFO  [ImapServer-4612] [ip=92.63.193.50;] imap - authentication failed for [[email protected]] (account lockout)

Anyways, we are a US based company, and there should not be IP addresses in Russia trying to authenticate to our mail server.

Here is what I attempted to configure on the ASA to get this working:

I created an object-group called BLACKLIST in the Cisco ASA

object-group network BLACKLIST
 description "to block attackers from Russia hitting our mail server"
 network-object 92.63.193.0 255.255.255.0
 network-object 5.188.9.0 255.255.255.0
 network-object 66.114.33.0 255.255.255.0

FYI the 66.114.33.0 network is a friends server that I have shell access to. To test the rules, I ssh into that server and then try to scan my companies mail server's external IP address from there to see what the result of the rules I am adding was. So far, the ACL does not appear to be applied due to where it appears in the list.

Here are the ACL's set in the ASA for the access-list outside_access

access-list outside_access extended permit tcp any host WAN.44 object-group mail 
access-list outside_access extended permit tcp any host WAN.51 eq www 
access-list outside_access extended permit tcp any host WAN.52 eq www 
access-list outside_access extended permit tcp any host WAN.39 object-group web 
access-list outside_access extended permit tcp any host WAN.54 object-group web 
access-list outside_access extended permit tcp any host WAN.38 object-group web 
access-list outside_access extended permit tcp any host WAN.37 object-group web 
access-list outside_access extended permit tcp any host WAN.40 object-group web 
access-list outside_access extended permit tcp host ADT host WAN.43 object-group adt-access 
access-list outside_access extended permit tcp any host WAN.62 eq ssh 
access-list outside_access extended permit tcp any host WAN.41 eq www 
access-list outside_access extended permit tcp any host WAN.50 object-group web 
access-list outside_access extended permit tcp any host WAN.53 eq www 
access-list outside_access extended permit tcp any host WAN.55 object-group web 
access-list outside_access extended permit tcp any host WAN.51 eq 22609 
access-list outside_access extended permit tcp any host WAN.52 eq 22609 
access-list outside_access extended permit tcp any host WAN.36 object-group hvac-tcp 
access-list outside_access extended permit udp any host WAN.36 object-group hvac-udp 
access-list outside_access extended permit tcp any host WAN.56 object-group unitrends-cloud 
access-list outside_access extended permit icmp any interface outside 
access-list outside_access extended permit icmp any host WAN.56 
access-list outside_access extended permit udp host 69.164.156.164 host WAN.56 eq 1322 
access-list outside_access extended permit tcp any host WAN.49 eq ssh 
access-list outside_access extended permit tcp any host WAN.51 object-group ipcam 
access-list outside_access extended permit tcp any host WAN.52 object-group ipcam 
access-list outside_access extended permit tcp any host WAN.45 object-group RDP 
access-list outside_access extended deny ip object-group BLACKLIST any log debugging

See the very top rule in the outside_access ACL? WAN.44 is a name associated with the external IP address of our email server.

The very last line of the outside_access ACL is the rule I added for the object-group BLACKLIST that contains the offending IP addresses

access-list outside_access extended deny ip object-group BLACKLIST any log debugging

Here is the output from show access-list outside_access

RosevilleHQ# show access-list outside_access
access-list outside_access; 54 elements; name hash: 0xee117655
access-list outside_access line 1 extended permit tcp any host WAN.45 object-group mail 0x178b4b24 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq 465 (hitcnt=16) 0x47cf55a9 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq 993 (hitcnt=8) 0x11b2bd68 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq www (hitcnt=212) 0x9fa21b42 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq https (hitcnt=305) 0xc64364b1 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq imap4 (hitcnt=13) 0x0e18a498 
  access-list outside_access line 1 extended permit tcp any host WAN.45 eq smtp (hitcnt=318) 0x92935501 
access-list outside_access line 2 extended permit tcp any host WAN.44 object-group mail 0xebd7e3e5

-- SNIP --

access-list outside_access line 28 extended deny ip object-group BLACKLIST any log debugging interval 300 0xf8cdc515    access-list outside_access line 28 extended deny ip host 66.114.33.57 any log debugging interval 300 (hitcnt=1988) 0x795c4347    access-list outside_access line 28 extended deny ip 92.63.193.0 255.255.255.0 any log debugging interval 300 (hitcnt=227) 0x050b89a6    access-list outside_access line 28 extended deny ip 5.188.9.0 255.255.255.0 any log debugging interval 300 (hitcnt=64) 0xa9f56709    access-list outside_access line 28 extended deny ip 66.114.33.0 255.255.255.0 any log debugging interval 300 (hitcnt=0) 0x3779146b

My question is, how do I move those entries int he ACL up to the top line so they get processed first? Is there something else I am missing? Is there some better way to go about blocking communication from these two blocks?

Improve this question
7
  • There is an implicit deny at the end of every ACL, so adding deny statements to the end really does nothing. The ACL will exit upon a match, so any matching permit before the deny will let the traffic through.
    – Ron Maupin ♦
    May 22, 2018 at 14:37
  • OK, so what is the best approach for blocking all communication from these two blocks of IPs?
    – Richie086
    May 22, 2018 at 14:39
  • 1
    Move your Blacklist rule to the top because right now its doing nothing at the bottom.
    – A-A-Ron
    May 22, 2018 at 14:39
  • How do I do that tho? I tried to move the line up but could not seem to figure it out.
    – Richie086
    May 22, 2018 at 14:42
  • 2
    Use access-list outside_access line 1 extended deny ip object-group BLACKLIST any log, by specifying the line number you are telling the ASA where to insert the line in the ACL, it will then automatically shuffle the rest of your lines down.
    – A-A-Ron
    May 22, 2018 at 14:45

3 Answers 3

Reset to default
4

One way to modify your ACL is to simply create a new one, then apply it to the interface. The advantage of this method is you can quickly revert back if you've made a mistake, and you can see what you have previously done for auditing, etc.:

access-list outside_access_1 extended deny ip object-group BLACKLIST any log debugging
access-list outside_access_1 extended permit tcp any host WAN.44 object-group mail 
access-list outside_access_1 extended permit tcp any host WAN.51 eq www 
access-list outside_access_1 extended permit tcp any host WAN.52 eq www 
access-list outside_access_1 extended permit tcp any host WAN.39 object-group web 
access-list outside_access_1 extended permit tcp any host WAN.54 object-group web 
<etc>

access-group outside_access_1 in interface outside
Improve this answer
4
  • Ron, great idea! How do I go about deactivating my old ACL (access_list)?
    – Richie086
    May 22, 2018 at 14:59
  • just do no commands in front of each entry?
    – Richie086
    May 22, 2018 at 14:59
  • This totally worked btw. I just attempted to connect to my mail server from my friends external linux server and I am no longer able to port scan my external network from the host i specified out on the internet! thank you so much!
    – Richie086
    May 22, 2018 at 15:03
  • if you're certain you don't need the old access list, you can simple delete with "no access-list outside_access"
    – Ron Trunk
    May 22, 2018 at 15:25
2

ACL checks start at the top of the ACL, and they proceed until there is a match, at which point the check will halt. ACLs also have an implicit deny all at the end of the list, so anything not matching a permit in the ACL will be denied.

Your problem is that you are permitting the traffic first, so the ACL test will exit before it gets to they deny. You need to put all your explicit deny statements at the top of the ACL, then all your explicit permit statements. Anything not matching the permit statements will be denied.

Improve this answer
0

What Ron Maupin said about the explicit deny being pointless is wrong. With only the implicit deny, you will only see denied traffic if your logging level (such as via the "logging buffered" command) is set to Debugging or you're using "terminal monitor". If your logging level is anything lower than Debugging (such as Error) you will not see the denied traffic unless you have an explicit deny statement (along with logging enabled on it).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.