@jmaxwell said:
Is the Romanian node officially gone or it’s just being “Calin’s server”
It’s been pretty unstable to the point that we don’t really monitor it. I just fix it every few days. I think it’s up right now though.
The public IP did change recently, make sure you’ve got the right IP in the panel.
Billing Panel and Control Panel Migration Announcement
Whilst we don't have a definitive date for this due to ongoing development at some point around mid January to Mid February we will be migrating away from the current billing panel and control panel to the new Micronode Panel which combines both aspects.
This massively improves the user experience and simplifies administration.
There will be no downtime for any Instances or VPS' although we expect around 3 days downtime on the Billing and Control panel, this will be communicated ahead of time to ensure that users can create instances or perform maintenance in advance.
Notice to users with VPS'
All VPS' will be converted to instances with the same specifications, a single instance credit will be assigned for all VPS users for the remainder of the billing period (512MB RAM and 20GB disk unless the VPS is larger where an additional credit will be assigned).
Notice to users with Storage VPS'
We will reach out to you ahead of time as this migration will involve downtime and a few operational differences.
The new panel
The new panel is written from the ground up, we've made huge UI improvements, added support for additional templates, introduced 2FA, Email verification and a higher level of fraud detection.
Breaking Changes:
* Password based SSH Auth has been removed, users will be required to add an SSH key for provisioning
* Hostnames are now automatically generated
* All locations come with the same resources (Double resource locations etc no longer come with double resources.)
Improvements:
* Loadbalancer Editing
* One panel for Billing and Administration
* 2fa
* Email Notifications
* Monitoring
* Faster Provisioning
* UI Improvements
Screenshots:
Instance Management:
Memory Upgrade / Downgrade:
Instance Details:
Launch Instance:
SSH Key Management:
Add SSH Key:
Products:
Checkout:
My Resources:
View Tickets:
Open Ticket:
Reply/View Ticket:
The public Beta will begin in the New Year, I'm going to be having some time away from development over the next few weeks to spend time with Friends and Family. We wish everyone an early Merry Christmas and a Happy New Year>
If you would like to join the public beta you must already have a Micronode Account with active resources, please DM me on here and we will arrange early access.
@Neoon said:
Do a closed/public test before you migrate everybody, otherwise it may be ugly.
As above, the beta will begin early January.
The public Beta will begin in the New Year, I'm going to be having some time away from development over the next few weeks to spend time with Friends and Family. We wish everyone an early Merry Christmas and a Happy New Year>
If you would like to join the public beta you must already have a Micronode Account with active resources, please DM me on here and we will arrange early access.
The code will be reviewed prior to release externally along with a pen test. I can’t share details on this currently as we haven’t yet awarded the contract.
This will likely not occur prior to the beta and this will be stipulated in the beta terms and conditions, no data personal data will be stored in the panel during the beta period and the panel will not be connected to any of our production nodes.
My VPS in Limburg got suspended due to "Torrent Activity Detected" yesterday. I don't use it to download torrents or anything related. When I logged in to the client area, I found that there's another (unrelated) ticket open for more than a month.
Has anyone else been erroneously suspended before?
@Brueggus said:
My VPS in Limburg got suspended due to "Torrent Activity Detected" yesterday. I don't use it to download torrents or anything related.
Torrent detection is an automated process, for context it was somewhat forced upon us from one of our providers to prevent the nodes from being suspended. I can't go into the full logic of what the detection is doing but the first condition that must be met is a number of TCP packets containing the bittorrent header must be detected either originating from or with a destination of either your IPV4 port range or IPv6 Address.
If your VPS is being used as a VPN any torrent traffic going over the VPN will also trigger this.
Thats not to say that we haven't seen false positives although I can say that less than 1% of our VPS' have been hit with a torrent suspension over the last 12 months and only a tiny number of them have been false positives.
Without fully understanding what was happening on your VPS at the time I can't categorically say what caused this although I have now unsuspended your VPS - you will need to reboot it from the panel.
To help debug this in the future the suspension warning in the upcoming panel will show the SRC and DST IP and port of the activity determined to be torrent based.
@Brueggus said: When I logged in to the client area, I found that there's another (unrelated) ticket open for more than a month.
We've always been clear that this service comes with limited/no support. We do tend to work through tickets in batches and we do a ticket sweep once per day to ensure that no clients are facing downtime.
@Brueggus said:
My VPS in Limburg got suspended due to "Torrent Activity Detected" yesterday. I don't use it to download torrents or anything related. When I logged in to the client area, I found that there's another (unrelated) ticket open for more than a month.
Has anyone else been erroneously suspended before?
As far as I'm aware out of the 800+ clients we have only one other user has seen false detection and we are working on a solution for their use case.
@Brueggus said:
My VPS in Limburg got suspended due to "Torrent Activity Detected" yesterday. I don't use it to download torrents or anything related. When I logged in to the client area, I found that there's another (unrelated) ticket open for more than a month.
Has anyone else been erroneously suspended before?
I'm having these problems too. I created a support ticket and we're still in investigation what cause these issues. On my vps I never used any torrents and never will.
@natvps_uk said:
Torrent detection is an automated process, for context it was somewhat forced upon us from one of our providers to prevent the nodes from being suspended. I can't go into the full logic of what the detection is doing but the first condition that must be met is a number of TCP packets containing the bittorrent header must be detected either originating from or with a destination of either your IPV4 port range or IPv6 Address.
An attacker can get everyone suspended by:
Scan for open TCP ports.
Send a BitTorrent header to each open TCP port.
Your detection logic needs to check for whether the container responded to the incoming BitTorrent header in a way that BitTorrent software would.
@yoursunny said: Your detection logic needs to check for whether the container responded to the incoming BitTorrent header in a way that BitTorrent software would.
I'm not able to go into details on this but this is accounted for. We didn't write the tooling, it was provided to us.
I plan to move to more of a traffic blocking approach to discourage torrenting VS Suspension.
I was one of the user that false positives causing vps suspended from half years ago,and they just unsuspended the vps 1-2months ago(after few months of two ticket opened).
And i can 100% confirmed the detection logic is not working correctly, as i never install any torrenting app on it,even vpn application like wireguard. (And the vps was suspended after few days of vps provision)
The only thing i "might" install was Alist(From Github),as i cant remember any else was installed on that suspended vps.
Edited:
They just unsuspended the vps,and only allow to reprovision the vps with blank new data,so i cant check what was the main reason on the vps causing the false positive.
@go626201 said:
I was one of the user that false positives causing vps suspended from half years ago,and they just unsuspended the vps 1-2months ago(after few months of two ticket opened).
And i can 100% confirmed the detection logic is not working correctly, as i never install any torrenting app on it,even vpn application like wireguard. (And the vps was suspended after few days of vps provision)
The only thing i "might" install was Alist(From Github),as i cant remember any else was installed on that suspended vps.
This will get better, the new panel automatically unsuspends after 24 hours which will prevent people being left in the dark.
Suspension script should provide a pcap of offending packets.
Customer who thinks they experienced victimisation could upload the pcap for all to judge whether they are indeed torrenting.
@yoursunny said:
Panel should provide a pcap of offending packets.
Customer who thinks they experienced victimisation could upload the pcap for all to judge whether they are indeed torrenting.
We’ll start with the src and dst ports and IPs. I’d rather put the effort into moving away from suspension and just try to prevent it via blocking torrent downloads. That’s an easier said than done mind as there’s a lot to consider there.
@yoursunny said:
Panel should provide a pcap of offending packets.
Customer who thinks they experienced victimisation could upload the pcap for all to judge whether they are indeed torrenting.
We’ll start with the src and dst ports and IPs. I’d rather put the effort into moving away from suspension and just try to prevent it via blocking torrent downloads. That’s an easier said than done mind as there’s a lot to consider there.
In my undergraduate, I participated in a research program that studies how to restrict BitTorrent and eDonkey.
I don't understand the details as I only built an UI.
The grad student in charge of the project said it's based on pattern matching in the packets, implemented through iptables l7filter module.
As soon a matching string is found in the packet, that packet is dropped.
In the demo, we can see BitComet shows zero speed when the blocker is enabled.
I don't know how much overhead this would cause though.
I read some other papers at that time.
One other technique is counting the number of TCP connections versus the number of remote IPs.
If a particular local IP:port has made many TCP connections but there's only one connection per remote IP, this port is engaging in torrenting.
Boss made me implement this method on the office router.
Whoever found torrenting during work hours would be called into the boss office.
Torrenting is legal in China but it's not okay to cause a congestion during work hours.
Comments
It’s been pretty unstable to the point that we don’t really monitor it. I just fix it every few days. I think it’s up right now though.
The public IP did change recently, make sure you’ve got the right IP in the panel.
Billing Panel and Control Panel Migration Announcement
Whilst we don't have a definitive date for this due to ongoing development at some point around mid January to Mid February we will be migrating away from the current billing panel and control panel to the new Micronode Panel which combines both aspects.
This massively improves the user experience and simplifies administration.
There will be no downtime for any Instances or VPS' although we expect around 3 days downtime on the Billing and Control panel, this will be communicated ahead of time to ensure that users can create instances or perform maintenance in advance.
Notice to users with VPS'
All VPS' will be converted to instances with the same specifications, a single instance credit will be assigned for all VPS users for the remainder of the billing period (512MB RAM and 20GB disk unless the VPS is larger where an additional credit will be assigned).
Notice to users with Storage VPS'
We will reach out to you ahead of time as this migration will involve downtime and a few operational differences.
The new panel
The new panel is written from the ground up, we've made huge UI improvements, added support for additional templates, introduced 2FA, Email verification and a higher level of fraud detection.
Breaking Changes:
* Password based SSH Auth has been removed, users will be required to add an SSH key for provisioning
* Hostnames are now automatically generated
* All locations come with the same resources (Double resource locations etc no longer come with double resources.)
Improvements:
* Loadbalancer Editing
* One panel for Billing and Administration
* 2fa
* Email Notifications
* Monitoring
* Faster Provisioning
* UI Improvements
Screenshots:
Instance Management:
Memory Upgrade / Downgrade:
Instance Details:
Launch Instance:
SSH Key Management:
Add SSH Key:
Products:
Checkout:
My Resources:
View Tickets:
Open Ticket:
Reply/View Ticket:
The public Beta will begin in the New Year, I'm going to be having some time away from development over the next few weeks to spend time with Friends and Family. We wish everyone an early Merry Christmas and a Happy New Year>
If you would like to join the public beta you must already have a Micronode Account with active resources, please DM me on here and we will arrange early access.
Do a closed/public test before you migrate everybody, otherwise it may be ugly.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
As above, the beta will begin early January.
So who is the auditor?
Free Hosting at YetiNode | Cryptid Security | URL Shortener | LaunchVPS | ExtraVM | Host-C | In the Node, or Out of the Loop?
The code will be reviewed prior to release externally along with a pen test. I can’t share details on this currently as we haven’t yet awarded the contract.
This will likely not occur prior to the beta and this will be stipulated in the beta terms and conditions, no data personal data will be stored in the panel during the beta period and the panel will not be connected to any of our production nodes.
Free NAT KVM | Free NAT LXC | Bobr
ITS WEDNESDAY MY DUDES
My VPS in Limburg got suspended due to "Torrent Activity Detected" yesterday. I don't use it to download torrents or anything related. When I logged in to the client area, I found that there's another (unrelated) ticket open for more than a month.
Has anyone else been erroneously suspended before?
dnscry.pt - Public DNSCrypt resolvers hosted by LowEnd providers • Need a free NAT LXC? -> https://microlxc.net/
Torrent detection is an automated process, for context it was somewhat forced upon us from one of our providers to prevent the nodes from being suspended. I can't go into the full logic of what the detection is doing but the first condition that must be met is a number of TCP packets containing the bittorrent header must be detected either originating from or with a destination of either your IPV4 port range or IPv6 Address.
If your VPS is being used as a VPN any torrent traffic going over the VPN will also trigger this.
Thats not to say that we haven't seen false positives although I can say that less than 1% of our VPS' have been hit with a torrent suspension over the last 12 months and only a tiny number of them have been false positives.
Without fully understanding what was happening on your VPS at the time I can't categorically say what caused this although I have now unsuspended your VPS - you will need to reboot it from the panel.
To help debug this in the future the suspension warning in the upcoming panel will show the SRC and DST IP and port of the activity determined to be torrent based.
We've always been clear that this service comes with limited/no support. We do tend to work through tickets in batches and we do a ticket sweep once per day to ensure that no clients are facing downtime.
As far as I'm aware out of the 800+ clients we have only one other user has seen false detection and we are working on a solution for their use case.
I'm having these problems too. I created a support ticket and we're still in investigation what cause these issues. On my vps I never used any torrents and never will.
An attacker can get everyone suspended by:
Your detection logic needs to check for whether the container responded to the incoming BitTorrent header in a way that BitTorrent software would.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
I'm not able to go into details on this but this is accounted for. We didn't write the tooling, it was provided to us.
I plan to move to more of a traffic blocking approach to discourage torrenting VS Suspension.
I was one of the user that false positives causing vps suspended from half years ago,and they just unsuspended the vps 1-2months ago(after few months of two ticket opened).
And i can 100% confirmed the detection logic is not working correctly, as i never install any torrenting app on it,even vpn application like wireguard. (And the vps was suspended after few days of vps provision)
The only thing i "might" install was Alist(From Github),as i cant remember any else was installed on that suspended vps.
Edited:
They just unsuspended the vps,and only allow to reprovision the vps with blank new data,so i cant check what was the main reason on the vps causing the false positive.
MY/SG & Worldwide Latency Test V3 : http://www.mywebping.com (27 February 2021 Updated)
MY-Unifi Home SmokePing: http://smokeping.mywebping.com/smokeping/
This will get better, the new panel automatically unsuspends after 24 hours which will prevent people being left in the dark.
Suspension script should provide a pcap of offending packets.
Customer who thinks they experienced victimisation could upload the pcap for all to judge whether they are indeed torrenting.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.
We’ll start with the src and dst ports and IPs. I’d rather put the effort into moving away from suspension and just try to prevent it via blocking torrent downloads. That’s an easier said than done mind as there’s a lot to consider there.
In my undergraduate, I participated in a research program that studies how to restrict BitTorrent and eDonkey.
I don't understand the details as I only built an UI.
The grad student in charge of the project said it's based on pattern matching in the packets, implemented through iptables l7filter module.
As soon a matching string is found in the packet, that packet is dropped.
In the demo, we can see BitComet shows zero speed when the blocker is enabled.
I don't know how much overhead this would cause though.
I read some other papers at that time.
One other technique is counting the number of TCP connections versus the number of remote IPs.
If a particular local IP:port has made many TCP connections but there's only one connection per remote IP, this port is engaging in torrenting.
Boss made me implement this method on the office router.
Whoever found torrenting during work hours would be called into the boss office.
Torrenting is legal in China but it's not okay to cause a congestion during work hours.
Accepting submissions for IPv6 less than /64 Hall of Incompetence.