On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote:
> On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen 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 Evaluat
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen 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 Rainbow Books
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
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
> On Feb 13, 2015, at 9:03 AM, Valeri Galtsev 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, it was a cry against sy
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
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 legitimat
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 c
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
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".
Once upon a time, James Hogarth 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 a waste
of time an
> 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
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 2
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
>
>
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 into
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?
>> 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
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 Wi
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 open
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 sor
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 he
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
> wor
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.
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 d
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
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
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
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.
-
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 g
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.
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
y
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
>> 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?
OSSEC-HIDS is pretty good.
_
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 probab
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
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 g
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 espec
> >> 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
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 iptab
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.
>
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 attem
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 ne
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
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?
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 is
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 fro
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 ge
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 co
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.
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 fro
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
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 w
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 peo
John R Pierce 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.
actually, those 'attempts' are coming from vir
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?
__
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 al
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
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
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 wh
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.
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 secon
65 matches
Mail list logo