I know it's common sense, but do NOT use FTP. Passwords are sent in plaintext. There seems to be a lot of people snooping.....

On my new server, I created a personal login account for me to use. I normally never use user 'admin'.... however:

Yesterday, I ftp'ed from an old server into one of my new rackshack dual xeon servers. I did ftp just ONCE, to transfer a database from the older server. I used the admin login, just for the hell of it....

This morning I find in the logs that _THREE_ people have since signed into my server via ftp. Two american hosts, and one from switzerland.

Luckly for me:

- sshd is running on a different port than normal, so they couldn't ssh into the box.

- I'm running portsentry, which proceeded to blackhole everyone who then tried to ssh in, completely blocking access to the machine.

- User account 'admin' has no access to my files, and is not in the same Group as webserver.

- I only have 2 user accounts (including 'admin'), and root, and all three have different passwords that are not dictionary crackable.

- Passwords on all my servers are different.


I've since checked the 3 user accounts for anything in lastlog, run chkrootkit, and nothing seems to be out of the ordinary.

It looks like the crackers tried the ftp login to verify the admin pass worked, then tried to access the machine via ssh (standard port) and got blocked. They then tried to port scan from a diff host, and also got immediately blackholed by portsentry.

I highly recommend the following:

1) Do not use FTP. use scp instead (http://winscp.vse.cz/eng/download.php) which basically works the same as ftp does, but without giving out your password to everyone, AND you do not need to run ftpd anymore.

2) If you have more than one IP address, have sshd bind to just one of them (logically, use the least popular IP so that your main site doesn't even show ssh ports anywhere)

3) Install portsentry (make sure your own ip address is added in the .ignore file just in case you trigger it to block

4) Move ssh's default port to a random high level port.

5) use secure passwords (duh)

6) Don't use the same password for all your accounts, especially root (duh again)

7) If possible, set gcc and all other compilers to be root-accessable only.

Remember that email (POP3) is also in plaintext.

9) If you're giving a friend your login info, remember that Instant Messages are also in plaintext.


I hope this post helps someone out there.

The one im guilty of .

-Dave

Hmmm that is scary... you got a new server, FTP'ed from one RS server TO another RS server (aka internal bandwidth) and got your uname and pw sniffed?

if that is the correct scenario then someone is running a server or two as sniffers internally (or appear to be)

excellent post! thankyou!
i have two servers and i now have 4 different passes for each of the admins (and they're all @#!@#!@#!@#!@#!es to type toO!)

i love your suggestions, but unfortunately for a novice like me its hard to implement them without risking destroying everything....

could you (or someone else) perhaps give instructions on how to
- change ssh port
- change ssh ip bind
- restrict gcc to root

To change ssh port

edit /etc/ssh/sshd_config and either find the "port 22" entry or add a line that contains "port #" (with whatever number you want)

Also in /etc/ssh/sshd_config, you can change the ip sshd listens to, it is "ListenAddress #.#.#.#"

for correctness you may want to edit /etc/services and change the port numbers for ssh also in that file


as far as compilers, you can do a "chmod 700 /usr/bin/g++" to take care of that problem. (Don't forget to do that for g++, gcc, and maybe g77)

although more time consuming and in-depth, it would be well worth it to get a firewall set up. Just let your known IP's through for ssh and just the needed ports open to the world. Changing ssh to a high port by itself won't really help at all, since a quick port scan would reveal that instantly. (The original poster that mentioned it also runs ipsentry, so anyone trying to connect to the original port gets blocked, great idea!)

thanks so much rkramer! i'll make the changes immediately, i really appreciate your help

i really like the idea of only letting known IPs through for ssh and ftp, to me that would be the best security feature of all....my question is...i am on adsl and (probably) have a dynamic ip, its possible to restrict the RANGE of ips isn't it..so i can only allow connections from , right?

also..i wouldn't want to run the risk of locking myself out of my own box and then rackshack can't let me in...does rackshack have a set of known ips (or a range) that i can allow them to get in..without allowing the whole of rackshack since AFAIK people from rackshack are doing some of the attacking themselves!!

IMVHO changing ssh port is pointless - new port can be discovered in milliseconds.

Using hosts.allow hosts.deny to restrict ssh and ftp access is a much better idea

Finally if someone had got ftp access to one of my servers then I would assume that the server is completly rooted

Changing ssh port along with using portsentry can be a highly effective combo.

I never said that I described ALL techniques that you can/should use -- not everyone has a static ip or class C that they can rely on to ssh from. ie; if you set sshd to only accept from ip x.x.x.x, and something happens that you're no longer on that block, you're screwed until rackshack can assist you.

I think most people place several 'backup' IP's to give access to their servers when using this technique, I normally use home dsl, work firewall, work backup dsl and one or two servers I have in other data centers

HTH

To block IP's is not good...

beacuse if you are on vacation our away and you go to a diferent computer / company provider ?


The safer way is not having easy passwords

put a nice firewall it a only the needed port's opened

and some others little trick's like....

and most important keep your eye on what your client's run under your servers

Each to their own - if you think that having ssh open on the internet is a good thing - knock yourself out

I'm unsubscribing from this thread before it degenerates

Just from using FTP, 3 people got into your server via FTP? Is FTP really that insecure? Just wondering... (and time to change my passwords...)

What's 100 % secure these's day's ???
and money comes first

not the majority of the servers in RS, perhaps thats why there is such a high atrition rate

A suggestion is NOT to use FTP but instead to use Secure FTP (sftp). Remember to disable FTP & Telnet logins.
Allow only ssh or sftp.

On my server, using proftpd, I just use a different password for ftp then ssh. I have my account jailed to an upload only directory as well, although I don't do that for some of my other users. The ftp passwords I use aren't anything strong, just enough so random people don't log in as anonymous or whatever.

And for ssh, I block any host that isn't mine or my other admin's as well.

one of the biggest security holes that people don't realize is the buffer overflow type of attack, NOT weak passwords. SSH in theory is fairly secure as long as you have a decent password, but now imagine someone can get in just by sending a huge login string to ssh. It crashes, leaving a root shell in it's place. (simplified version, but it has happened to MANY common programs...)

That is where the firewall is helpful, to prevent those attacks from every coming in to start with...

I took the excellent advice above to modify the port number for sshd which worked fine. However, now Ensim doesn't seem to know when the service is running or not and always reports it as down... (though still starts and stops it)! I made sure I changed /etc/services... so anyone any idea as to how to fix that side effect... I must admit I'm an Ensim newbie... I used to use command line for everything before. Not convinced at this stage Ensim helps ... But maybe it will grow on me. (I am using Ensim 3.1)

If you change the SSH and FTP ports, assure to inform RackShack when you request a reboot ticket, because RS will test the standard ports. The monitoring is made on these standard ports too. You could have serious delay problems when restarting your server, if you don´t do it.

Netino

For those here hosting clients' sites... can they still use their FTP clients such as WsFTP to use the secure ftp?

There should be an option in the account preferences to connect via sftp.

RS's LANs are switched, so how did the attacker sniff the passwords over the LAN? When I have run a sniffer for debugging net issues on my server, the only traffic I see is traffic destined for my server, level 2 stuff (STP etc), and broadcast packets ... I see no other traffic to other hosts.

The only time I have seen traffic destined for other hosts that (that didn't originate from my box) is when the RS LAN I am on has been subjected to a major DOS of some sort .. then the switches stop operating in point -> point mode and drop back to broadcast .. and so all traffic flows between hosts.

How do I know that? Snort captures .. when that situation arises, I will all of a sudden see snort log entries with traffic that does not have any IP that belongs to my server in the source or destination address fields .. lots and lots of it. This has only happened during serious attacks that affect the LAN segment I am on.

So then the possibility of sniffing seems to me to be limited to the source network, not the destination network, unless the sniffs happened during on of these handful of times when the switches stopped doing point -> point switching properly.

COuld it be possible that someone on the network you were using your ftp client from did the sniffing? If not there, could it be some point in between? It seems to me to be very unlikely that the sniffing happened on your RS LAN segment.

Interesting comments about the sniff possibility with ftp.

There's also an important reason for ftp capability, which is web development with tools like Macromedia Dreamweaver. You have to use site admin account to upload your site files via ftp, see this comment from Ensim 3.1 docs:

Name-based domains support FTP file transfers at the Site Administrator level only. Other users can upload files to the domain using the File Manager upload feature.

Therefore anyone using Dreamweaver and similar programs is opening their site up to possible intruders. Not a good thing, IMHO, either the client-side protocol choice has to be expanded to sftp or otherwise the design tools will become obsoleted.

I was wondering that as well... can anyone comment?

So is the advice to not use FTP to even upload your website HTML files/images? Same for other people using your server?

Unfortunately, it's impossible to enforce this with hosting customers. FTP is still the most popular file transfer method, secure or not, and it's a built-in feature of DreamWeaver, Frontpage, etc.

then this would mean that rackshak's backup solution should never be used unless they provide sftp. but perhaps they do, anyone know?

That settles it. I am never logging into my server ever again!

no, switches are not secure anymore there are tools for sniffing switches out there

I don't know if RackShack got any idea about this, and are doing (or not) something about it. Could someone from staff tell us about it?

Good news: There are ways to detect it
Bad news: There is no way to prevent it

for those still thinking twice on getting that server wide ssl certificate, do it ASAP

Why? What does the SSl certificate accomplish?

sweet fa

What's your opinion on using something like CuteFTP Pro with SFTP with SSH2?

I'm looking for a secure program, because I need the ftp capability.

Ugh. :eek:

Thanks in advance.

Hopefully when you use rackshack's backup system, you're not using the same passwords that you'd use for your user accounts on your server.

Worse case with someone getting your backup pass, is your backups are lost.

Any connection that is encrypted is going to be tons better than plaintext methods. If you must use regular ftp, I'd recommend:

1) chroot/jail the ftp accounts to be locked in a specified root dir, so they cannot snoop around the server.
2) use a user/pass combo that does not match any real accounts on the server. That way if it is found, you'll still have pretty high security maintained.
3) If you have a limited amount of users, you can also use hosts.allow/deny to prevent anyone but your user's on their regular netblocks from having access.
4) If you've got a lot of free time, you can even explore the wonderful world of port knocking

So you are saying there are tools that would allow a Rackshack owner to remotely sniff the switch over ethernet? Or a remote user outside of the segment the swtich handles sniff the switch? How so?

Please post a link to a web resource that discusses this technique or a link to a program/project that does this.

I don't understand how that can be possible without breaking into the switch over it's remote interface (ssh or god forbid telnet) and snooping from there.

I am not saying I don't believe it can't be done, I would just really be interested in seeing what resources you are drawing your information from .. let the rest of us be educated on this too.

Thanks!

The only way I could think of to do this would be to have an exploit that would cause the switch to change from point -> point mode back to broadcast mode (like what happens when the switch is overwhelmed during a heavy DOS or DDOS attack) and then just use a promiscous mode sniffer from any host on the segment.

Looking forward to learning more about this technique via any URLs you can post on it.

Yes, don´t trust switches are "unfailable". A DOS or DDOS can put switches to broadcast all packets, in promiscuous mode.

Netino

I maybe opening Pandora's box in here, but since it's on the Internet it's only a matter of time for a script kiddie or black hat to get this, it's useless to keep it from anybody

so here goes, for the sake of "no more security thru obscurity"

http://ettercap.sourceforge.net/

http://www.securityfocus.com/tools/1916

enjoy ;-)

Kami,

Thanks .. .damnit, I had seen that tool 2 years ago and had even tried it .. and had forgotten all about it.

Thanks again for the URLs. I don't think RS scans hosts to see who is in promiscuous mode and who isn't. I know they do security scanning, but I don't think they check for that.