You are not logged in.

#26 2009-11-25 03:00:37

mawhii
Member
Registered: 2009-07-04
Posts: 18

Re: SSH - Is my setup secure?

Oo..

drop at bottom, missed that!

What I was referring to is your default policy..

"Chain INPUT (policy ACCEPT)"

It pretty much means if no other rule matches, do this. But I see you have a drop all at bottom, so that won't ever be used from what I can tell.

Offline

#27 2009-11-25 03:05:30

ybotspawn
Member
From: Oz
Registered: 2008-04-06
Posts: 140

Re: SSH - Is my setup secure?

1. Change the port
2. Use RSA Keys
3. Why did you setup the ssh server so that a mysql service account had allowed login through ssh?
4. I disagree with the comment that RSA Keys = Complex Passwords (greater than 9 characters) if you really wanted to make an argument about RSA keys being long passwords then they are 100+ character passwords, I have yet to see a password with that type of complexity.


"As long as people are going to call you a lunatic anyway,
why not get the benefit of it? It liberates you from convention. "

Offline

#28 2009-11-25 04:18:35

merrill541
Member
From: United States
Registered: 2009-11-08
Posts: 14

Re: SSH - Is my setup secure?

mawhii wrote:

Oo..

drop at bottom, missed that!

What I was referring to is your default policy..

"Chain INPUT (policy ACCEPT)"

It pretty much means if no other rule matches, do this. But I see you have a drop all at bottom, so that won't ever be used from what I can tell.

Cool, I was worried there for a bit.


ybotspawn wrote:

1. Change the port
2. Use RSA Keys
3. Why did you setup the ssh server so that a mysql service account had allowed login through ssh?
4. I disagree with the comment that RSA Keys = Complex Passwords (greater than 9 characters) if you really wanted to make an argument about RSA keys being long passwords then they are 100+ character passwords, I have yet to see a password with that type of complexity.

I will definitely not make the mistake again of allowing a mysql account ssh login. As I said earlier, I had created it myself instead of letting the MySQL package create it, thus unintentionally giving it shell access. Right now, I have the AllowUsers directive set to allow only one user and with the PermitRootLogin (or something similar) directive to no. So I have verified that only one user can log in to the ssh server.

Offline

#29 2009-11-25 07:33:44

.:B:.
Forum Fellow
Registered: 2006-11-26
Posts: 5,819
Website

Re: SSH - Is my setup secure?

merrill541 wrote:

That is good to know. But why isn't the linux kernel base code modified for all distributions. Doesn't really make any sense not to do it.

It probably is already. Remember Debian doesn't use the most recent of software (although they do perform security updates and I like to believe they're good at it, if only because of the size of the project), and that combined with maybe sloppy updating from your side, might mean there are are vulnerabilities (well, there are always vulnerabilities, the question is whether they're known publicly and whether they're patched or not).

You shouldn't blame kernel devs though. You've been negligent, that's all there's to it. A system with internet access (and especially a server) should be firewalled. Using Linux doesn't mean you're safe just because you use Linux. If you leave the door open and get robbed, would you blame the construction company?

Chain INPUT (policy ACCEPT)
ACCEPT     all  --  anywhere             anywhere

This is bad already. Set your policy to DROP, then set your rules. Iptables works its way down your rules file (the configuration file), and if none of the rules match it will use the policy. So setting a policy to ACCEPT, then adding a rule blocking everything, then adding a rule (e.g.) allowing SSH will result in blocking everything (since iptables will never get to the second rule).

I found this to be an excellent source on iptables. Not concise, but clear.

mawhii wrote:

Oo..

drop at bottom, missed that!

What I was referring to is your default policy..

"Chain INPUT (policy ACCEPT)"

It pretty much means if no other rule matches, do this. But I see you have a drop all at bottom, so that won't ever be used from what I can tell.

It's a redundant rule, a line you could toss out. It's just bad practice altogether. Save iptables (and yourself) the trouble. Complexity only makes security harder to enforce.

So: policy to DROP, then define what you allow by setting your rules.


Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy

Offline

Board footer

Powered by FluxBB