This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Preventing Brute Force Attacks!!!!!

Is it possible to ban an IP addresses after X number of unsuccessful login attempts to a Windows XP Sp2 which is our SFTP server? Not to a particular account, which I know how to do, but to the whole machine. Or how to block ICMP request on external IP which use NAT to our internal network. 

We get hit pretty hard by brute force attacks trying to guess usernames and passwords, so this would really help get some load of the server. Does anyone know how to block these attacks? btw we have Astaro security gateway 320 V7. We have blocked the ICMP off the server but need to find a way to block those false IP addresses attempting to connect with different users and passwords. Please advice/help will be appreciate!! 

Thank you,


This thread was automatically locked due to age.
Parents
  • Hi, Sham, and welcome to the User BB!

    Interesting question.  My guess is that this needs to be handled with a function of the SFTP server, as it is the only entity that knows of the login failures.

    In some cases, you might want to upgrade to Astaro V8 so that you can do 'Country Blocking' (there are many other good reasons to upgrade!).

    In many cases, you can just block a few /24 networks:

    - Create a 'Network Group' "Public Addresses" containg the "(Address)" objects for all 'Additional Addresses' and the primary IPs of all external interfaces.  You must use these objects, and not manually-created 'Host' or 'Network' definitions.
    - Create a group "Hackers" containing the offending networks.
    - Create a 'Packet Filter' rule: 'Hackers -> Any -> Public Addresses : Drop'.



    Let us know what you do to solve this issue.

    Cheers -  Bob
    PS Oh, I just internalized the fact that you're using a DNAT for the traffic.  I think the Packet Filter rule wouldn't be recognized.  There are two other possible solutions:

    -Instead you could make a DNAT above your DNAT for the SFTP server: 'Hackers -> {SFTP services} -> Public Addresses : DNAT to {non-existent internal IP}.

    -Instead of the new DNAT, you use not the 'Automatic Firewall rule' in the DNAT for SFTP, and, instead, use Packet Filter rules with 'Hackers -> Any -> Any : Drop' above 'Internet -> {SFTP services} -> {SFTP server} : Allow'.

  • - Create a 'Network Group' "Public Addresses" containg the "(Address)" objects for all 'Additional Addresses' and the primary IPs of all external interfaces.  You must use these objects, and not manually-created 'Host' or 'Network' definitions.
    - Create a group "Hackers" containing the offending networks.
    - Create a 'Packet Filter' rule: 'Hackers -> Any -> Public Addresses : Drop'.



    Let us know what you do to solve this issue.

    Cheers -  Bob
    PS Oh, I just internalized the fact that you're using a DNAT for the traffic.  I think the Packet Filter rule wouldn't be recognized.  There are two other possible solutions:

    -Instead you could make a DNAT above your DNAT for the SFTP server: 'Hackers -> {SFTP services} -> Public Addresses : DNAT to {non-existent internal IP}.

    -Instead of the new DNAT, you use not the 'Automatic Firewall rule' in the DNAT for SFTP, and, instead, use Packet Filter rules with 'Hackers -> Any -> Any : Drop' above 'Internet -> {SFTP services} -> {SFTP server} : Allow'.



    Hi Bob,

    This seems overly complicated.
    As long as one is not using the "auto packetfilter rule" on the DNAT, then network definitions/groups, and a DROP PacketFilter rule BEFORE the ALLOW rule would suffice.

    Barry
Reply

  • - Create a 'Network Group' "Public Addresses" containg the "(Address)" objects for all 'Additional Addresses' and the primary IPs of all external interfaces.  You must use these objects, and not manually-created 'Host' or 'Network' definitions.
    - Create a group "Hackers" containing the offending networks.
    - Create a 'Packet Filter' rule: 'Hackers -> Any -> Public Addresses : Drop'.



    Let us know what you do to solve this issue.

    Cheers -  Bob
    PS Oh, I just internalized the fact that you're using a DNAT for the traffic.  I think the Packet Filter rule wouldn't be recognized.  There are two other possible solutions:

    -Instead you could make a DNAT above your DNAT for the SFTP server: 'Hackers -> {SFTP services} -> Public Addresses : DNAT to {non-existent internal IP}.

    -Instead of the new DNAT, you use not the 'Automatic Firewall rule' in the DNAT for SFTP, and, instead, use Packet Filter rules with 'Hackers -> Any -> Any : Drop' above 'Internet -> {SFTP services} -> {SFTP server} : Allow'.



    Hi Bob,

    This seems overly complicated.
    As long as one is not using the "auto packetfilter rule" on the DNAT, then network definitions/groups, and a DROP PacketFilter rule BEFORE the ALLOW rule would suffice.

    Barry
Children
No Data