On 12.01.2018 09:55, Adam Weremczuk wrote:
> For the future - would you recommend a list / forum better suited for
> these kinds of questions?
the debian-user mailing list is usually a good place for all debian
related questions.
best regards,
Ulf
That was it, working now.
Thank you Peter and everybody else who replied :)
For the future - would you recommend a list / forum better suited for
these kinds of questions?
On 11/01/2018 17:08, Peter Ludikovsky wrote:
Hi!
The change was possibly introduced in the latest release, with the
cha
On 11.01.2018 17:44, Adam Weremczuk wrote:
> 11437 read(4, "from=\"*.example.com\" ssh-rsa XX"..., 4096)
> = 4096
> Connection is established fine when I replace *.example.com with an IP
> address but that's not very scalable.
i guess, you ha
ting from 7.1
> landing at 9.2.
>
> I have a script running on another 7.1 machine which was connecting fine
> to 7.1 but now it fails after reading authorized_keys file as below:
>
> 11437 read(4, "from=\"*.example.com\" ssh-rsa XX"..., 4096)
>
Hi all,
I recently performed a series of distro upgrades starting from 7.1
landing at 9.2.
I have a script running on another 7.1 machine which was connecting fine
to 7.1 but now it fails after reading authorized_keys file as below:
11437 read(4, "from=\"*.example.com
В Sat, 31 Jan 2015 18:09:58 -0600
John Goerzen пишет:
> A friend of mine pointed out to me recently that the Debian Live CD
> has ssh open to the network by default, and the "user" account --
> which has passwordless sudo to root privileges -- has a password that
> is well-
Great news, thanks!
On 01/31/2015 07:01 PM, Evgeny Kapun wrote:
> This should be fixed in the latest version. See
> https://bugs.debian.org/741678.
>
> On 01.02.2015 03:09, John Goerzen wrote:
>> Hello,
>>
>> A friend of mine pointed out to me recently that the Deb
This should be fixed in the latest version. See https://bugs.debian.org/741678.
On 01.02.2015 03:09, John Goerzen wrote:
> Hello,
>
> A friend of mine pointed out to me recently that the Debian Live CD has
> ssh open to the network by default, and the "user" account -- wh
Hello,
A friend of mine pointed out to me recently that the Debian Live CD has
ssh open to the network by default, and the "user" account -- which has
passwordless sudo to root privileges -- has a password that is
well-known and easily found via Google. This poses some nasty surprises
session opened
for user root by (uid=0)
+++
and a password based sftp log in as (non-root) user shows:
+++
Dec 27 10:29:13 zopf sshd[3287]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=95.XX user=UU
Dec 27 10:29:13 zopf sshd[3287]: Accepted password fo
On Mon, 13 Jul 2009, Maik Holtkamp wrote:
> I decided to follow this and on the weekend iptables blocked about 70
> IPs. I am afraid that after some time the box will be DOSed by the
> crowded INPUT chain.
The only _real_ fix for that is to use IPSET (patch for netfilter) to deal
with IPv4, and co
Roger Bumgarner wrote:
ALLOW rules and SSH-keys. Using a non-standard port will stop the
majority of automated attackers, but a dedicated attack will find
you're SSH server: it only takes 20-30mins to portscan 1-65535.
Not necessarily:
http://jengelh.medozas.de/documents/Chaostables.pdf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Maik Holtkamp wrote/schrieb @ 13.07.2009 11:12:
> tail -n -20 | sed "s/^-A/-D/" | \
s/tail/head/
Sorry.
- --
- - bye maik
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Signature of Maik Holtkamp
iEYEARECAAYFAkpbA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Clemens Pfaffinger wrote/schrieb @ 07.07.2009 23:23:
> this is standard for me. I always change the port of the openSSH-server.
>
> My (current) solution is:
> Portsentry listens on port 22, while openSSH-server has another port.
> Every port sc
Peter Jordan writes:
> hmmm, although i have set supported enctypes
> supported_enctypes = aes256-cts:normal
> and restarted kdc nothing seens to have changed.
>
> After calling "kinit" klist -5e show me:
> Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc
> mode with HM
Russ Allbery, Fri Jul 10 2009 19:24:52 GMT+0200 (CEST):
> Peter Jordan writes:
>> Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):
>
>
>> But for new installations a change is not a bad idea?
>
> Yeah, for new installations it's generally best to start the master key
> at the strongest s
Peter Jordan writes:
> Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):
>> Yes. The master key isn't used on the network and changing it is
>> very difficult in lenny.
> But for new installations a change is not a bad idea?
Yeah, for new installations it's generally best to start the ma
Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST):
> Peter Jordan writes:
>
>> Let the option
>> master_key_type = des3-hmac-sha1
>> as it is?
>
> Yes. The master key isn't used on the network and changing it is very
> difficult in lenny.
But for new installations a change is not a b
On Fri, Jul 10, 2009 at 07:31:33AM -0700, Russ Allbery wrote:
> Peter Jordan writes:
> > We use NFSv4.
> I think the current version may have that same problem.
Urgs, yes.
Bastian
--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 346
"Boyd Stephen Smith Jr." writes:
> Russ Allbery wrote:
>> But yes, you don't want to get Kerberos tickets on an insecure system.
> I thought tickets only lasted for a small period of time, and could be
> expired early if need be so that you could use them on insecure
> machines.
True, you can g
In <87ws6gppyi@windlord.stanford.edu>, Russ Allbery wrote:
>Peter Jordan writes:
>> Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST):
>>> Not without applying custom patches that are rather a hack. You can,
>>> however, do PKINIT, which lets you use smart cards that can do X.509
>>> aut
ave not the
> choice.
Yeah, you're right -- that's a very hard one. Even ssh public key isn't
horribly attractive in that situation. You're basically betting that
whoever has hacked that cafe system has only installed a keyboard logger
and hasn't bothered to do something
Peter Jordan writes:
> Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):
>> However, if you also have AFS, which I recall that you do, you can't
>> turn it off at that level. You have to leave DES as a supported
>> enctype since the AFS service key at present still has to be DES
>> (althou
Peter Jordan writes:
> Let the option
> master_key_type = des3-hmac-sha1
> as it is?
Yes. The master key isn't used on the network and changing it is very
difficult in lenny.
> No change in /etc/krb5.conf required?
Correct. Clients will negotiate the strongest available encryption key
Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST):
> Peter Jordan writes:
>
>> btw is it possible to use any kind of one time password mechanism with
>> mit kdc?
>
> Not without applying custom patches that are rather a hack. You can,
> however, do PKINIT, which lets you use smart cards th
Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):
> Peter Jordan writes:
>> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
>
>
>
> However, if you also have AFS, which I recall that you do, you can't
> turn it off at that level. You have to leave DES as a supported enctype
> sin
Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST):
> Peter Jordan writes:
>> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
>
>>> Ensuring that you use AES enctypes for all keys (disable DES and
>>> ideally also 3DES)
>
>> How?
>
> In /etc/krb5kdc/kdc.conf, set the supported_encty
Peter Jordan writes:
> btw is it possible to use any kind of one time password mechanism with
> mit kdc?
Not without applying custom patches that are rather a hack. You can,
however, do PKINIT, which lets you use smart cards that can do X.509
authentication (some of which are quite inexpensive
Peter Jordan writes:
> Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
>> Ensuring that you use AES enctypes for all keys (disable DES and
>> ideally also 3DES)
> How?
In /etc/krb5kdc/kdc.conf, set the supported_enctypes configuration
option for your realm to:
supported_enctypes =
Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
> Peter Jordan writes:
>
>> It would be a stand alone MIT KDC (with krb-rsh) on debian lenny.
>>
>> "safe" in the sense of "you better attack the services which depends on
>> kerberos than kerberos itself"
>
> That's what we've done at Stan
Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST):
>
> Ensuring that you use AES enctypes for all keys (disable DES and ideally
> also 3DES)
>
How?
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
Peter Jordan writes:
> It would be a stand alone MIT KDC (with krb-rsh) on debian lenny.
>
> "safe" in the sense of "you better attack the services which depends on
> kerberos than kerberos itself"
That's what we've done at Stanford for many, many years, and I'm
comfortable doing so. The Debian
IT KDCs that
> are exposed to the world and, incidentally, derive much advantage by
> so doing.
In my experience, common practice in the Active Directory world is to
start by using VPN before doing anything else, which of course also
works (although I find it more annoying and difficult to use t
pod, Thu Jul 09 2009 21:38:31 GMT+0200 (CEST):
> Peter Jordan writes:
>
>> It is not my decission to isolate kerberos.
>>
>> Is it safe to open kerberos for the world?
>
> It's not clear that anyone on this list can answer that question since it
> depends on what "safe" and "kerberos" mean in th
Peter Jordan writes:
> It is not my decission to isolate kerberos.
>
> Is it safe to open kerberos for the world?
It's not clear that anyone on this list can answer that question since it
depends on what "safe" and "kerberos" mean in the context of your
organization. The meaning of "safe" is de
Russ Allbery, Thu Jul 09 2009 20:45:57 GMT+0200 (CEST):
> Peter Jordan writes:
>
>> I want to login passwordless to my ssh server from the internet. vpn
>> is not avaiable and kerberos is not acccessable from outside the
>> lan. How?
>
> Fix the last problem.
Peter Jordan writes:
> I want to login passwordless to my ssh server from the internet. vpn
> is not avaiable and kerberos is not acccessable from outside the
> lan. How?
Fix the last problem. Otherwise, yes, you can't use Kerberos.
Authentication systems really need to be
>
I want to login passwordless to my ssh server from the internet. vpn is
not avaiable and kerberos is not acccessable from outside the lan. How?
PJ
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The ISC has another diary entry on the exploit, voicing doubts about
it [1]. The original diary entry [2] doesn't have any more updates on
it, which is kind of a shame as that was where I was originally
tracking the story. Anyway, there it is and I'm sure we'll hear more
about it.
[1] http://isc
On Thu, Jul 09, 2009 at 06:02:37PM +0200, Peter Jordan wrote:
> > If you have Kerberos, why would you use ssh keys? GSS-API is so much
> > nicer if you already have a Kerberos environment.
>
> And how to login passwordless from outside the kerberos network?
There's no suc
Russ Allbery, Thu Jul 09 2009 17:04:06 GMT+0200 (CEST):
> Peter Jordan writes:
>> Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):
>
>
>> Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
>> problem, that the authorized_keys file is n
Peter Jordan writes:
> Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):
>> (Plus we've got Kerberos and don't usually mess around with keys or
>> passwords).
> Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
> problem, that the authori
Bernd Eckenfels schrieb:
In article you
wrote:
Besides I dont think you can force both, its only one stage in ssh protocol.
But your login shell could ask for the password via Terminal. Maybe with pam..
I think, you can, when you are hacking the source code of the server,
but i'
clarify this?
> Would you recommend stopping ssh completely and switching to remote control?
> Regards,
> Justus
>
>
I recompiled openssh lenny version for etch without problems. Are there
any reasons against installing this version in etch?
PJ
--
To UNSUBSCRIBE, em
d
> well-maintained setup like e.g. One-Time-Pads or such - because both can
> potentially be brute-forced way faster than SSH-keys.
Why not using PasswordAuthentication and/or
ChallangeResponseAuthetication like opie/otpw/freeauth? I think its
better then passwordless ssh keys and strong pa
Noah Meyerhans, Wed Jul 08 2009 23:13:30 GMT+0200 (CEST):
> (Plus we've got Kerberos and don't usually mess around with keys or
> passwords).
>
Do you use kerberos/nfsv4 and ssh keys? If yes, how you handle the
problem, that the authorized_keys file is not accessable withou
rce both, its only one stage in ssh protocol.
But your login shell could ask for the password via Terminal. Maybe with pam..
Greetings
Bernd
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Michael Stone wrote:
[A way to enforce non-empty passwd on ssh-keys]
> You can't, which is why it is useful to have both passwords and keys
> simultaneously--you can enforce a policy on a password.
To cite Noah Meyerhans from his recent mail - my users would shoot me if I ever
t
On Wed, Jul 08, 2009 at 11:18:43PM +0200, Sebastian Posner wrote:
Jim Popovitch wrote:
Is there a way to force keys AND passwd verification?
Normally you'd want to DISABLE PasswordAuthentication and
ChallengeResponseAuthentication
...
Something that would indeed be interesting is a way to en
n when it comes to
> PAM authentication. SSH-keys can (and should!) be password-protected
> already.
One of the big problems with ssh keys, though, is that there's no way
for an admin to force a user's key to be password protected. On
occasion, when there are other restrictions in place, pa
Jim Popovitch wrote:
> > ALLOW rules and SSH-keys.
>
> Is there a way to force keys AND passwd verification?
Normally you'd want to DISABLE PasswordAuthentication and
ChallengeResponseAuthentication - unless you have a special and well-maintained
setup like e.g. One-
As far as I know, it does keys first then falls back to passwords. I'd
imagine PAM could help, but I'm not knowledgeable enough in regards to
that. I know you're only limited by your imagination when it comes to
PAM authentication. SSH-keys can (and should!) be password-protected
al
On Wed, Jul 08, 2009 at 09:37:55AM -0700, Jim Popovitch wrote:
> On Wed, Jul 8, 2009 at 09:33, Roger Bumgarner
> wrote:
> > ALLOW rules and SSH-keys.
>
> Is there a way to force keys AND passwd verification?
That's actually a really good question. I would be interest
On Wed, Jul 8, 2009 at 09:33, Roger Bumgarner wrote:
> ALLOW rules and SSH-keys.
Is there a way to force keys AND passwd verification?
-Jim P.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ALLOW rules and SSH-keys. Using a non-standard port will stop the
majority of automated attackers, but a dedicated attack will find
you're SSH server: it only takes 20-30mins to portscan 1-65535.
-rb
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subje
Are you talking about trying the exploit on every single port? Then
>> they would really be stupid. Calling nmap makes that much faster.
>>
>> No the code must be fixed if there is a hole, nothi
ally be stupid. Calling nmap makes that much faster.
>
> No the code must be fixed if there is a hole, nothing else helps but
> turing off ssh.
>
> Best wishes
>
> Norbert
>
>
> ---
> Dr. No
ere is a hole, nothing else helps but
turing off ssh.
Best wishes
Norbert
---
Dr. Norbert Preining Vienna University of Technology
Debian Developer Debian TeX Group
gpg DSA: 0x09C5B094
>
>
Right you are!, but, don't forget that there are more than 65500 ports to
scan for ssh if it's not listening on the default one. I know, it's a matter
of time, but, almost the majority of "mortals" give up if SSH is not in 22.
Regards.
Hi,
this is standard for me. I always change the port of the openSSH-server.
My (current) solution is:
Portsentry listens on port 22, while openSSH-server has another port.
Every port scan attempt will result in a ban via iptables and every
connection to port 22 will also result in a ban via ipta
It's helpfull indeed but withe a portscan they can easly find the other port
of openssh.If have shutdown the openssh service untill i know wich version
is attackable by this exploit or when they have a solution for it.
Regards,
Jeroen
2009/7/7 Leandro Minatel
> Hi,
>
> a good practice, at leas
servers already.
>
> Do you think tcpwrapping ssh service is enough, or should i use iptables
> instead?
>
> Thanks in advance,
> Regards
>
> --
> Ramūnas Čereškevičius
>
> Tel.: +370 600 48 371
> El.p.: ramu...@techsupport.lt
>
> * UNIX/Linux serveriai
> *
Hi,
a good practice, at least for me, is put openssh to listen in a different
port than the default. I know, it's not the perfect solution.
Regards.
Is there Information on what Versions are affected by this exploit?
I read something of Version 3.2 and 4.3 in one of the blog entrys
(http://secer.org/hacktools/0day-openssh-remote-exploit.html), maybe
someone else could clarify this?
Would you recommend stopping ssh completely and switching to
de Moraes Holschuh
> As usual, you may want to either raise shields (i.e. disable/restrict
> access
> to the ssh service), or pay extra attention to what is happening on your
> SSH
> inbound gateways...
>
> http://lwn.net/Articles/340360/
> http://isc.sans.org/diary.
Hi all,
This is a serious security threat if it is not some sort of a duck (as
we call it in our country). I have firewalled some servers already.
Do you think tcpwrapping ssh service is enough, or should i use iptables
instead?
Thanks in advance,
Regards
--
Ramūnas Čereškevičius
Tel
As usual, you may want to either raise shields (i.e. disable/restrict access
to the ssh service), or pay extra attention to what is happening on your SSH
inbound gateways...
http://lwn.net/Articles/340360/
http://isc.sans.org/diary.html?storyid=6742
http://secer.org/hacktools/0day-openssh-remote
Personally I am using SSHBlack for that. Very powerful script.
Take a look there
http://www.pettingers.org/code/sshblack.html
Rgds,
2008/9/29 Brent Clark <[EMAIL PROTECTED]>
> Brent Clark wrote:
>
>> Michael Tautschnig wrote:
>>
>>> Hi all,
>>>
>>> since two days (approx.) I'm seeing an extrem
Brent Clark wrote:
Michael Tautschnig wrote:
Hi all,
since two days (approx.) I'm seeing an extremely high number of
apparently
coordinated (well, at least they are trying the same list of
usernames) brute
force attempts from IP addresses spread all over the world. I've got
denyhosts
and an
On Saturday 23 August 2008 04:28:32 Roger Bumgarner wrote:
> I think they're more interested in using your computer to participate
> in the botnet. sending spam / exploiting other machines is far more
> lucrative that holding Joe Nobody's machine for ransom. unplug +
> format = game over.
>
> -rb
7;t get hold of any passwords? Any ideas are welcome...
>>
>
> change port from 22 to 1 or someone you like
But this could break you in places where SSH acess is allowed but
other ports not like in academia networks.
I have saw some ssh attempts also in other ports instead of
Jack T Mudge III <[EMAIL PROTECTED]> writes:
> I'm quite open to other interpretations, and I'd be glad to hear what
> others think of this idea, but IMO, anyone attacking a linux machine is
> probably doing so for reasons other than running a botnet.
The brute force login attempts that we see, a
В Thu, 21 Aug 2008 16:33:51 +0200
Michael Tautschnig <[EMAIL PROTECTED]> пишет:
>
> Further, what do you guys do about such attacks? Just sit back and
> hope they don't get hold of any passwords? Any ideas are welcome...
>
change port from 22 to 1 or someone you like
--
wbr
Victor "Anana
> >> the root of these attacks.
> >>
> >> Well, probably I'm pretty naive in hoping that one could do anything
> >> about that at all, but maybe some of you are more experienced in
> >> security issues/dealing with CERTs, etc. and have some idea
ch attacks? Just sit back and hope
>> they don't get hold of any passwords? Any ideas are welcome...
>>
>> Thanks,
>> Michael
>
> redirect attackers to another port with a ssh honeypot with common attacked
> accounts and stupid passwords, let take over false infor
all, but maybe some of you are more experienced in security
> issues/dealing with CERTs, etc. and have some ideas what could be done.
>
> Further, what do you guys do about such attacks? Just sit back and hope
> they don't get hold of any passwords? Any ideas are welcome...
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Nevertheless, I'd like to do something about it more proactively,
you can play with psad, fwsnort and fwknop.
Greetings.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> On Thursday 21 August 2008 11:33:51 Michael Tautschnig wrote:
> > Hi all,
> >
> > since two days (approx.) I'm seeing an extremely high number of apparently
> > coordinated (well, at least they are trying the same list of usernames)
> > brute force attempts from IP addresses spread all over the w
On Thursday 21 August 2008 11:33:51 Michael Tautschnig wrote:
> Hi all,
>
> since two days (approx.) I'm seeing an extremely high number of apparently
> coordinated (well, at least they are trying the same list of usernames)
> brute force attempts from IP addresses spread all over the world. I've g
Micah Anderson wrote:
You could use dronebl, a dnsbl service, to check against and report
attacks to (http://headcandy.org/rojo/ for some examples using
fail2ban).
micah
Hi
Thanks for this.
It so obvious, I cant believe I didnt think of this myself.
Kind Regards
Brent Clark
--
To UNSUBSCR
On Thu, 21 Aug 2008 16:58:45 +0200, Michael Tautschnig writes:
>> * use a Firewall to prevent other IP address to connect to your ssh
>> service. restrict just to yours (iptables script can be easy to find on
>> the web)
>Well, I should have added that my hosts must be world-
On Thu, Aug 21, 2008 at 7:58 AM, Michael Tautschnig <[EMAIL PROTECTED]> wrote:
>> Third use a non standart ssh port (for example ) apt-get install fail2ban
>>
> I'm not a huge fan of security by obscurity, so I'd rather stick with 22 for
> now.
>
"S
> Third use a non standart ssh port (for example )
Michael Tautschnig <[EMAIL PROTECTED]> wrote:
> I'm not a huge fan of security by obscurity, so I'd rather stick with 22 for
> now.
Try it before you dismiss it out of hand.
Chris
--
To UNSUBSCRIBE, email to
> -Original Message-
> From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2008 5:21 PM
> To: Michael Tautschnig
> Cc: debian-security@lists.debian.org
> Subject: Re: What to do about SSH brute force attempts?
>
> On Thu, 21 Au
l iptables based firewall solution in place to mitigate these
since quite some time already and this seems to do the trick in terms of
blocking them fairly quickly.
Hi
Theres not much you can do.
Obviously you need to be using
SSH Protocol 2,
latest openssh server,
strong passwords for uses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Tautschnig wrote:
>> Yes, but could I really expect police to act "just because of a
>> bunch of hosts
>> being under attack?" And even more so, could I expect any police of
>> foreign countries to react?
No, probably not right now. But as mo
trigger a denyhosts DOS to
> > lock out anyone they want.
> >
>
> Hmm, no, not really - how would that work?
fail2ban and denyhosts watch log files for repeat failed ssh
authentication attempts from particular ips. Its quite trivial for a
non-privileged user to add entries to
lways write a script that will send an email after every SSH
> bruteforce attack to a mail address from whois database. That way you don't
> have to do it manually, and still you can do some good deed if someone has a
> server that's broken into, and is not (yet) aware of t
> * Michael Tautschnig <[EMAIL PROTECTED]> [2008-08-21 07:35-0400]:
> > Hi all,
> >
> > since two days (approx.) I'm seeing an extremely high number of apparently
> > coordinated (well, at least they are trying the same list of usernames)
> > brute
> > force attempts from IP addresses spread all
> Assuming that your system is secured as well as can be, and that your
> question is not about how to fend off attacks but rather how to stop your
> attackers from being able to continue, isn't this the kind of thing that the
> police or other law enforcement agencies would normally investigate?
>
* Michael Tautschnig <[EMAIL PROTECTED]> [2008-08-21 07:35-0400]:
> Hi all,
>
> since two days (approx.) I'm seeing an extremely high number of apparently
> coordinated (well, at least they are trying the same list of usernames) brute
> force attempts from IP addresses spread all over the world. I
On Thursday 21 August 2008 16:57:27 Max Zimmermann wrote:
> The problem with reporting the IPs is, that it can become a very big
> task, as the number of IPs denyhosts blocks increases.
You can always write a script that will send an email after every SSH
bruteforce attack to a mail a
On Thu, 21 Aug 2008, Michael Tautschnig wrote:
> > * use a Firewall to prevent other IP address to connect to your ssh
> > service. restrict just to yours (iptables script can be easy to find on
> > the web)
> Well, I should have added that my hosts must be world-wide access
re in the world where you can't really do them any harm,
> or are infected or compromised systems of people that don't know that
> their machines are running such 'attacks'.
>
> So I thing reporting is pretty much the only thing you can do. You won't
> be able t
ress criminal charges against anyone I think.
The problem with reporting the IPs is, that it can become a very big
task, as the number of IPs denyhosts blocks increases.
Another advice I can give is to change the SSH port. That minimized
bruteforces to almost zero for me.
So long.
--
Cheers,
Max
Linux-User #477672
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Hi,
>
> * use a Firewall to prevent other IP address to connect to your ssh
> service. restrict just to yours (iptables script can be easy to find on
> the web)
Well, I should have added that my hosts must be world-wide accessible using
password-based authentication, so th
Assuming that your system is secured as well as can be, and that your
question is not about how to fend off attacks but rather how to stop your
attackers from being able to continue, isn't this the kind of thing that the
police or other law enforcement agencies would normally investigate?
Sam
Hi,
* use a Firewall to prevent other IP address to connect to your ssh
service. restrict just to yours (iptables script can be easy to find on
the web)
* use Fail2ban which can ban ssh auth failure and create iptables rules.
(google can help your search about fail2ban)
Third use a non standart
On Thu, Aug 21, 2008 at 10:33 AM, Michael Tautschnig <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> since two days (approx.) I'm seeing an extremely high number of apparently
> coordinated (well, at least they are trying the same list of usernames) brute
> force attempts from IP addresses spread all over
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Tautschnig wrote:
> Nevertheless, I'd like to do something about it more proactively, so I also
> contact the abuse mailboxes as obtained from whois.
Thats pretty much the only thing you can do about it. But one should not
be too hopeful tha
1 - 100 of 1832 matches
Mail list logo
