Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)
-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 scan attempt will result in a ban via iptables and every connection to port 22 will also result in a ban via iptables. 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. As I didn't find any mechanism in Lenny's portsentry package to automatically de-block the IPs I would try following cron script: - ---cut--- #!/bin/bash /sbin/iptables-save | grep ^-A INPUT | \ tail -n -20 | sed s/^-A/-D/ | \ while read line; do iptables $line; done /etc/init.d/portsentry restart - ---cut--- Which will keep the last 20 entries and skip everything else before restarting portsentry. However, I would greatly prefer a straight forward Debain way to smoothly delete the portsentry rules. Any ideas? TIA - -- bye maik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Signature of Maik Holtkamp iEYEARECAAYFAkpa+okACgkQz3bq6aadmI/PIQCeIm1E8e7jMoUGfxOq63///ERP 9ZYAn1bWCL6y91Y19ITvqiwZXPV9nkoU =V2tw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)
-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 iEYEARECAAYFAkpbA7wACgkQz3bq6aadmI9geQCbBsEOUXW1Gv7TqnFJjaB/f9nA O3kAnj958UiIghGGg2ZbJDyGHmPCGGkK =ULYK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 I've included something like: iptables -N deceive iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-proto-unreachable iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-net-prohibited iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-host-prohibited iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-port-unreachable iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-host-unreachable iptables -A deceive -m statistic --mode random --probability 0.003 -j REJECT --reject-with icmp-net-unreachable iptables -A deceive -p tcp -m statistic --mode random --probability 0.003 -j REJECT --reject-with tcp-reset iptables -A deceive -j DROP then some ALLOW rules: ... iptables -A INPUT -p tcp --dport $SSH_PORT -m hashlimit --hashlimit-name sshlimit --hashlimit-mode srcip --hashlimit-upto 25/minute --hashlimit-burst 25 --hashlimit-htable-expire 12 -j ACCEPT and then: iptables -A INPUT -j deceive That causes full portscan w/ nmap to take a week or so. Apart from that I use portsentry and fail2ban. Rgds, Marcin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)
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 config portsentry to run a script that just adds IPs to the proper set you used to block stuff. You can even add them with a builtin expire time, so that they get unblocked three days after they were inserted, or whatever... I really wish IPSET was merged upstream, but it must be lacking something fundamental to earn that right (IPv6 support, perhaps?), since it has been around for a long time now, and it is fully maintained. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 = aes256-cts:normal Note that you'll also need to enable rc4-hmac:normal if you need to do cross-realm trust with Active Directory, and you'll need to enable des3-hmac-sha1:normal if you have any Java 1.4 clients. 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 (although we're working on that). In that case, you have to deal with it at creation time for each principal. In other words, when you do addprinc or ktadd for everything other than the AFS service key, pass the -e aes256-cts:normal option to the command to force the enctypes to be restricted to 256-bit AES. Let the option master_key_type = des3-hmac-sha1 as it is? No change in /etc/krb5.conf required? should i renew all host keys? PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Fri Jul 10 2009 00:55:42 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 since the AFS service key at present still has to be DES (although we're working on that). In that case, you have to deal with it at creation time for each principal. In other words, when you do addprinc or ktadd for everything other than the AFS service key, pass the -e aes256-cts:normal option to the command to force the enctypes to be restricted to 256-bit AES. We use NFSv4. PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Fri Jul 10 2009 00:56:57 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 these days). We're evaluating the DESfire cards for our purposes. hmmm, that does not solve the problem, when i have to login from a insecure computer (ie Internet cafe) . I know, you have not connect to your network from insecure computers, but sometimes you have not the choice. PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 automatically. should i renew all host keys? Ideally, yes, since that will get them on AES only. If you have any existing keys that don't have AES keys, you do need to list fallback enctypes as supported until you've rekeyed them or you won't be able to authenticate to them. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 (although we're working on that). In that case, you have to deal with it at creation time for each principal. In other words, when you do addprinc or ktadd for everything other than the AFS service key, pass the -e aes256-cts:normal option to the command to force the enctypes to be restricted to 256-bit AES. We use NFSv4. I think the current version may have that same problem. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 authentication (some of which are quite inexpensive these days). We're evaluating the DESfire cards for our purposes. hmmm, that does not solve the problem, when i have to login from a insecure computer (ie Internet cafe) . I know, you have not connect to your network from insecure computers, but sometimes you have 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 that would let them grab your ssh private key as well. But yes, you don't want to get Kerberos tickets on an insecure system. As portable systems (handhelds, laptops, etc.) and ubiquitous wireless becomes more common, hopefully there will be less need to use computers that you don't physically control. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
In 87ws6gppyi@windlord.stanford.edu, Russ Allbery wrote: Peter Jordan usernetw...@gmx.info 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 authentication (some of which are quite inexpensive these days). We're evaluating the DESfire cards for our purposes. hmmm, that does not solve the problem, when i have to login from a insecure computer (ie Internet cafe) . I know, you have not connect to your network from insecure computers, but sometimes you have not the choice. 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. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: HEAD's UP: possible 0day SSH exploit in the wild
Boyd Stephen Smith Jr. b...@iguanasuicide.net 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 get limited-lifetime tickets, which is a bit safer since any attacker would have to use them right away. If you can get them without exposing your key material (using PKINIT, for instance), that could be a possible solution. You obviously don't want to get password-based tickets from an untrusted machine. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Fri, Jul 10, 2009 at 07:31:33AM -0700, Russ Allbery wrote: Peter Jordan usernetw...@gmx.info 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 3468.1 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Fri Jul 10 2009 16:31:14 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 bad idea? No change in /etc/krb5.conf required? Correct. Clients will negotiate the strongest available encryption key automatically. How can i see that the change has worked? should i renew all host keys? Ideally, yes, since that will get them on AES only. If you have any existing keys that don't have AES keys, you do need to list fallback enctypes as supported until you've rekeyed them or you won't be able to authenticate to them. It seems to work without renewing old keys (host/nfs). How can i see which enctypes the keys have. btw. if i list the principal for me in kadmin.local there are no values for Last successful authentication / Last failed authentication and ailed password attempts although the EQUIRES_PRE_AUTH Attribute is set: get_principal peter Principal: pe...@example.com [...] Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 6 Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 1, DES cbc mode with CRC-32, no salt Key: vno 1, DES cbc mode with RSA-MD5, Version 4 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3 Attributes: REQUIRES_PRE_AUTH Policy: [none] Do you know what is wrong? thank you very much! PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 master key at the strongest supported key type. MIT 1.7 supports rekeying, though, which makes things much simpler. Correct. Clients will negotiate the strongest available encryption key automatically. How can i see that the change has worked? klist -e will show you the enctypes of the tickets in your cache. You can also check the enctypes of the tickets issued by the KDC in the KDC logs, although those are numeric and a bit less easy to understand. It seems to work without renewing old keys (host/nfs). How can i see which enctypes the keys have. kadmin examine on those principals. btw. if i list the principal for me in kadmin.local there are no values for Last successful authentication / Last failed authentication and ailed password attempts although the EQUIRES_PRE_AUTH Attribute is set: Those fields aren't actually maintained in the database. (There is code to do so, but it's ifdefed out and has serious problems.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Fri Jul 10 2009 19:24:52 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 supported key type. MIT 1.7 supports rekeying, though, which makes things much simpler. How can i see that the change has worked? klist -e will show you the enctypes of the tickets in your cache. You can also check the enctypes of the tickets issued by the KDC in the KDC logs, although those are numeric and a bit less easy to understand. 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 HMAC/sha1 PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 HMAC/sha1 It sounds like removing something from supported_enctypes in the KDC may not turn things off to quite the degree that I thought it would and if only old keys are available, old keys are still used. You'll need to change your krbtgt key in order to get newer enctypes for your ticket-granting tickets. You'll want to use -keepold unless you can afford a flag day that invalidates all existing ticket caches. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Sebastian Posner, Wed Jul 08 2009 23:18:43 GMT+0200 (CEST): Jim Popovitch wrote: 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-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 passwords and fail2ban should help against brute-force. PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Justus, Tue Jul 07 2009 22:36:31 GMT+0200 (CEST): 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 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, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Bernd Eckenfels schrieb: In article f971bab40907080937v33884e78nce8291d34140f...@mail.gmail.com 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'm not into the source code ... If you try to connect with an invalid key, the server can fall back to password authentication. This works transparently on the clients i use. So you possibly can change the code of the server in this way: - remember if there was a valid authentication by key, but deny it - if there is a valid password authentication, only accept it, when you remembered a valid key auth I would not suggest this. It is confusing for the user. And in my opinion, there are better solutions: - let the server listen on another port - use fail2ban - put a fail2ban minefield around the other port - drop invalid packets - use port knocking Yes, there are pros and cons. I dont know a good port knocking server. The ones i testet had static keys, what you don't want. Better would be dynamic keys, maybe with first a knocking sequence by time and later by password with answers on port knock daemon. You could distribute working portknocking clients to your customers. If you have windows customers, you can distribute putty-configurations as reg-files. Possibly this works with winscp to. At least you can take over putty-configs to winscp in a rather hidden menu-button on the very first startwindow. http://en.wikipedia.org/wiki/Port_knocking As an alternative to port knocking, you could use web based knocking, which is more difficult to set up. With knocking in general you lock the syn-packages on your ssh-port and unlock it for a certain time, after receiving a valid knock-sequence an another port-range. However you set up. Keep one important thing in mind: Try to manage your system in a way, that if an atacker cracked the access of one customer, he can't affect changes on other customers. That is not an easy task on ordinary web servers. You always have customers, that are not sensible to security. And even if your customers are smart, but have in spite of a cracked system, the malware could record both there passwords and the passphrase of the encrypted private key ... If the malware was smart, it coul even get between you and the terminal window, install it's own public key on the server and try to hide this action from your cutomers by clearing the screen and closing the connection. So just keep insecure customers from having influence on your system or other customers. Greeting, Guntram -- Guntram Trebs freier Programmierer und Administrator g...@trebs.net +49 (30) 42 80 61 55 +49 (178) 686 77 55 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 authorized_keys file is not accessable without a krb ticket? If you have Kerberos, why would you use ssh keys? GSS-API is so much nicer if you already have a Kerberos environment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Thu Jul 09 2009 17:04:06 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 not accessable without a krb ticket? 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? PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 such thing as outside the kerberos network. noah signature.asc Description: Digital signature
Re: HEAD's UP: possible 0day SSH exploit in the wild
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.sans.org/diary.html?storyid=6760 [2] http://isc.sans.org/diary.html?storyid=6742 -- Matt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Noah Meyerhans, Thu Jul 09 2009 18:04:54 GMT+0200 (CEST): On Thu, Jul 09, 2009 at 06:02:37PM +0200, Peter Jordan wrote: And how to login passwordless from outside the kerberos network? There's no such thing as outside the kerberos network. noah 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
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 defined by the organizational security policy and the meaning of kerberos will depend on which implementation has been used. For example there seems to be a school of thought amongst certain deployers of Active Directory (a component of which is a kerberos KDC) that it should not be exposed more widely than strictly necessary. There are however plenty of deployments of Heimdal and MIT KDCs that are exposed to the world and, incidentally, derive much advantage by so doing. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Thu Jul 09 2009 20:45:57 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 exposed to all sites from which one wishes to authenticate or they're not horribly helpful. It is not my decission to isolate kerberos. Is it safe to open kerberos for the world? PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
pod, Thu Jul 09 2009 21:38:31 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 defined by the organizational security policy and the meaning of kerberos will depend on which implementation has been used. For example there seems to be a school of thought amongst certain deployers of Active Directory (a component of which is a kerberos KDC) that it should not be exposed more widely than strictly necessary. There are however plenty of deployments of Heimdal and MIT KDCs that are exposed to the world and, incidentally, derive much advantage by so doing. 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 PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
pod p...@herald.ox.ac.uk writes: For example there seems to be a school of thought amongst certain deployers of Active Directory (a component of which is a kerberos KDC) that it should not be exposed more widely than strictly necessary. There are however plenty of deployments of Heimdal and MIT 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 than just using ssh with an externally exposed Kerberos server). Certainly, anything you expose to the world can be attacked. If you allow anyone to hit your Kerberos server, your Kerberos server can be attacked. If you allow anyone to hit your ssh servers with public key authentication enabled, the public key authentication can be attacked. Both ssh and Kerberos KDCs are treated with special care and concern for security issues and generally have a very fast turn-around time for fixes and updates. I personally am comfortable exposing UNIX-based Kerberos KDCs to the Internet. I have no expertise with running Active Directory and cannot comment there. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 MIT Kerberos maintainers (of which I'm one) receive advance notice of upcoming security vulnerability announcements and always prepare security updates in advance for any KDC vulnerabilities. The one additional vulnerability that you do open is brute-force attacks on weak keys, which generally means password-based keys since the randomly-generated service keys are generally too strong to bother with. Ensuring that you use AES enctypes for all keys (disable DES and ideally also 3DES) and that your users have to pick strong passwords should eliminate most of that concern. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Russ Allbery, Thu Jul 09 2009 21:51:50 GMT+0200 (CEST): Peter Jordan usernetw...@gmx.info 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 MIT Kerberos maintainers (of which I'm one) receive advance notice of upcoming security vulnerability announcements and always prepare security updates in advance for any KDC vulnerabilities. btw is it possible to use any kind of one time password mechanism with mit kdc? thanks, PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 = aes256-cts:normal Note that you'll also need to enable rc4-hmac:normal if you need to do cross-realm trust with Active Directory, and you'll need to enable des3-hmac-sha1:normal if you have any Java 1.4 clients. 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 (although we're working on that). In that case, you have to deal with it at creation time for each principal. In other words, when you do addprinc or ktadd for everything other than the AFS service key, pass the -e aes256-cts:normal option to the command to force the enctypes to be restricted to 256-bit AES. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Peter Jordan usernetw...@gmx.info 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 these days). We're evaluating the DESfire cards for our purposes. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Tue, Jul 7, 2009 at 6:20 PM, Jeroen van Drongelen jer...@naturewebdesign.eu wrote: 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 leandromina...@gmail.com 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. 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.
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Mi, 08 Jul 2009, Leandro Minatel wrote: Right you are!, but, don't forget that there are more than 65500 ports to ??? 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, nothing else helps but turing off ssh. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LUSBY (n.) The fold of flesh pushing forward over the top of a bra which is too small for the lady inside it. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 8, 2009 at 11:38 AM, Norbert Preining prein...@logic.at wrote: On Mi, 08 Jul 2009, Leandro Minatel wrote: Right you are!, but, don't forget that there are more than 65500 ports to ??? 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, nothing else helps but turing off ssh. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LUSBY (n.) The fold of flesh pushing forward over the top of a bra which is too small for the lady inside it. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org No, of course not. Maybe I expressed myself not in a proper way, sorry, english is not my natural language. AFAIK, nmap, by default, scan ports from 1 to 1024 and those listed in nmap-services. This allows me to hide ssh-server for the majority of mortals. BTW, I agree with you, the code must be fixed, no doubt at all. Regards Leandro
Re: HEAD's UP: possible 0day SSH exploit in the wild
just update it! 2009/7/8 Leandro Minatel leandromina...@gmail.com On Wed, Jul 8, 2009 at 11:38 AM, Norbert Preining prein...@logic.atwrote: On Mi, 08 Jul 2009, Leandro Minatel wrote: Right you are!, but, don't forget that there are more than 65500 ports to ??? 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, nothing else helps but turing off ssh. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LUSBY (n.) The fold of flesh pushing forward over the top of a bra which is too small for the lady inside it. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org No, of course not. Maybe I expressed myself not in a proper way, sorry, english is not my natural language. AFAIK, nmap, by default, scan ports from 1 to 1024 and those listed in nmap-services. This allows me to hide ssh-server for the majority of mortals. BTW, I agree with you, the code must be fixed, no doubt at all. Regards Leandro
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 8, 2009 at 09:33, Roger Bumgarnerroger.bumgar...@gmail.com 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
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 08, 2009 at 09:37:55AM -0700, Jim Popovitch wrote: On Wed, Jul 8, 2009 at 09:33, Roger Bumgarnerroger.bumgar...@gmail.com 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 interested in knowing how to do that. jamie. signature.asc Description: Digital signature
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 already. -rb On Wed, Jul 8, 2009 at 9:37 AM, Jim Popovitchjim...@gmail.com wrote: On Wed, Jul 8, 2009 at 09:33, Roger Bumgarnerroger.bumgar...@gmail.com 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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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-Time-Pads or such - because both can potentially be brute-forced way faster than SSH-keys..unless you happen to use a key generated with one of those funny buggy random-sources from the past, in which case a well-maintained sshd nowadays will simply reject your key. Something that would indeed be interesting is a way to enforce that the PRIVATE KEY is password-protected - sadly, you can't see this from the public key, and I'm not aware of any possibility to query the client concerning this specific matter. Sebastian -- baboo -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 08, 2009 at 02:03:57PM -0700, Roger Bumgarner wrote: 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 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, passwordless keys are a good thing and can be used safely, but when used to access a user's account, they're always bad. Also, since ssh public key auth isn't handled by PAM, I don't believe there's a way to use PAM to require both keys and passwords. I could be wrong, though. My users would shoot me if I ever tried such a thing. (Plus we've got Kerberos and don't usually mess around with keys or passwords). Not that any of this will help if this alleged sshd vulnerability can be triggered prior to authentication. noah signature.asc Description: Digital signature
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 tried such a thing. Sadly, I'm not their bossbut they are more or less my customers, so putting a security policy in place requiring the previously stated mechanism would be more like starting a war than a small skirmish. Sebastian -- baboo -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
In article f971bab40907080937v33884e78nce8291d34140f...@mail.gmail.com you wrote: Is there a way to force keys AND passwd verification? You know that if its a protocol exploit (which is quite likely) that will not help you much. tcpwrapper itself or ipfilter acts quite early in the protocol stack - that might help. 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.. Greetings Bernd -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 without a krb ticket? PJ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
HEAD's UP: possible 0day SSH exploit in the wild
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-exploit.html Yes, it could be a hoax, and I sure hope that's all it is... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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.: +370 600 48 371 El.p.: ramu...@techsupport.lt * UNIX/Linux serveriai * Kompiuterių tinklai * Internetinių svetainių kūrimas * Konsultacijos www.techsupport.lt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
Hi, thanks for this information! I just hope that this is a hoax. What would you suggest for securing a server running openSSH? How can I notice such an attack in my log files? Cheers Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Henrique de Moraes Holschuh h...@debian.org 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-exploit.html Yes, it could be a hoax, and I sure hope that's all it is... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 remote control? Regards, Justus -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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.
Re: HEAD's UP: possible 0day SSH exploit in the wild
As i have read on this page : http://secer.org/hacktools/0day-openssh-remote-exploit.htmlhttp://secer.org/hacktools/0day-openssh-remote-exploit.htmlit say's that the attack is againt OpenSSH version 4.3. So the best thing that you can do is update OpenSSH to a newer version. But again it are still rumors and i don't know if a version higher then 4.3 is also attackable by the exploit 2009/7/7 Ramunas / techsupport.lt ramu...@techsupport.lt 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.: +370 600 48 371 El.p.: ramu...@techsupport.lt * UNIX/Linux serveriai * Kompiuterių tinklai * Internetinių svetainių kūrimas * Konsultacijos www.techsupport.lt -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 leandromina...@gmail.com 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.
Re: HEAD's UP: possible 0day SSH exploit in the wild
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 iptables. Regards Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Clemens Pfaffinger clpfaffin...@gmail.com 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 iptables. Regards Kontaktinformationen clem...@csrv.at www.cdev.at 2009/7/7 Leandro Minatel leandromina...@gmail.com 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.
