Sinisterly
Any more ways to secure my box? - Printable Version

+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Website & Server Hacking (https://sinister.ly/Forum-Website-Server-Hacking)
+--- Thread: Any more ways to secure my box? (/Thread-Any-more-ways-to-secure-my-box)

Pages: 1 2


Any more ways to secure my box? - Megan - 01-13-2016

So currently I have a box that has the following.

The only service is SSH.
To SSH in you need the public key.
To SSH in you need the passphrase.
Passwd login is disabled.
Root login is disabled.

Any suggestions on improvements on how to harden it?

Quote:Note: I would change the default port from 22 to something else but for some reason everytime I try it ends up making the box inaccessible from remote SSH, so changing the default port is not really viable at the moment as I am not near the box to fix it.



RE: Any more ways to secure my box? - Megan - 01-13-2016

(01-13-2016, 04:24 PM)Kuro Wrote: Nothing, I've already rooted all your boxes.
Spoiler:
and probably most people on sl's too

*David Attenborough voice* and here we see the runt of the skids attempting to assert his dominance by being jovial, watch as the majestic creature fails dramatically.


RE: Any more ways to secure my box? - The Real Slim Shady - 01-13-2016

Some further possible hardening tips:

1. Whitelisting allowed IP's

2. Running something like fail2ban to mitigate brute force attacks

3. Rate limit connections attempts to like, 1 attempt per 30 seconds. Reduces the effectiveness of a brute force attack.

4. Add 2 factor authentication

5. Change the default port. Not really "security" but it will reduce the number of people who try anything who just scan IP ranges for specific ports. I like 2222 personally.

6. If you really want to get creative you could look into "port knocking"

7. If you stated that you disabled root login - but you can also white list specific users/groups - so you don't need to disable specific accounts. this is better because if a new account is made it won't have ssh access

8. Use jailed shells

9. Make sure you're using/forcing SSH2 - You don't want people doing a downgrade attack


RE: Any more ways to secure my box? - Dyme - 01-13-2016

Depends on what you want to use it for... I'm assuming you'll be running something other than just SSH?


RE: Any more ways to secure my box? - Rou - 01-13-2016

(01-13-2016, 05:12 PM)The Real Slim Shady Wrote: Some further possible hardening tips:

1. Whitelisting allowed IP's

2. Running something like fail2ban to mitigate brute force attacks

3. Rate limit connections attempts to like, 1 attempt per 30 seconds. Reduces the effectiveness of a brute force attack.

4. Add 2 factor authentication

5. Change the default port. Not really "security" but it will reduce the number of people who try anything who just scan IP ranges for specific ports. I like 2222 personally.

6. If you really want to get creative you could look into "port knocking"

7. If you stated that you disabled root login - but you can also white list specific users/groups - so you don't need to disable specific accounts. this is better because if a new account is made it won't have ssh access

8. Use jailed shells

9. Make sure you're using/forcing SSH2 - You don't want people doing a downgrade attack
^
Do this and you can be fairly confident in the security of your SSH login, at least. I especially recommend fail2ban. I've been yelled at by a VPS provider before for using too much CPU time, and it turned out to be nothing but a massive SSH bruteforce attempt.

You should also block everything you don't use in iptables. Just be sure not to lock yourself out!
If you're planning on running a web server, something like tripwire could also come in handy, which let's you detect when files change unexpectedly.

And, of course, keep yourself up to date with security related info for all the software you're running, so you know to install critical updates as soon as they're released.

If you're interested, Jupiter Broadcasting's TechSNAP podcast usually keeps you up-to-date with the most important stuff, as well as teaching you different tips and tricks along the way. You can send them an email and ask if they want to cover a "How to secure your server, 2016 edition" on the show.


RE: Any more ways to secure my box? - meow - 01-14-2016

grsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsec


RE: Any more ways to secure my box? - Oni - 01-14-2016

(01-14-2016, 02:15 AM)meow Wrote: grsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsecgrsec

What he means to say, is that he recommends Grsecurity.

Code:
Grsecurity® is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats through intelligent access control, memory corruption-based exploit prevention, and a host of other system hardening that generally require no configuration. It has been actively developed and maintained for the past 14 years. Commercial support for grsecurity is available through Open Source Security, Inc.



RE: Any more ways to secure my box? - Loki123 - 01-27-2016

(01-13-2016, 05:12 PM)The Real Slim Shady Wrote: 4. Add 2 factor authentication

5. Change the default port. Not really "security" but it will reduce the number of people who try anything who just scan IP ranges for specific ports. I like 2222 personally.

6. If you really want to get creative you could look into "port knocking"

4. He has SSH keys. He doesn't really need more protection considering the authentication other than keeping the private SSH key safe and as well as using a good passphrase with it. Other than that, the authentication process is perfectly secure as it is. But as a further protection, it is correct to mention it.

5. Changing the port to 2222 should be considered a security risk really. I'll accept that he should be fine doing that, but he shouldn't do it none the less. The main risk I personally see if, on a multi user system, one user starts mimicking the SSH server he put in place. And yes, that user can do that because you changed the port to 2222. Now; Due to the SSH keys, he should get a key mismatch error and load of crap, but the risk still exists.

6. Port knocking is a much better solution. As it would keep the SSH server on a privileged port but then again; is there any real harm in showing that you are running an SSH server ? No, none at all.

If you want to reduce logs on SSH there are better methods and you listed one that comes into mind, Fail2Ban or quite simply using IPTables. Then, for the last part. Logs don't get that big, log files are usually split up when they reached some max size. Meaning, searching in them isn't very slow nor complicated if you can take advantage of grep for example.

The rest I completely agree with though.

@Megan

Take a look at Grsecurity but in my experience, security vulnerabilities are mostly due to the owner and maintainers incapability to reckon when his system is outdated. It is more rare to be compromised by a vulnerability that has not hit the internet yet or one that hasn't been patched yet. Security issues that are dangerous are usually fixed nearly right away and a patch pushed out. Keeping your system updated is crucial to being secure, however, that does not mean always be updating to the latest version or to the next stable major version, that could be a pain if major changes happened. What I mean is that you keep updating to get security patches. Stable versions more often than not get security patches so system administrators don't have to go through the trouble very often to update to a new major version each time they release a new one, instead they have the option of only getting the patch and not needing to maybe reconfigure their whole setup due to a syntax change or something important to them at that time being removed in a newer version. And a lot more probably that you can count up on the reasons major, stable, versions are kept supported for quite some time.


RE: Any more ways to secure my box? - The Real Slim Shady - 01-28-2016

(01-27-2016, 10:35 PM)Loki123 Wrote: 4. He has SSH keys. He doesn't really need more protection considering the authentication other than keeping the private SSH key safe and as well as using a good passphrase with it. Other than that, the authentication process is perfectly secure as it is. But as a further protection, it is correct to mention it.

5. Changing the port to 2222 should be considered a security risk really. I'll accept that he should be fine doing that, but he shouldn't do it none the less. The main risk I personally see if, on a multi user system, one user starts mimicking the SSH server he put in place. And yes, that user can do that because you changed the port to 2222. Now; Due to the SSH keys, he should get a key mismatch error and load of crap, but the risk still exists.

6. Port knocking is a much better solution. As it would keep the SSH server on a privileged port but then again; is there any real harm in showing that you are running an SSH server ? No, none at all.

If you want to reduce logs on SSH there are better methods and you listed one that comes into mind, Fail2Ban or quite simply using IPTables. Then, for the last part. Logs don't get that big, log files are usually split up when they reached some max size. Meaning, searching in them isn't very slow nor complicated if you can take advantage of grep for example.

The rest I completely agree with though.

I was providing some additional suggestions.

4. It may not be necessary if he keeps his key secure. but what if it falls into the wrong hands? his computer hacked, accidentally uploaded to github... whatever. The fact is it is additional protection. Which is why I mentioned it.

5. The user would have to be able to kill that process. But if you're worried about requiring root to use the port - you could just as easily use 222 or 15 if you wanted to. no practical difference between 22 and 222. Again, its just security through obscurity but in the event a 0day hits the web it'll stop the skids scanning 22 for vulnerable services. definitely a + no matter how little security it actually provides. Which is why i mentioned it.

6. There is nothing wrong with showing that you're running an ssh service. Unless there is a vulnerability. or your key becomes compromised. In which case not knowing how to access the service or even being able to tell that there is one, is a decent security precaution. Which is why i mentioned it.

Whether the suggestions are reasonable or practical or not - there is valid reasoning/logic behind all of them. They will not detract from security in any way, and will infact likely increase it.


RE: Any more ways to secure my box? - Loki123 - 01-28-2016

(01-28-2016, 04:36 AM)The Real Slim Shady Wrote: I was providing some additional suggestions.

4. It may not be necessary if he keeps his key secure. but what if it falls into the wrong hands? his computer hacked, accidentally uploaded to github... whatever. The fact is it is additional protection. Which is why I mentioned it.

5. The user would have to be able to kill that process. But if you're worried about requiring root to use the port - you could just as easily use 222 or 15 if you wanted to. no practical difference between 22 and 222. Again, its just security through obscurity but in the event a 0day hits the web it'll stop the skids scanning 22 for vulnerable services. definitely a + no matter how little security it actually provides. Which is why i mentioned it.

6. There is nothing wrong with showing that you're running an ssh service. Unless there is a vulnerability. or your key becomes compromised. In which case not knowing how to access the service or even being able to tell that there is one, is a decent security precaution. Which is why i mentioned it.

Whether the suggestions are reasonable or practical or not - there is valid reasoning/logic behind all of them. They will not detract from security in any way, and will infact likely increase it.

I do realize that you were only providing additional suggestions, I was trying to provide reasonable logic why he wouldn't need 2 of them or wouldn't want. Cons of those methods pretty much was all I was trying to do. But implemented correctly and they all serve their good purpose.

4. As said, if the key falls into the wrong hands, it should have a decent passphrase. Today, cracking a 12 character passphrase takes years if not longer (excluding clusters for this purpose which I doubt many 12 year old kids using RAT's have access to) but instead of directly getting his hands on the password if his computer gets compromised he gains the key, but not the passphrase unless the admin uses the same passphrase everywhere, which is his own fault. Meaning you have two layers to bypass to gain access. Should be considered enough security. If he were to only use password, he might want that 2FA. But not saying the idea is wrong, just saying that the security currently exists could be considered enough security authentication vise. Of course it is logical to suggest it in here.

5. It isn't about being worried. It is more about not opening yourself to other variations of attacks. Thus; What good does it do to change the port to something that opens up a realistic and practical security risk ? That is all I am saying. Tl;dr; if changing the port, don't do it above 1024. Basically what I was trying to say.

6. I have nothing to say to this point.. Agreed pretty much.


Don't mistake my intentions for saying you are wrong or the idea/logic is wrong because it isn't. The intentions were simply to post the cons of one method (port 2222) that is frequently used and suggested. But everyone should be able to make their own decisions made up with the pros and cons, and I find the cons rarely posted in the port changing situation. But no idea or suggestion in your post is wrong at all.