[ale] ssh brute-force

Tue Feb 18 09:21:56 EST 2014

Sorry about that.

You don't have to wait for your network/architecture team though.   Even if it is open via your network firewall device(s) you can still control it via iptables at host level and only open the ports in each specific host's iptables that you expect to be used on that host.   That is having external access to all ports on all hosts is a bad thing but you can mitigate it by insuring at least that your hosts are only allowing the traffic you want.

Ideally any device exposed to INBOUND traffic from the internet should be DMZed so that there is a firewall device between it and the internet and another firewall device between it and your internal network.  Most servers only need OUTBOUND traffic to the internet.   In the internal firewall device most of the traffic should be one way - from your internal servers to the DMZ host and not vice-versa though for a few things you might actually need SOME inbound flow it is should be for very specific things and would be a lot less than you'd allow out to the DMZ host.   The great thing about iptables is you can get even more granular at host level about what you allow into it.

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Edward Holcroft
Sent: Tuesday, February 18, 2014 9:14 AM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] ssh brute-force

Shit Jeff, you have just pointed out a design flaw in our entire AWS setup that I was unaware of! We use a single security policy for all our servers, and every time we need another port open, it gets added to the global policy. We should be creating a policy for each individual server. After you comment, I went in there and took a look and yes, we have sql ports rdp ports ssh ports ftp ports http/s ports .... everything in the single policy. At this rate eventually everything will be world open on all servers!

Thanks for asking the question. I'm going to get our architecture guys on this right away.

cheers
ed

On Tue, Feb 18, 2014 at 8:48 AM, Lightner, Jeff <JLightner at water.com<mailto:JLightner at water.com>> wrote:
Given that 443 is the standard https port I'd think you'd still have an issue with lots of hits on this port although they'll be trying to break the wrong thing by default.   Also since both ssh and https are based on ssl it is just possible someone smart enough to actually smart enough to hack one would be smart enough to hack the other.  443 is below 1000 so is in the space commonly reserved for root level processes.   As a final note if you ever did put up a secure web service on this machine the port would conflict (unless  you chose a different one for your web service).

The question is why do you have 443 or other ports "open to the world" if they're not actually in use on the host?   Much better to turn off 443 and turn on something random above 1000.

From: ale-bounces at ale.org<mailto:ale-bounces at ale.org> [mailto:ale-bounces at ale.org<mailto:ale-bounces at ale.org>] On Behalf Of Edward Holcroft
Sent: Tuesday, February 18, 2014 8:35 AM

To: Atlanta Linux Enthusiasts
Subject: Re: [ale] ssh brute-force

Thanks everyone for the useful links and comments. I decided to go with port 443 since that was already open to the world, meaning I did not need to open an additional port.

I was happy to note that enabling password logins did not stop my ssl-based logins from working on the same server. I was worried it might be an either/or scenario. Unfortunately, for the service I'm setting up I had to provide a password-based login. I set up a restricted user for this purpose.

Will monitor things and see what kind of hits I get on that server. Hopefully the problem goes away or is significantly reduced by this. If I still see lots of hits then I guess I'll just have to go back to denyhosts which seems to do a great job of nailing things down. Of course, I'd rather not have the hits at all.

cheers
ed

On Mon, Feb 17, 2014 at 9:37 AM, JD <jdp at algoloma.com<mailto:jdp at algoloma.com>> wrote:
Securing ssh:
http://blog.jdpfu.com/2011/08/23/securing-ssh-connections-and-blocking-failures

The short version is:
* only allow key-based logins, never passwords
* use denyhosts or fail2ban
* change to a non-default port (any will do) - use port translation at the
router to make life easier, NOT on the server itself.
* do not allow direct root logins over ssh, even on the LAN.

On 02/17/2014 08:51 AM, Lightner, Jeff wrote:
> The reason why changing the port drops hits to near zero even if someone is doing a port scan is that the port scan doesn't tell them the port is ssh - just that it is open.   Of course doing a telnet to an open port might reveal that..
>
> The fail2ban idea is a good one.  So is using the high number but you CAN do nmap for high numbers - most people just don't.  Security is all about hardening so the bad guys move on to easier targets.  Nothing is really going to stop the determined folks specifically targeting you but it will keep out most of the hit and run types and script kiddies.

_______________________________________________
Ale mailing list
Ale at ale.org<mailto:Ale at ale.org>
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
Edward Holcroft | Madsen Kneppers & Associates Inc.
11695 Johns Creek Parkway, Suite 250 | Johns Creek, GA 30097
O (770) 446-9606<tel:%28770%29%20446-9606> | M (770) 630-0949<tel:%28770%29%20630-0949>

MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc. WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or privileged. If you are not the intended recipient, please notify the sender immediately then delete it - you should not copy or use it for any purpose or disclose its content to any other person. Internet communications are not secure. You should scan this message and any attachments for viruses. Any unauthorized use or interception of this e-mail is illegal.

Athena(r), Created for the Cause(tm)

Making a Difference in the Fight Against Breast Cancer

How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative to beverages that contain sugar, calories, etc. Your support of bottled water will make a difference! Your signatures count! Go to http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a petition to support your right to always choose bottled water. Help fight federal and state issues, such as bottle deposits (or taxes) and organizations that want to ban the sale of bottled water. Support community curbside recycling programs. Support bottled water as a healthy way to maintain proper hydration. Our goal is 50,000 signatures. Share this petition with your friends and family today!

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

_______________________________________________
Ale mailing list
Ale at ale.org<mailto:Ale at ale.org>
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
Edward Holcroft | Madsen Kneppers & Associates Inc.
11695 Johns Creek Parkway, Suite 250 | Johns Creek, GA 30097
O (770) 446-9606 | M (770) 630-0949

MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc. WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or privileged. If you are not the intended recipient, please notify the sender immediately then delete it - you should not copy or use it for any purpose or disclose its content to any other person. Internet communications are not secure. You should scan this message and any attachments for viruses. Any unauthorized use or interception of this e-mail is illegal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140218/9b01321f/attachment-0001.html>