Hello,
We are having some corporate customers getting blocked because of multiple drop events from the same source.
Some hosts within their networks connect to various ports that are not in use and we are asking customers to review their networks and possibly not connect to our servers on unused ports. We are reluctant to simply whitelist the IP-Addresses.
However, it is very difficult to locate the origin of these requests they are repeatedly getting blocked.
So my question:
How do others handle these situations? Are there any recommendations? Do you simply whitelist such customers?
Or do you modify the rule to simply keep dropping the packets but not block the IP?
Since these requests generally originate from within Switzerland, our home country, is it possible to whitelist a country? Although this does also not feel right, I must say.
Any input is greatly appreciated.
Kind regards
-Stephan
Networks get blocked / multi. drop / best practices?
-
- Forum User
- Posts: 71
- Joined: Mon May 07, 2012 9:37 am
- Location: Zurich
Re: Networks get blocked / multi. drop / best practices?
As it is a corporate customer with a known static IP, whitelisting them is relatively low risk - but as you point out, not ideal.
I would not whitelist a country! We get all sorts of attacks from "local" IPs.
On the other hand, since the customer is connecting to ports that they should not be, the responsibility is theirs to resolve the issue. It is down to how you explain it to the customer really ..
If they do not have the in-house IT experience to prevent it, they do not have the in-house IT experience to keep their network safe, and it becomes a potential threat and therefore whitelisting it is less acceptable.
We have a customer who has a mailserver that still has accounts set up that no longer exist in their account with us. This would normally get them blacklisted. They have no idea how to prevent this/remove the accounts. At the moment I whitelist their IP (as I say, not ideal), but I have told them they need to deal with the issue by such and such a date or their IP will be blacklisted. That gives them tine enough to get someone in to deal with the issue.
If they have not dealt with it I WILL remove their IP from the whitelist and they will be blacklisted. When they call to complain, I will tell them I can whitelist their IP for another week, but that's it.
Of course if they are paying you thousands of euros every month or year then you can adjust as required. But by giving them a notice period, they know when they have to do something and what they need to do.
Of course if it is really complicated, like some obscure system that can't be modified, whitelisting them is the only option if you want to keep them.
Another option is to set up an "insecure" system dedicated to these insecure customers. We did this for a while. We told the customers that we were doing so, and what the consequences were going to be if something went wrong, not just on their account but potentially on the accounts of other customers as well. i.e. total loss of data, data theft, eavesdropping, website compromise etc etc etc and no SLA at all.
I would not whitelist a country! We get all sorts of attacks from "local" IPs.
On the other hand, since the customer is connecting to ports that they should not be, the responsibility is theirs to resolve the issue. It is down to how you explain it to the customer really ..
If they do not have the in-house IT experience to prevent it, they do not have the in-house IT experience to keep their network safe, and it becomes a potential threat and therefore whitelisting it is less acceptable.
We have a customer who has a mailserver that still has accounts set up that no longer exist in their account with us. This would normally get them blacklisted. They have no idea how to prevent this/remove the accounts. At the moment I whitelist their IP (as I say, not ideal), but I have told them they need to deal with the issue by such and such a date or their IP will be blacklisted. That gives them tine enough to get someone in to deal with the issue.
If they have not dealt with it I WILL remove their IP from the whitelist and they will be blacklisted. When they call to complain, I will tell them I can whitelist their IP for another week, but that's it.
Of course if they are paying you thousands of euros every month or year then you can adjust as required. But by giving them a notice period, they know when they have to do something and what they need to do.
Of course if it is really complicated, like some obscure system that can't be modified, whitelisting them is the only option if you want to keep them.
Another option is to set up an "insecure" system dedicated to these insecure customers. We did this for a while. We told the customers that we were doing so, and what the consequences were going to be if something went wrong, not just on their account but potentially on the accounts of other customers as well. i.e. total loss of data, data theft, eavesdropping, website compromise etc etc etc and no SLA at all.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
-
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Re: Networks get blocked / multi. drop / best practices?
Its probably a much more common condition out there than we're giving it credit for, off the top of my head a method might be an extension to not log that type of connection from specific ranges. Its not perfect, since if you're getting say port 1433/139 connections from those ranges those are indicative of something malicious (those are mssql and netbios connections respectively) piled on with the ones that arent.
-
- Forum User
- Posts: 71
- Joined: Mon May 07, 2012 9:37 am
- Location: Zurich
Re: Networks get blocked / multi. drop / best practices?
Thank you very much for the elaborate answer! That gives me some food for thought.
Kind regards
-Stephan
Kind regards
-Stephan