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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
22 or custom - ssh
80 - http
8080 - second server
443 - ssl
21 - if they're ignorant enough to run FTP :P
We'll probably be disabling FTP just because of that possibility
Um, all of them. If I have a VPS, I expect that the provider isn't blocking anything.
^ That.
We're mulling over a few ideas for blocking SMTP at the host node and then enabling it upon request per container. This thread is related to that goal.
I shouldn't have to ask for permission to send mail from my VPS.
IP blacklisting is not fun.
@RamNode better limiting that completely disabling outgoing connections to --dport 25. You can do that at node level via iptables. I've seen a few discussions and samples about that, but i can't remember on what forum.
getting back to common ports, here the relevant part from iptables on a vps of mine:
port 4949 is standard for munin-node, 25/465/587 for smtp, 53 tcp/udp for dns, 22 with rate limiting for ssh (requires recent module), 80/443 http/s
Check users details before they pay, it's simple.
If someone signs up with sketchy details and can't explain them then they're likely up to no good. I'm pretty sure @Aldryic can count on his 2 hooves how many blacklist entries he has had to clear this year
Fran
Default should be to allow all traffic and monitor. If there's a spike or suspicious amount traffic on port 25 from a particular container, then DROP outgoing port 25 on that container and send an email to the customer.
port 6667 is also nice
Welcome to being a VPS provider.
-A INPUT -p udp --dport 53 -j ACCEPT
I'm curious - this is only necessary if you're running a DNS server, right? I don't open 53 on non-DNS-server VPSes and have never had any problems using DNS, as the queries are caught by the ESTABLISHED rule.
I never run SSH on port 22...because whenever I do people tediously knock on the door.
daytime 13/tcp
daytime 13/udp
time 37/tcp
time 37/udp
ntp 123/udp
I sometimes run web servers on alternate ports: 591, 777, 8008
On a VPS no ports should be blocked except maybe common IRC ports only if you don't allow IRC.
I would only reluctantly accept blocking of port 25. I can use 465 with SSL if i really need to with my own SMTP server some place else, but that provider will already have a - in my book.
I mean, no rDNS by default, fine, port 25 blocked, f-fine, but this speaks volumes about the host's abilities to handle **** when it happens.
If it is a very good deal, I take it, otherwise, no.
M
At the risk of starting a war I have to say I disagree.
The inherent security risk of FTP -- transmitting credentials in plain text -- is easily resolved by configuring the FTP daemon to use SSL encryption. e.g., for vsftpd:
Free FTP clients like FileZilla and CoreFTP readily support this. For a multi-user system (where many people are uploading) I prefer this to SFTP because:
@sleddog i think its also possible to give sftp acces but no shell by limiting them other ways but I'm not entirely sure. Performance wise it is faster and less overhead indeed.
Anyways, you sound like you know what you're doing so you weren't my real audience. When made secure, I don't have any problem with it at all. Its just that most default ftp installs are so insecure and full of leaks
Ports 1-65535 because port blocking is weak sauce.
I didn't think that you had to give shell access to give sftp access. I seem to recall you could set the user's shell to /bin/false and they could still sftp?
I could very easily be wrong, though.
I use vsftpd as you do :-)
There's things like scponly shell which I last tried a couple years ago... I couldn't get it to chroot users to their homedir. Maybe that's fixed/easier to do now.
And that's another point I'll add to the bullet-list above... chrooting users is extremely easy with FTP.
Can't argue with that But I don't think that FTP should be labelled, "Insecure! Don't use it." in the same fashion as, say, telnet.
sftp and scp are "over-ssh" and require a valid user shell like /bin/sh, /bin/bash, etc. Or at least that's the way it was the last time I checked....
Well, we're at least going to do some rate limiting. Still on the fence about blocking anything by default.
I mean, no rDNS by default, fine, port 25 blocked, f-fine, but this speaks volumes about the host's abilities to handle **** when it happens.
If it is a very good deal, I take it, otherwise, no.
M
We would enable it per request if we go that route.
It passed my mind to block SMTP as well, however desided not to go that route, atleast for now. For the past 1 year, had only 2-3 IPs blacklisted. Its acceptable, its under 1% of my allocations.
What's so bad about ftp?
There's no s before or after it.
@Daniel oh, how many times has someone sniffed anything over external ftp?
I don't know, but do you want to take the risk?
SFTP is widely supported now, no reason not to use it. My MC panel even recommends it over FTP.
Following this reasoning we could all go back and use Telnet instead of SSH.
We force our clients of shared hosting to connect through sftp..