[derchris]

After all, they are "unmanaged" servers, so the owner should be responsible for the security of it.
I don't like the idea of filtering it before it hits my server.
Maybe as an addon service for customers who needs it.

[IainK]

If SSH is run on a port other than 22 OVH will not know that it is the SSH service, obviously, however just because they don't know it's SSH doesn't mean it's blocked.
Now if you attempted to open 20 connections to your SSH server in 20 seconds that would be considered a bruteforce and you would probably be banned.

[helpseeker]

is this something "static" or clever?

If (as everybody I hope!) someone runs ssh on a random port does this will work recognizing the protocol or every scan made to that port will be considered a ssh bruteforce?

[Dave]

I agree with Murph, port blocking on a dedicated server which could be running any sorts of configuration using any number of ports for legitimate reasons is not going to go down well.

And iand tell me about it, I get attacked daily from OVH members mainly SSH attempts which I always report but never get confirmation and the attack's don't stop.

[iand]

yes you need to sort your internel network as well as external it seems theres quiet a few virused boxes on the ovh network id say 99% of curent scans on my box hosted by ovh are coming from the internal network

[Murph]

Why don't you block at your perimeter :

137, 139, 445

These are of no use on the public internet.

1025-1029 is more of a danger as GOOD traffic can use these ports, although it is mostly MESSENGER SPAM.

I, for one, don't want any default filtering on my IP traffic, as it's a slippery slope where eventually some well-meaning filter impacts legitimate traffic. I'm much happier managing my own filtering on the server itself - I can both see what is being blocked, and adjust the filtering if there are any issues. Blocking 1025-1029 would be madness - there are protocols which open a dynamically assigned port for incoming connections, and these dynamic ports can be anywhere in the range 1024-65535, depending on the application and the OS. Internet facing servers absolutely do need a firewall/filtering, but it's much better to leave that up to the individual server admins in a diverse environment like OVH.

That said, I'm happy enough with OVH taking efforts to identify specific cases of abuse and temporarily block them, as long as they take great care over it (which they appear to be doing).

[Palad1n]

Why don't you block at your perimeter :

137, 139, 445

These are of no use on the public internet.

1025-1029 is more of a danger as GOOD traffic can use these ports, although it is mostly MESSENGER SPAM.

[Andy]

Good morning,
We went into production Friday the new system
Detection scan. It works on tonneur. So although
the system that was doing the blocking was not enough
effective. We've changed since last night and everything
is a real-time again.

On Saturday, 14, we had 1078 alerts.
On Sunday, 15, 1145 we had alerts.
Today, we are already 416 alerts.

Below are the stats of 14:
number
port
scan scané
-------*-------
2 1026
2 3306
3 10000
6 443
10 80
12 21
55 23
56 22
72 139
217 445
643 135

And 15:
number |
| port
scan | scané
-------*-------
1 | 1026
1 | 3306
3 | 10000
5 | 443
9 | 80
21 | 21
46 | 22
50 | 23
68 | 139
256 | 445
685 | 135


And so the winner is:
------------------------
loc-srv 135/tcp epmap # Arrivals Service
Loc-srv 135/udp epmap
microsoft-ds 445/tcp # Naked Microsoft CIFS
Microsoft-ds 445/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-SSN 139/udp
Telnet 23/tcp
ssh 22/tcp # SSH Remote Login Protocol
SSH 22/udp
FTP 21/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
https 443/tcp # http protocol over TLS / SSL
https 443/udp
webmin 10000/tcp
MySQL 3306/tcp
MySQL 3306/udp


Windows remains the main danger for our network and
level on protege of dynamic way servers hosted by
Ovh against scans on our network.

The type of scan that detects is simple:
-> :
And blocking is very clean
deny host any eq
Thus ip scan which can no longer scan the network Ovh on port
in question. Everything else going on.

Yours
Octave

[oles@ovh.net]

Hello,

On Friday we released a new scan detection system. It works very well. So well that the system that was doing the blocking was not efficient enough. We changed it last night and everything is done in a real-time again.

On Saturday 14th, we had 1078 alerts.
On Sunday, 15th, we had 1145 alerts.
Today, we are already at 416 alerts.

Below are the stats of 14th:
number of scans/ port scanned
-------*-------
2 1026
2 3306
3 10000
6 443
10 80
12 21
55 23
56 22
72 139
217 445
643 135

Below are the stats of 15th:
number of scans/ port scanned
-------*-------
1|1026
1|3306
3|10000
5|443
9|80
21|21
46|22
50|23
68|139
256|445
685|135


And therefore the winner is:
------------------------
loc-srv 135/tcp epmap # Location Service
loc-srv 135/udp epmap
microsoft-ds 445/tcp # Microsoft Naked CIFS
microsoft-ds 445/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
telnet 23/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp
ftp 21/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
https 443/tcp # http protocol over TLS/SSL
https 443/udp
webmin 10000/tcp
mysql 3306/tcp
mysql 3306/udp


Windows remains the main danger for our network and at our level we dynamicaly protect servers hosted by Ovh against scans on our network.

The type of scan that we detect is simple:
-> :
And the blocking is very clean
deny host any eq
Thus the ip that scans, can no longer scan the Ovh network on the port in question. Everything else goes well.

Regards,

Octave