Today we made two changes to the customer dashboard the first enables you to download your custom rules for backup, editing or to take to another IP processing company. We've also enabled the ability to upload your own rules in JSON format which makes it possible to create your own rule generator or easily move your rules from the different accounts you may have with us.

You'll find two new buttons within the global control interface on the custom rules tab of the dashboard just like in the screenshot above.

The second change we've made is to do with the stats tab where we've added a new section to view tag statistics as shown in the screenshot below.

This feature has often been requested and we're happy to be able to add it to the dashboard today. It essentially allows you to see how often your tags result in a positive detection with a breakdown showing the types of detections that it triggered.

So that's it for this update, we hope everyone is having a great weekend!

Today we've released a significant update to our post-processing inference engine which should greatly increase its detection time of bad addresses. The post-processing inference engine is the part of our service that stores addresses we don't think are proxies in a temporary cache so that more data can be accumulated and more processing power can be used to determine if the addresses are in-fact bad.

The new changes today allow the engine to be a lot more aggressive on when it starts making determinations. Prior to today we would convert IP Addresses into one-way hashes (similar to how we hash passwords) and then only make a determination on whether those hashes are proxies or not after we had gathered 8 hours worth of data.

This meant that if an IP was going on a rampage, such as registering on lots of websites, brute forcing passwords and so forth it's likely we would not detect it as a bad address until its 8th hour in operation. For some IP's you really do need this amount of time to get a full picture of its intent as we do not have a complete overview of the entire internet, we only see a small slice.

But for other addresses it becomes obvious in mere seconds that they are bad. And so that is why we've re-engineered our post-processing engine to be a lot more aggressive in when it begins to make determinations. Now it will constantly re-evaluate them based on the actions it's seeing them perform in near real-time allowing us to go from first sight to determination in seconds instead of hours.

Already we're seeing an uplift in detection rate for the worst addresses attacking our customers and honeypots. As our customer base continues to grow, the speed at which attacks are correlated will increase resulting in even faster determinations. Essentially the more our customers and honeypots receive attacks the faster we can identify those bad addresses causing those attacks and share our determinations through our API.

In addition to these changes we've also updated our machine learning model and the inference engine can now hold hashed addresses for a much longer period of time if it feels that's warranted which allows for more data accumulation. This should increase the overall detection rate over our previous model due to it now being able to gather much more evidence.

Thanks for reading this update and we hope everyone is having a great week.

That title sure is a mouthful and I'm sure you're scratching your head right now just trying to decipher it! - Hopefully after reading this post you'll have an understanding of exactly what this new feature is. (The Custom Rule documentation has been updated here if you just want to read that instead).

When we added the Custom Rules feature late last month we listed one of its main features as being able to customise the output of our API. Meaning you can provide some values that will be shown in the API result if your rule conditions are satisfied.

For example if you wanted to add an extra field to the API with some text you could do that. But we didn't at that time provide variables which is where you could include some data from the API in your customised fields. Today that changes with the introduction of variables. And we think we've accomplished this in a really simple to understand way.

Put simply we have a list of 14 variables such as %IP%, %COUNTRY%, %ASN% and %TAG% which you can include in your custom output value boxes when you create rules. When the API sees these variable names it will replace them with the data the variable name is for.

So if you use %COUNTRY% and check an IP for Spain that variable will be swapped out with the word Spain. Pretty simple right? - So why are we doing this. Well it's so you can further customise the output of our API to suit your needs and do some clever stuff.

For instance if you wanted to add content to a custom tag you've provided with a query you can do that by writing your new message and then including the %TAG% variable at the end. That will essentially add your custom information to the start of the tag because while you're overwriting the old tag you're also including a copy of it in the new tag.

So if you had a custom rule called "Block Russia" which always detects Russian IP's as proxies and your tags are all like this: "example.com/myblog/login.php" and you wanted to note that in the tag this IP was detected as a proxy because of a custom rule you could supply a custom value like this: "Activated by Rule: %RULENAME%, %TAG%" which would output: "Activated by Rule: Block Russia, example.com/myblog/login.php".

And that would then appear in your positive detection log within your dashboard on our website allowing you to very simply track when a rule was acted upon that resulted in a positive detection as opposed to an organic result that wasn't caused by your rule.

So you can see the power that variables provide and we know you'll find them useful as we're using the custom rules feature ourselves on our own personal websites, forums and blogs and much of the new functionality such as replacing tag content and adding output variables are a direct result of us using our own product. With that said we're still in full custom rule development so keep checking back for more updates!

Thanks for reading and have a great weekend.

Today we've released a new version of our customer dashboard which spruces up the interface a little bit and adds a more secure way to pay by card and also a new method of paying entirely that doesn't use your card.

So firstly you may notice we've switched up our icons from the previous thin line design to a new dual-tone design which is a bit more modern. We've also made this change to our feature section within our pricing page. We think these new icons look really fantastic, they were done by the FontAwesome.io team of which we are a happy patron.

Secondly maybe not so obvious is we've added some more animations to the dashboard. The invoices section for instance now smoothly slides out as does the positive log filter. We also corrected some inconsistencies with the UI with regards to margins, button animations and styling. These are all very subtle changes that you may not notice but the overall quality improvement will be felt.

We've also had customers tell us that after being subscribed for a long time the invoice section was getting a bit cluttered so we're making some changes there, we're now only showing invoices for your current or most recently held subscription and by default the invoices will be hidden instead of exposed. You can of course always ask support for a past invoice, they're not lost and we always email you a link to your invoices when we charge you, those links will always remain functional.

So let's get to the big change, the new payment gateway. Since we started charging money for our API we have been using Stripe as our payment partner. They've been terrific and we really love using their service. Recently they announced a new version of their checkout product which moves the payment interface from the website you're paying on (proxycheck.io for instance) to Stripes own website.

This has a major advantage in that whilst we always protected your payment information by opening a secure frame to Stripe (and thus we never saw or handled your card information) there was always the chance that the payment page on our own website could be replaced with a malicious one that contains a payment window which looks identical to Stripes and users wouldn't be able to tell the difference.

That is no longer an issue with the new checkout page which is completely hosted on Stripes own website. And it's just as easy as before, you pick the plan you want and click the Subscribe button you're then transferred to Stripe, enter your payment information and then you're transferred back to us for your plan to be processed.

The new checkout also has some enhancements that were not possible on the previous checkout. For example, it supports SCA which is a new secure initiative coming in September where all payments originating within the European Union will require the card owner to authenticate using their mobile device. We welcome this higher level of authentication as it will significantly reduce fraud for both card owners and merchants like ourselves.

But that's not all, with the new checkout we also gain support for new payment methods. As of today we now support Apple Pay which means you can use Safari on your Mac, iPhone or iPad to setup a subscription and in the near future we will also be adding support for Google Pay, Microsoft Pay, iDEAL, Sepa Debit and even more payment methods through the new Stripe hosted checkout page.

So that's all the updates to the Dashboard for today. We still have a lot of things on our roadmap yet to come so keep checking back!

This is just a quick update to let you know we've added preliminary Custom Rules documentation to our API Documentation page which you can visit through this link.

We will be updating this documentation over the coming weeks and months as it was our original intention to provide a more interactive way to show you how to use the feature instead of just telling you how it works.

But we've put this up earlier than planned because we have been inundated with questions about the feature and it became clear to us that making any documentation available is better than nothing and we can come back and update the documentation with something more interactive at a later date.

So thats it for this update, we hope everyone is having a great weekend.

When we released the new Custom Rules feature on July 17th we asked you all to try it out and give us any feedback you may have. And to our surprise a great deal of you have created rules that remain active as of this post indicating you've found the feature useful.

Whenever we make a big feature like this we always wonder exactly how many customers will make use of it and it's not like you all visit our website every day to find out what we're doing so to have so many of you use the feature and so soon after its unveil has been quite surprising.

And with that surprisingly high usage has come a lot of feedback. In-fact we probably received more feedback since launch about this feature than any other. It has been made clear to us that you all love being able to create an unlimited amount of conditions and outputs within each rule. Making that unlimited was the right way to go and we've received a lot of praise for that.

You've also made it clear you want more conditions which is why today we've introduced Latitude, Longitude and Port Number condition targets. The first two new conditions will allow you to create complex geofenced rules by utilising the Latitude and Longitude data we provide within ranges you specify.

Another piece of feedback we received was that you would like some kind of library with pre-made rules for common situations so that you can browse and save a rule to your dashboard which you can use as-is or edit to fit your specific need. We do intend to make this and in-fact it was brought up during the initial development stages.

The final piece of feedback we received is you would like to see documentation for this feature. Some of the condition values you can provide are not obvious and while we have enhanced the status messages that appear to be more descriptive since the launch we agree with you that a full page piece of documentation in the same style as our API Documentation page is necessary. We will be working on this.

So that's your first update to the rules feature. We're of course still accepting feedback for this and all other features so please get in touch with your ideas, we love to hear them.

Thanks for reading and have a great week!

Today is a day I've been looking forward to for a very long time because today I get to share with you all our new custom rule system. This is a new dashboard feature that puts you in complete control of how the API responds to your queries with an unparalleled level of customisation.

This feature has been on our long term roadmap for as long as I can remember. It required lots of planning, experimenting and testing, we wrote the feature several different times from scratch until we nailed it.

We know it's going to be a big deal for our customers because you've been telling us so every month for the past two years. You may not have specifically said the words "I want custom rules!" but you definitely said "Can the API respond this way if x and y happens?". Every month we're asked to add more flags to the API that allow specific use cases.

The two most common requests we receive are. Can you add an easy way to do Country blocking on the API side and what if I only want to block the really bad VPN's and not okay ones? - Well with the new custom rules feature you can accomplish both of these things and a whole lot more.

And that's because not only can you alter the logic of the API but you can overwrite responses with your own ones or create entirely new custom fields containing the strings you specify.

So that's enough talking, let's show it to you. Below is an animation showing the global controls for your rules. The extra control buttons you need only appear when you have rules created and they disappear when you don't. We feel this makes the interface more approachable, less intimidating.

When clicking on the add a rule button a new rule will be added to the page. Below we've added a rule and expanded it to reveal all the configurable options. We've also populated it with three conditions and a single output modifier. Each rule you create can have as many conditions and output modifiers as you like. And we also allow you to specify multiple values for a single condition, more on that in a bit.

In the screenshot above hopefully you can identify what this rule will accomplish just by looking at it. But essentially if you send an IP to be tested and it's a VPN but its risk score is below 67 then with this rule enabled the API will output Proxy: No. Normally in this situation it would output Proxy: Yes.

Which means this rule has enabled you to only block VPN's which we consider dangerous by utilising our risk score. Now you could create logic like this in your own client software that talks to our API. But most of our customers are not computer programmers and are instead utilising plugins and client software which may not take advantage of all our API responses or the developer of their software may have locked-in how the software reacts to most API responses and that may not suit your particular use case.

By moving this logic to the API side with custom rules it enables you to use even the most basic clients available that support our API and still make full use of all current and future features.

The UI we've designed for custom rules goes beyond just looking nice. It's highly functional with instant feedback letting you know if a condition or output modifier you've entered won't work. It can automatically disable rules if the rule isn't valid and let you know which part of a rule needs to be changed before it can be enabled.

We've also made it so you can drag and drop rules around enabling you to adjust the order in which rules are acted upon without the need to erase a rule just because it's in the wrong position.

Now you're probably thinking, great now the Whitelist and Blacklist features are going away. Well don't worry, that's not happening. We love those features and it makes it really easy for customers to do simple actions based on IP Addresses, IP Ranges and AS numbers. And in-fact the new rule system works fully in conjunction with those features, you can even make rules based on the result of those lists.

So this all sounds great right - but what does it cost! - I hear you saying. Well we're not charging extra for rules. Instead we're giving you a quantity of rules based on your current plan sizes. Customers on our free plan can enable three rules while our starter paid plan of $1.99 can enable six rules. Each plan can enable an additional three rules over the previous plan.

And to be clear, we're saying enable because all accounts regardless of plan size can create an unlimited amount of rules. You just can't enable more than your plan size allows. So you can create a lot of different rules for testing and see what works for you by toggling different rules on and off without needing to delete one rule to create another.

Each rule you create can have an unlimited amount of conditions and output modifiers and as I mentioned previously you can provide multiple values for each condition within a single rule, this is done by separating them by a comma. This means if you wanted to create a rule that applied to 20 different countries you could do that by simply listing 20 countries as a single value in a single condition. You do not need to create 20 different conditions or 20 different rules to accomplish that.

So that is the new custom rules feature. It's live right now for all customers within the dashboard and we would love to hear your feedback. The last thing to mention is this feature only works on our v2 API so if you've not made the switch from the v1 API now is the perfect time to do so!

Thanks for reading and have a great week.

Today proxycheck.io suffered what we believe to be our first total service outage and it was caused by Cloudflare, our Content Delivery Network (CDN) partner.

The outage did not only affect us but every single website that uses Cloudflare. This means around 1/3rd of all websites worldwide were affected too. That is an unfathomable amount but it is how many websites trust and use Cloudflare.

This outage lasted 27 minutes and we're incredibly sorry that this happened, unfortunately due to Cloudflare's own website and web based API being affected by the outage we were unable to move our services to a different content delivery network or to expose one of our own servers to the internet directly as a stop-gap measure until their infrastructure started to work correctly again.

This is a highly unusual and unexpected point of failure in our infrastructure design and although we had considered this could happen we deemed the risk so small that we did not put in place a mitigation strategy as Cloudflare is such a professional, large and trusted company which as noted above has 1/3rd of all the worlds websites using them we did not think an outage of this magnitude was likely to ever happen.

Clearly we were wrong about that and we must diversify our entire infrastructure to be resilient against these kinds of failures. We did already build redundancy into every pillar of our own core infrastructure but didn't do so for our CDN which is the last mile so to speak between our servers and our customers, it's also the only piece of our infrastructure that we pay another company to handle solely on our behalf.

We hope that all of our customers can accept our sincere apologies for this outage and that we take full responsibility for it occurring, no one forced us to use Cloudflare, we chose to do so believing they were the best way to bring our product to you and we still do believe that but clearly having no redundancy at the CDN level was a big mistake which we will rectify.

When Cloudflare releases an official statement about this outage we will link it within this blog post.

EDIT [ Cloudflare has now released a blog post here. ]

Thanks.

Over the past month we've released two significant updates to our PHP Library which bring full feature parity with our v2 API and also with our dashboard API's.

This means you can now use all the flags that the v2 API offers including our latest risk score and attack history data as well as view your account statistics, page through your positive detection log and more all with the library.

Here is a full rundown of the changes across our v0.1.3 (May) and v0.1.4 (June) releases.

• Added support for viewing account statistics and positive detections
• Added support for risk scores and attack history
• Added local whitelisting in addition to blacklisting
• Added isocode support to the country white/blacklist features
• Improved error handling when option flags are absent

You can get the latest release (v0.1.4) from packagist.org here or from our github page here. We hope you'll all enjoy the library, we are accepting feature requests for it. Local country whitelisting support was one such customer request.

Thanks and have a great week.

Today we've released an update to the v2 API which brings our vast attack history to the API so that you can finely tune your custom security model using our attack data.

We thought about introducing this with a new flag but we felt it fit best with our risk flag. So instead of supplying &risk=1 and only receiving a risk score you can now supply &risk=2 and receive both a risk score and detailed attack information. Below is an example of how this data looks in the API.

{
    "status": "ok",
    "node": "RHEA",
    "51.38.22.253": {
        "asn": "AS16276",
        "provider": "OVH SAS",
        "country": "France",
        "latitude": 48.8582,
        "longitude": 2.3387,
        "isocode": "FR",
        "proxy": "yes",
        "type": "Compromised Server",
        "risk": 100,
        "attack history": {
            "Total": 28594,
            "Vulnerability Probing": 28594
        },
        "last seen human": "1 hour, 19 minutes, 17 seconds ago",
        "last seen unix": "1560942310"
    },
    "query time": "0.02s"
}

As you can see there is a new section directly under the risk score which shows attack history. At the very top we're listing the total amount of attacks we've seen from this IP Address and then directly below we categorise each type of attack and display those counts. In this section you may encounter Login Attempt, Registration Attempt, Comment Spam or like in the example above Vulnerability Probing. We've detailed these and other response types on the API Documentation page under the risk score section.

These attack histories do not only display for detected proxies and VPN's. You could for example receive some attack history for an IP that we believe to be clean although if the attacks accumulate it will likely be displayed as a compromised server like the entry above which is a real reply from our API.

We've had a lot of requests from users over the past few months to add this data to the API and it was important to us that we did it in a way that won't impact service performance. This kind of data retrieval requires us to load information from our slowest storage medium where as most of our other data lives in fast server memory.

But we think we've come up with a good starting point. For an IP Address with a lot of attack history (such as the one above showing 28,594 attacks) we're seeing around a 0.02s query time. But for the vast majority of the IP Addresses out there you won't see any increase because the IP's either haven't generated any attack data or the attack volume is very small.

We hope you will take good advantage of the new attack data, we know some of you have gone to great lengths to try and obtain it, even going so far as to crawl our threat pages. Thankfully you won't have to do that anymore and the API version of this feature will provide a much wider range of data as it's not limited to 10 unique entries like our threat page attack history display is currently.

Thanks for reading and we hope everyone has a great week.