Blog

Archive for Firewall

Core-Admin integration for Tor Network tracking, analysis, tagging and blocking

[extoc]

Introduction to Core-Admin tor integration

Tor Network is an anonymizer network infrastructure, opened for everyone for use, that allows users to hide their location (mostly IP) or make it difficult to track (https://www.torproject.org/). As its function implies, it can be used to protect users from abuse and tracking.

However, you might be interested in have additional information about how Tor is used to access your services to implement analysis, apply policy or maybe blocking all traffic that might come from Tor (legitimate or not).

Due to the way Tor Network works, all exit nodes are public and can be downloaded. Combined with some tracking functions, it is possible to know if an IP belongs to Tor Network (as an exit node) or was part of it in the past.

Core-Admin provides an integration option that allows having all this information in an usable form so you can integrate it with your infrastructure:

core-admin-tor-integration

How to enable Tor Network Integration with Core-Admin

For that, open #IpBlocker application as shown:

Selección_336

and then, click to configure:

Selección_337

After that, click to enable Tor Integration as shown:

Selección_353

After enabling it, you will have in your system, an up to database information about Tor Exit-Nodes that are active or were active in the past.

How to use this information about Tor Exit-Nodes with Core-Admin

By enabling this basic integration you have different indications out of the box that can be used. Some of then are the following.

Support to get an indication if a Tor node is detected when checking #IpBlocker tool. That way you will be able to get additional information when checking attacks:

Selección_354

Also, you will also get additional information when requesting for a report about certain ip:

Selección_355

How to integrate Tor Network information provided by Core-Admin with MySQL

To start doing more advanced things, you might be interested in having all this information in a MySQL table (two tables) so you can implement your own queries.

This way, you can not only check, you can also make your application to tag, do quick searches or implement resource policy control and protection.
For example, you might want to deny or allow login if source connection is inside or not Tor Network.

To enable Tor Network integration with MySQL, follow next steps as shown, and input the database were you what the information to be exported and updated. You can configure several MySQL databases.

Core-Admin will keep that MySQL information updated, leaving the rest of the tables untouched. This can be used for empty dedicated MySQL or existing MySQL databases, with working data where a couple of tables will appear and keep updated so your application can access this information using current MySQL API.

Selección_356

How to block Tor Network with Core-Admin

In the case you don’t want any of your services to be available/reachable to any Tor Exit-Node, then use the following option. It will create automatically IP firewall blocking for all exit nodes found. These rules will be updated regularly removing old exit nodes, and adding new active exit nodes.

Selección_357

Command line options to manage Tor Network integration with Core-Admin

There are different options available through crad-ip-blocker.pyc tool. Run the following command to get information about them:

>> crad-ip-blocker.pyc  --help | grep tor
                        also removes old blocking history (retaining last
  --update-tor-exit-nodes-list
  --find-all-tor-access
  --check-tor-ip=IP[,IP2[,IP3]]
                        in tor (active,historic) network or not.
  --export-tor-tracking-to-mysql-db=DBNAME[,DBNAME2[,DBNAME3]]
  --dump-tor-tracking   Allows to dump all tor tracking information current
                        stored.
  --block-active-tor-nodes
                        Allows to block all tor actives nodes currently found.
                        /crad-ip-blocker.pyc --update-tor-exit-nodes-list to
  --unblock-active-tor-nodes
                        active-tor-nodes. Use this option to remove all rules
                        created by --block-active-tor-nodes options.

Something missing or have a doubt? We want to hear your opinion!

Please, if you have a question or a comment, contact us at support@core-admin.com (https://www.core-admin.com/portal/about-us/contact).

Posted in: Blacklist, Firewall, Tor

Leave a Comment (0) →

Integrating with Crad-Log-Watcher to block IPs due login failures for your custom web/server app

[extoc]

In order to integrate your login failures with crad-log-watcher, to have remote IP blocked automatically when some number of login failures are reached, follow the next guide.

Next steps will help you to create a login failure handler that will track and manage login failures for any given application, to block source IP in the case a configurable threshold is reached.

  1. First, you have to make your web or server application to generate a log indication about the IP that is going to be blocked.

    We recommend sending this log to syslog because it is accesible to all system users and requires no special privileges. That will simply next steps. If you decide to send this information to another log, just adapt everything as needed.

    With PHP, generating such log will be:

    // in case of login failure ::
            $remoteAddr = $_SERVER['REMOTE_ADDR'];
            $currentWeb   = $_SERVER['SERVER_NAME'];
            $loginAttempted = // point this variable to the login that was attempted and failed
            syslog (LOG_INFO, "Login failure from [$remoteAddr] access denied to [$currentWeb] with user [$loginAttempted]");
            

    This will make record a log to syslog everytime a login failure happens.
    This change will be required for every web page or server to be protected.

  2. Now, you have to create a custom handler for crad-log-watcher that reads these logs, keep track about login failures and block IPs reaching a threshold:

    For that, create a file called login_failure_handler.py with the following content (adapt as needed):

    #!/usr/bin/python
    
    from core_admin_common import support
    from core_admin_agent  import checker, watcher
    
    # database for tracking login failures
    database_path = "/etc/core-admin/client/my.watcher.sql"
    
    def init ():
    
        # notify this is child for checker notification
        checker.is_child = True
    
        # track and lock login failures
        (status, info) = watcher.create_track_login_failure_tables (database_path)
        if not status:
            return (False, "Unable to create ip_registry table, error was: %s" % info)
    
        return (True, None) # return ok init
    
    def handle_line (line, source_log):
    
        # only process log failures to block
        if "login failure from [" in line.lower () and "access denied to [" in line.lower ():
            
            # assuming log error format:
            # Jul  7 16:15:29 node04-grupodw python: Login failure from [88.99.109.209] access denied to [http://foobar.com] with user [userAccess1]
        
            source_ip_to_block    = line.lower ().split ("login failure from [")[1].split ("]")[0]
            login_failure_because = line.lower ().split ("access denied to [")[1].split ("]")[0]
            user_login            = line.lower ().split ("with user [")[1].split ("]")[0]
    
            # configure notification
            reason                   = "Access failure to %s" % login_failure_because
            fail_logins_before_block = 10
            
            # call to track user and ip
            watcher.track_and_report_login_failure (user_login, source_ip_to_block, reason, database_path, fail_logins_before_block, source_log)
    
        # end if
        
        return
    
  3. Now, place these file into /var/beep/core-admin/client-agent/log-handlers

  4. Now, inside /etc/core-admin/client/log-watcher.d, create a file that links your /var/log/syslog with the handler you have just created. For example, make that file have the following path: /etc/core-admin/client/log-watcher.d/custom-login-failures-blocker

    <log src="/var/log/syslog" handler="login_failure_handler" />
  5. After that, just restart crad-log-watcher to have it loading your login_failure_handler and configuration created with:
    /etc/init.d/crad-log-watcher restart
  6. Supervise crad-log-watcher execution to ensure everything is working with:
    # tail -f /var/log/syslog | grep crad-log-watcher
  7. Now, test your development by causing login failures to protected system. You should see logs created at /var/log/syslog.
    If you do not see login failure logs, it will not work. Review your code to ensure these logs are created.

  8. If login failure logs are created, then run the following command just to show if login failure tracking is happening:

    # sqlite3 -column -header /etc/core-admin/client/syslog.watcher.sql "select * from login_failure"

Have any questions? Contact us at support@core-admin.com (https://www.core-admin.com/portal/about-us/contact).

Posted in: Blacklist, Firewall, Security

Leave a Comment (0) →

Updates — KB: 24032014-001: Dealing with TIME WAIT exhaustion (no more TCP connections)

The KB http://www.core-admin.com/portal/kb-24032014-001-dealing-with-time-wait-exhaustion-no-more-tcp-connections about managing time wait configuration problems reported by time wait checker has been updated to allow configuring TCP TIME WAIT recycle option (/proc/sys/net/ipv4/tcp_tw_recycle). The article also includes additional infomation about how this option relates (and may cause problems) with devices behind NATing firewalls when the server running this option is accessed from there.

The article also includes a reference to Troy Davis’ article http://troy.yort.com/improve-linux-tcp-tw-recycle-man-page-entry/ which explains in more detail how this happens.

Posted in: Administration, Firewall, KB, Security

Leave a Comment (0) →