Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Alpha-assisted rogue IP blocker - feedback

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Alpha-assisted rogue IP blocker - feedback

    I've been working on a homegrown solution to block attacks on my server. There are probably easier ways, but I wanted to try something out. Please watch the video and comment if you can.

    Video: https://www.screencast.com/t/rcVxfNtWKy
    Steve Wood
    See my profile on IADN


    #2
    Re: Alpha-assisted rogue IP blocker - feedback

    My initial thought would be if the hacker were running his scan from public places and/or through any shared proxy and/or NAT'ed IPs used by others also or just spoofing IP's used by larger populations... well, you would be blocking a lot of innocent users from ever going to your site.

    Maybe finding a free Web Application Firewall (WAF) would be just enough so that you could do the Level 7 type parsing of requests for .php and such. Or a small web server set up as a reverse proxy / load balancer that only allows traffic for .a5w pages and such to your Alpha server. For the unwanted calls, just drop the request at that level instead of making your Alpha server do all that work.

    Comment


      #3
      Re: Alpha-assisted rogue IP blocker - feedback

      Ha, sound advice. My own load balancer (level 7) does allow for those rules so I will investigate. It is interesting though to review what goes on, who attacks and the nature of the attack. My website domains have been around for a decade and so they are constantly hit.

      For those reading, the load balancer sits in front of Alpha web server so blocked traffic would never hit the web server. Alpha does have its own abilty to block by IP address BUT those still hit the Alpha server but are blocked from continuing on to the application so they still affect performance.
      Steve Wood
      See my profile on IADN

      Comment


        #4
        Re: Alpha-assisted rogue IP blocker - feedback

        Not to mention if any of my friends here tried IADN.COM and included .php somewhere in the browser address it would block their IP address (hint, try it).
        Steve Wood
        See my profile on IADN

        Comment


          #5
          Re: Alpha-assisted rogue IP blocker - feedback

          If you want to see the logs and the load balancer ones aren't accessible or very good, send all requests that aren't in the whitelist to a little nodeJS webserver that can probably handle thousands of requests in a few seconds.
          Something like this one for example:
          https://gist.github.com/iamnoah/246761

          Letting bots create app server sessions where each session eats up valuable resources for 20 minutes or so is just too expensive. I'm not sure all requests for unavailable resources all create sessions but I've seen it with JBoss app servers where a bot would create a new session with each request and quickly bring the server to a halt.

          Comment


            #6
            Re: Alpha-assisted rogue IP blocker - feedback

            Steve, you have saved me several times with your knowledge of this issue, most of my applications are for specific client use, little to no real public face, and the user region IP is known for those allowed to access, I found allowing only valid known IP regions a great help in reducing the problem for non public use sites. Thanks to you both for sharing your knowledge.
            Insanity: doing the same thing over and over again and expecting different results.
            Albert Einstein, (attributed)
            US (German-born) physicist (1879 - 1955)

            Comment


              #7
              Re: Alpha-assisted rogue IP blocker - feedback

              how can I block china from my AS web server, or just allow US ips?
              NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

              Comment


                #8
                Re: Alpha-assisted rogue IP blocker - feedback

                Give this a go.. if you like it upgrade.
                https://ip-blocker-firewall.en.softonic.com/
                Insanity: doing the same thing over and over again and expecting different results.
                Albert Einstein, (attributed)
                US (German-born) physicist (1879 - 1955)

                Comment


                  #9
                  Re: Alpha-assisted rogue IP blocker - feedback

                  I think it is normal to have this kind of traffic today in web server. There is no need to block this kind of traffic.

                  The problem here is that WAS is not a web server but an application server.

                  I think it is not wise to run WAS alone. It needs a front end webserver which can handle thousands of requests without loosing performance and also has security skills. Same situation is for example with Adobe ColdFusion server. So for example although ColdFusion Enterprise server version price is over 10 000 it still needs and Adobe recommends using a frontend web server like IIS.

                  So Cloudflare + frontend webserver + Was = no problems

                  Ken

                  Comment


                    #10
                    Re: Alpha-assisted rogue IP blocker - feedback

                    I agree but I still like blocking abuse traffic. All of my traffic goes through a load balancer before it hits the WAS. That utility handles the port 80 to 443 redirect and gives me a better set of Access logs to review. The lb can handle 28K connections per second so I am good there.

                    So it goes Internet --> IP Blocker --> Load Balancer --> Port 80->443 (as needed) --> Alpha WAS Instances
                    Steve Wood
                    See my profile on IADN

                    Comment


                      #11
                      Re: Alpha-assisted rogue IP blocker - feedback

                      I wonder what is the advantage to use application server(xbasic script) to block traffic compared to just left traffic come to server. I am sure that blocking spends more application server resources in practice .

                      Best option is to use CloudFlare(or similar). If your configuration is right done you just protect your domain name myserver.com and nobody knows your physical servers IP address. This has huge impact. And when your domain name is under attack CloudFlare will automatically block attackers traffic to server. It is just impossibly to get same protection level if attacker knows your servers physical IP address.

                      Ken

                      Comment


                        #12
                        Re: Alpha-assisted rogue IP blocker - feedback

                        The app server really should never have a public accessible IP (if the business relying the application is important enough). As long as a app server has a public IP and answers to port scans from anyone (even just scans for 80 and/or 443), a hacker can use tools to scan the billions of public IPs for port 80 in less than 15 minutes. They don't care about domain names.

                        So yes, a product/service like CloudFlare is great as long as you configure it all so that your firewall only lets requests from CloudFlare IPs get to the expensive resources.
                        I had worked with a similar system like that but it was provided by Akamai. We did have to pay Akamai extra though to have a reduced and identifiable range of their IPs that we could whitelist on our firewall. We thought it would be ok to simply update the DNS entries for our domains to point to Akamai and use Akamai as a gateway for all traffic but after a couple of DDoS attacks that directly hit our unadvertised origin IPs we had to take the additional step.

                        And, of course, not all bots that are probing have to be nice about it. As long as they can get through to an app server that creates expensive sessions; they could very well be configured to not send any additional request information allowing the app server to identify them as already having a session. A bot can bring an app server down in minutes by simply sending a thousand separate requests that end up creating a thousand separate sessions.

                        Comment

                        Working...
                        X