Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Thinking of providing few sponsored VPSs, what ports to block to avoid abuse?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Thinking of providing few sponsored VPSs, what ports to block to avoid abuse?

As title says, theres a small local community here where I live, and I intend to give 4 OVZ VPSs away from my private node for them to redistribute to the student groups that may need one for an assigment/courses.

Since theyre all 9th grade primary school (16yo) IT-field students, I'd like to prepare for abuses. What ports would you guys block and what measures would you take before handing out a free VPS to a somewhat risky end user(s).

Comments

  • YuraYura Member

    Realistically - all.

  • kh81kh81 Member

    Definitely these, but there surely are a lot more.

  • cubedatacubedata Member, Patron Provider

    here is what we do; nodewatch for ovz runs on the nodes and stops all abuse automatically since it will auto suspend the vps's if they cause a problem.
    this is what we had to do for our vps's we sponsor to post4vps.

  • jlayjlay Member
    edited April 2017

    Security is essentially where you draw the line on ease of use. The most secure thing wouldn't have access at all, but it wouldn't be easy to use (or particularly useful). Blocking ports is a game of cat and mouse, just monitor usage (network/system resources) and handle it that way.

    Edit: If you're really wanting to block ports, the big three I recommend are 25 (SMTP), 53 (DNS), and 123 (NTP). Poorly configured/utilized services on these ports can cause a lot of headaches.

  • Block all and open ports on a case-by-case basis

  • raindog308raindog308 Administrator, Veteran

    kh81 said: Definitely these, but there surely are a lot more.

    That list looks like a Best of the 90s. When's the last time anyone saw Back Orifice in the wild, hacking unpatched Windows NT 3.5 systems?

    @stefeman I'd block outgoing email, unless there is a reason they need it.

    I'd block port 53 unless they're running a DNS server, to avoid reflection attacks, etc.

    You can go down quite a rabbit hole...some would say "everything's blocked, tell me what you need to open". It wouldn't be unreasonable to say "sshd is running on 2222, so that and 80/443 are open, anything else is closed and you need to request". Depends how fascist you want to be...though of course, the more fascist, the less interested students might be.

    You could also state up front "these are free for student studying purposes, but they don't come with the same privacy standards you'd find if you bought from a regular provider. To that end, I'll periodically scan filesystems, run AV scans, etc."

    You could also put in something that requires strong passwords, or set the root password yourself to something strong, or run crack periodically, etc. That's probably a major issue - people picking bad passwords.

    BTW, I have to ask - the github student pack comes with $50 in DO credit. DreamSpark (Microsoft) comes with some sort of Azure credit (which can be used to run Linux VMs). Seems like there's all kinds of free VPS hosting out there for students already.

    Thanked by 1ucxo
  • stefemanstefeman Member
    edited April 2017

    Thanks everyone. I'll look into these.

    @raindog308 said:
    BTW, I have to ask - the github student pack comes with $50 in DO credit. DreamSpark (Microsoft) comes with some sort of Azure credit (which can be used to run Linux VMs). Seems like there's all kinds of free VPS hosting out there for students already.

    This is something I chatted randomly with my friend (a primary school IT teacher) about. Nothing is really set to stone, as i'm just looking into if this would be even needed. It would be pretty much just for his lessons.. just something to tinker with most likely.. I assume the students would access the machines outside school time as well. We're talking about 4x 2-3 man/woman groups at max.

  • To avoid abuse do not provide a free or sponsored VPS at all.

  • raindog308raindog308 Administrator, Veteran

    It's worth pointing out that this isn't the standard customer-provider relationship. If someone loads up a lazer on the free VPS and uses it to DOS someone, you know who they are and there will be academic consequences.

    I think the biggest risk is the box being hacked due to inexperienced sysadmins.

  • edited April 2017

    Assuming these are on the Internet, and not on a private network....

    Block anything database related. MySQL, PostgreSQL, Redis, MongoDB, etc. Most GUI tools support SSH, so there isn't a good reason to have these open. Or have one dedicated Db box that is hardened.

    I can see the case being made for blocking port 25 incoming and outgoing. If email is needed, and it is fun to get it working, setup a relay server or use the school's email server.

    They probably don't need to join the NTP pool, so that's a good one.

    DNS is kind of iffy. They could host their own subdomain on the server. It depends on what they're going to be doing. It should be a non-recursive service, of course. This is another one of those things that is fun to setup.

    After that, it kind of depends on what they're going to be doing.

    • Web dev: open 22, 80, 443
    • Systems dev: open 22
    • Service dev: open 22, 1025+
    • SysAdmin: open 22, then make them open ports on the system firewall as needed.

    I'd be lenient, but vigilant, to let the students play in the sandbox and figure things out. They're going to do dumb stuff, but now is the time to learn why those are bad ideas.

  • It's like provide cheeseburgers without cheese or cakes without cream because it free.

    Guess abusers not need free stuff, till they poor abusers.

  • LeeLee Veteran

    If you are going to sponsor to complete unknowns then all I recommend blocking is the power button.

Sign In or Register to comment.