On 12/02/15 20:03, Warren Young wrote:
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port 2345/tcp
On 12/02/15 20:03, Warren Young wrote:
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port 2345/tcp
On 12/02/15 20:03, Warren Young wrote:
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port
On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:
On 02/13/2015 09:15 AM, Chris Adams wrote:
Yeah, the old move stuff to alternate ports thing is largely a waste
of time and just makes it more difficult for legitimate use. With
large bot networks and tools like zmap, finding services
Once upon a time, James Hogarth james.hoga...@gmail.com said:
If you really want to SSH to a port other than 22 for a little obscurity
use an iptables dnat to map the high port to local host 22 and block 22
from external connections.
Yeah, the old move stuff to alternate ports thing is largely
On 02/13/2015 09:15 AM, Chris Adams wrote:
Yeah, the old move stuff to alternate ports thing is largely a waste
of time and just makes it more difficult for legitimate use. With
large bot networks and tools like zmap, finding services on alternate
ports is not that hard for the bad guys.
On 02/13/2015 05:41 AM, James Hogarth wrote:
This is horrible advice anyway. It's not a good idea to run SSH on a port
greater than 1024 since if a crash exploit is used to kill the process a
non-root trojan process faking SSH to gather credentials could then bind on
that port trivially totally
Always Learning wrote:
On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:
On 02/13/2015 09:15 AM, Chris Adams wrote:
Yeah, the old move stuff to alternate ports thing is largely a waste
of time and just makes it more difficult for legitimate use. With
large bot networks and tools like
On Fri, February 13, 2015 9:05 am, Always Learning wrote:
On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote:
On 02/13/2015 09:15 AM, Chris Adams wrote:
Yeah, the old move stuff to alternate ports thing is largely a waste
of time and just makes it more difficult for legitimate use. With
On Feb 13, 2015, at 9:03 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote:
...changing port numbers...does not really add security. Security through
obscurity is only considered to be efficient by Windows folks.
“Security through obscurity” is an overused mantra of derision.
Originally,
On Fri, 2015-02-13 at 10:03 -0600, Valeri Galtsev wrote:
On Fri, February 13, 2015 9:05 am, Always Learning wrote:
I always change the SSH port to something conspicuously different. Every
server has a different and difficult to guess SSH port number with
access restricted to a few IP
On Fri, 2015-02-13 at 11:21 -0500, m.r...@5-cent.us wrote:
I disagree - I am in the waste of time camp. The reality is that only
script kiddies start out by trying 22 (and I *do* mean script kiddies -
I've seen attempts to ssh in that were obviously from warez, man, where
they were too
Hi,
Am 13.02.2015 um 09:48 schrieb Ned Slider:
On 12/02/15 20:03, Warren Young wrote:
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd
On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote:
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote:
On 02/13/2015 05:41 AM, James Hogarth wrote:
This is also why the Orange Book and its Rainbow kin exist (Orange Book =
5200.28-STD, aka DoD Trusted Computer System
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote:
On 02/13/2015 05:41 AM, James Hogarth wrote:
This is also why the Orange Book and its Rainbow kin exist (Orange Book =
5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria).
Should anyone care to learn from the
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port 2345/tcp --permanent
Also, it may be worth mentioning
Warren Young wrote:
Hi, just a quick note to whoever is maintaining this page:
http://wiki.centos.org/HowTos/Network/SecuringSSH
The procedure is missing the firewall-cmd calls necessary in EL7:
firewall-cmd --add-port 2345/tcp
firewall-cmd --add-port 2345/tcp --permanent
Also, it
On Tue, Apr 15, 2008 at 10:29:16AM -0700, Tim Alberts wrote:
Ned Slider wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get
Ned Slider wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
What's a good way to deal with this?
The
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
What's a good way to deal with this?
I use denyhosts
Tim Alberts wrote:
Ned Slider wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
What's a good way to deal
CentOS List wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
What's a good way to deal with this?
James A. Peltier wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
What's a good way to
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
What's a good way to deal with this?
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to get into the
system.
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and
I think the second I opened it every sorry monkey from around the
world has been trying every
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
The Wiki has an article
Trey Sizemore wrote:
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and
I think the second I opened it every
Rudi Ahlers wrote:
Trey Sizemore wrote:
On Fri Mar 28, 2008 07:47PM, Rudi Ahlers wrote:
Ray Leventhal wrote:
James A. Peltier wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and
I think the second I
On Wednesday 26 March 2008, Tim Alberts wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Peter Kjellstrom
Sent: 27. marts 2008 09:20
To: centos@centos.org
Subject: Re: [CentOS] Securing SSH
On Wednesday 26 March 2008, Tim Alberts wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think
And also try to pay a little with
AllowUsers user1 user2 user3
There might be a AllowGroup ??
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jes Struck
Sent: 27. marts 2008 14:03
To: 'CentOS mailing list'
Subject: RE: [CentOS] Securing SSH
Hey first
We have a public server and we did the following for SSH:
* Only Protocol v2
* Only key authentication, no password and large keys (just for the fun).
* Disable root login.
* Monitoring, we usually blacklists IPs trying to log in with many
unsuccessful attempts, using some custom scripts and
3. Install some brute force protection which can automatically ban an IP
on say 5 / 10 failed login attempts
The only software I know that could do this isn't supported anymore
(trisentry) or is too confusing and I don't know it yet (snort).
Suggestions?
denyhosts is pretty
Robert Spangler wrote on Tue, 25 Mar 2008 20:33:02 -0400:
Is an option but a waste of time as a scanner will find the port it was moved
to.
It's not a waste. Port scanning takes time, so, in general, those brute-force
bots just try port 22. Only if someone really wants to hack you and
On Wednesday 26 March 2008 07:31, Kai Schaetzl wrote:
The idea of only allowing for strict ip address is good but what if you
are on the move?
If you have a static IP address, this is not a problem. You VPN into your
home LAN and from there to the restricted machine.
If you are going
Robert Spangler wrote on Wed, 26 Mar 2008 08:03:48 -0400:
If you are going to use VPN then why not setup your remote site to use VPN
and
bypass SSH altogether then?
There could be several reasons, for instance:
1. SSH is all what is necessary
2. it's probably easier to have *one* VPN and
Kai Schaetzl wrote:
Robert Spangler wrote on Wed, 26 Mar 2008 08:03:48 -0400:
If you are going to use VPN then why not setup your remote site to
use VPN and bypass SSH altogether then?
There could be several reasons, for instance:
1. SSH is all what is necessary
2. it's probably easier
Bowie Bailey wrote on Wed, 26 Mar 2008 09:18:56 -0500:
Use VPN to connect to your network and then ssh through the VPN tunnel
to any machines you need to work with. This way only the VPN is exposed
to the Internet.
if the machines are within the LAN, yes. My original point was that if you
if the machines are within the LAN, yes. My original point was that if you
have a static IP address for your local LAN *and* you want to restrict the
*remote* machines to be ssh-connectable only from that LAN (which is a
good security measure) *and* you are on the road you can still work on
Kai Schaetzl wrote:
Bowie Bailey wrote on Wed, 26 Mar 2008 09:18:56 -0500:
Use VPN to connect to your network and then ssh through the VPN
tunnel to any machines you need to work with. This way only the
VPN is exposed to the Internet.
if the machines are within the LAN, yes. My
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
SSH question. Can I setup a
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
- keep your ssh up to date.
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
What's a good way to deal with this?
___
iptables, disallow root login via ssh, no valid shell for users that
don't need one, strong passwords, keys would be a good start.
Mike
On Tue, Mar 25, 2008 at 11:48 AM, Tim Alberts [EMAIL PROTECTED] wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
actually, those 'attempts' are coming from virus infected systems
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
FYI, here's a list of the losers (so far). I suggest everyone wish
On Tue, Mar 25, 2008 at 12:48 PM, Tim Alberts [EMAIL PROTECTED] wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
What's a
Mike Kercher wrote:
iptables, disallow root login via ssh, no valid shell for users that
don't need one, strong passwords, keys would be a good start.
Mike
iptables..add the ip of the attack source to reject? They keep moving
IP, this is very time consuming (but I am doing it). I don't
Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
1. Change the default port
I could do that, but if they already know about it, a simple port scan and
they'll probably find it again. Plus I gotta go tell all my client
programs the new port and I don't know how to do that on most of them (what
a hassle).
If you're talking about people
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
What's a good way to deal with this?
Tim Alberts wrote:
I got keys setup so I know
I'm talking to my server.
This is probably not what he meant. You can use a key pair to
authenticate with the SSH server and turn off password authentication
entirely. That makes password guessing attacks utterly impossible,
because the server
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
What's a good way to deal with this?
___
On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
What's a good way to
Tim Alberts wrote:
iptables..add the ip of the attack source to reject? They keep moving
IP, this is very time consuming (but I am doing it).
...
stop thinking 'they', that implies theres someone intentionally
targetting you. its just viruses randomly squirting out connection
requests
David Mackintosh wrote:
On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I think
the second I opened it every sorry monkey from around the world has been
trying every account name imaginable to get into the system.
John R Pierce wrote:
Tim Alberts wrote:
iptables..add the ip of the attack source to reject? They keep
moving IP, this is very time consuming (but I am doing it).
...
stop thinking 'they', that implies theres someone intentionally
targetting you. its just viruses randomly squirting out
Tim Alberts wrote:
David Mackintosh wrote:
On Tue, Mar 25, 2008 at 09:48:17AM -0700, Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the
world has been trying every account name imaginable to
Tony Placilla [EMAIL PROTECTED]
Sr. UNIX Systems Administrator
The Sheridan Libraries
Johns Hopkins University
On Tue, Mar 25, 2008 at 12:48 PM, in message [EMAIL PROTECTED],
Tim Alberts [EMAIL PROTECTED] wrote:
So I setup ssh on a server so I could do some work from home
Rudi Ahlers wrote:
Tim Alberts wrote:
... sounds great for getting around a remote dynamic IP address, but
some more authentication/security on that web page is necessary,
otherwise, anyone who finds that web page is given access?
___
Why?
What
John R Pierce wrote:
Rudi Ahlers wrote:
Tim Alberts wrote:
... sounds great for getting around a remote dynamic IP address, but
some more authentication/security on that web page is necessary,
otherwise, anyone who finds that web page is given access?
On Tue, Mar 25, 2008 at 11:28:45AM -0700, Tim Alberts wrote:
http://wiki.xdroop.com/space/Linux/Limited+SSH+Access
That sounds great for getting around a remote dynamic IP address, but
some more authentication/security on that web page is necessary,
otherwise, anyone who finds that web
On Tuesday 25 March 2008 17:00:18 James A. Peltier wrote:
Fail2Ban is a good brute force protector. It works in conjunction with
IPTables to block IPs that are attacking for a said duration of time.
And I can confirm that it's a doddle to set up. The defaults were fine for
me - nothing
Tim,
The important ones, imho --
1. disallow root login
2. disallow password authentication (use keys, as someone else has
described)
3. prevent multiple failed attempts using iptables:
# Log and block repeated attempts to access SSH
# See /proc/net/ipt_recent file for low-level data
# Block
On Tuesday 25 March 2008 12:55, Rudi Ahlers wrote:
Tim Alberts wrote:
So I setup ssh on a server so I could do some work from home and I
think the second I opened it every sorry monkey from around the world
has been trying every account name imaginable to get into the system.
68 matches
Mail list logo
