In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu --- config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration + +# only allow version 2 of SSH protocol +Protocol 2 + +# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress :: + +# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3 +MaxSessions 5 + +# limit maximum instanctes +MaxStartups 5 + +# ensure proper logging +SyslogFacility AUTH +LogLevel INFO + +# always turn on strict mode +StrictModes yes + +# only allow safe crypto algorithms (may break some _very_ outdated clients) +# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com + +# enable data compression after successful login +Compression yes + +# only allow cryptographically safe SSH host keys (adjust paths if needed) +HostKey /etc/ssh/ssh_host_ed25519_key +HostKey /etc/ssh/ssh_host_ecdsa_key +HostKey /etc/ssh/ssh_host_rsa_key + +# only allow login via public key +PubkeyAuthentication yes +PasswordAuthentication no +ChallengeResponseAuthentication no +PermitEmptyPasswords no +AuthenticationMethods publickey + +# ignore user ~/.rhost* files +IgnoreRhosts yes + +# ignore user known hosts file +IgnoreUserKnownHosts yes + +# ignore user environments +PermitUserEnvironment no + +# do not allow any kind of forwarding (provides only low security) +# some of them might need to be re-enabled if SSH server is a jump platform +X11Forwarding no +AllowTcpForwarding no +AllowAgentForwarding no +PermitTunnel no +GatewayPorts no +PermitOpen none + +# close broken session (clients went offline, ...) automagically +TCPKeepAlive yes + +# EOF
Hey,
On Sun, 2018-08-19 at 20:41 +0200, Peter Müller wrote:
In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu
config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration
+# only allow version 2 of SSH protocol +Protocol 2
+# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress ::
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
+MaxSessions 5
Per user? Why?
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
See: https://bugzilla.ipfire.org/show_bug.cgi?id=11819
+# only allow cryptographically safe SSH host keys (adjust paths if needed) +HostKey /etc/ssh/ssh_host_ed25519_key +HostKey /etc/ssh/ssh_host_ecdsa_key +HostKey /etc/ssh/ssh_host_rsa_key
+# only allow login via public key +PubkeyAuthentication yes +PasswordAuthentication no +ChallengeResponseAuthentication no +PermitEmptyPasswords no +AuthenticationMethods publickey
+# ignore user ~/.rhost* files +IgnoreRhosts yes
+# ignore user known hosts file +IgnoreUserKnownHosts yes
+# ignore user environments +PermitUserEnvironment no
+# do not allow any kind of forwarding (provides only low security) +# some of them might need to be re-enabled if SSH server is a jump platform +X11Forwarding no +AllowTcpForwarding no +AllowAgentForwarding no +PermitTunnel no +GatewayPorts no +PermitOpen none
In the default configuration for the WebUI, TCP forwarding is enabled by default. So this is changed when SSH is being started for the first time.
+# close broken session (clients went offline, ...) automagically +TCPKeepAlive yes
+# EOF
-Michael
Hello Michael,
Hey,
On Sun, 2018-08-19 at 20:41 +0200, Peter Müller wrote:
In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu
config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration
+# only allow version 2 of SSH protocol +Protocol 2
+# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress ::
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
Is 30 seconds enough (default setting in IPFire 2.x)?
+MaxSessions 5
Per user? Why?
Because most users do not connect to a machine multiple times - at least not more than five times. Many active logins for one account are a clear indicator of compromise, especially if the account is only secured by a password.
OpenSSH default is 10, but this seems too high for me.
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH) can be used.
In case a system is older than that, I doubt it can be considered secure anymore.
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more for compression is more secure as it avoids possible zlib vulnerabilities to unauthenticated users (Simple, but I was unaware of it.):
Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.
Compression does not seem to have security impact to a SSH connection itself.
Because of the security risk described above, I'd prefer "delayed" as a setting to this in a second version of the patch.
[...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376... sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
Best regards, Peter Müller
-Michael
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, 2018-08-20 at 17:06 +0200, Peter Müller wrote:
Hello Michael,
Hey,
On Sun, 2018-08-19 at 20:41 +0200, Peter Müller wrote:
In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu
config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration
+# only allow version 2 of SSH protocol +Protocol 2
+# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress ::
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
Is 30 seconds enough (default setting in IPFire 2.x)?
Yes I think so. I don't even see that there is a huge desire in a very low limit. This only allows to brute-force a little bit faster. However, the keys should be virtually un-brute-force-able and therefore dividing the time you need to search by 10 isn't making any difference in practise.
+MaxSessions 5
Per user? Why?
Because most users do not connect to a machine multiple times - at least not more than five times. Many active logins for one account are a clear indicator of compromise, especially if the account is only secured by a password.
Well, true. But I often use an IPFire system as a jump host and for that open multiple connections.
OpenSSH default is 10, but this seems too high for me.
This sounds good to me.
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH) can be used.
Your first comment stated *very* outdated. One year isn't outdated.
PuTTY doesn't have an update mechanism and therefore will probably be installed once and never updated on the average admin's machine.
In case a system is older than that, I doubt it can be considered secure anymore.
Because of? Using RSA?
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more for compression is more secure as it avoids possible zlib vulnerabilities to unauthenticated users (Simple, but I was unaware of it.):
That is a different attack then.
The OpenVPN issue is about a known-plaintext attack which could also be done (in theory - I think) on SSH unless they add any random padding which would increase overhead and reduce the bandwidth savings of the compression.
Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.Compression does not seem to have security impact to a SSH connection itself.
Because of the security risk described above, I'd prefer "delayed" as a setting to this in a second version of the patch.
That doesn't have anything to do with the stated attack, so I guess it doesn't make much of a difference to me.
[...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376... sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
22 is now default, but of course the switch on the webUI should still work.
- -Michael
Best regards, Peter Müller
-Michael
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
Hello Michael,
[snip]
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
Is 30 seconds enough (default setting in IPFire 2.x)?
Yes I think so. I don't even see that there is a huge desire in a very low limit. This only allows to brute-force a little bit faster. However, the keys should be virtually un-brute-force-able and therefore dividing the time you need to search by 10 isn't making any difference in practise.
Provided people are using SSH keys, yes. We have had that discussion.
+MaxSessions 5
Per user? Why?
Because most users do not connect to a machine multiple times - at least not more than five times. Many active logins for one account are a clear indicator of compromise, especially if the account is only secured by a password.
Well, true. But I often use an IPFire system as a jump host and for that open multiple connections.
Hm, have you tried something like this for jumping (snip from ~/.ssh/config):
Host *.ipfire.org ProxyCommand ssh -q [proxy IP] nc %h %p
It avoids open SSH sessions on systems, which need some scheduled downtime entries in my network (paranoia...), so I am very happy with this. :-)
OpenSSH default is 10, but this seems too high for me.
This sounds good to me.
All right, I will use this value.
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH) can be used.
Your first comment stated *very* outdated. One year isn't outdated.
Talking about software updates, one year is _very_ outdated. Especially if you are running Windows. Assumption here is if a client cannot use a service because it is too old to support the cryptography required, it did not receive other important updates, too.
PuTTY doesn't have an update mechanism and therefore will probably be installed once and never updated on the average admin's machine.
You are right and I gnashingly agree in case of normal distributions. Talking about a firewall system, I do not. Similar to TLS 1.2, which we enforced a few Core Updates ago, we should enforce strong cryptography for SSH.
If an admin's machine does not support that because it is outdated, I couldn't care less.
In case a system is older than that, I doubt it can be considered secure anymore.
Because of? Using RSA?
Lack of updates (see above). RSA is a smaller (performance) problem in my eyes.
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more for compression is more secure as it avoids possible zlib vulnerabilities to unauthenticated users (Simple, but I was unaware of it.):
That is a different attack then.
ACK. Sorry for mixing things up here.
The OpenVPN issue is about a known-plaintext attack which could also be done (in theory - I think) on SSH unless they add any random padding which would increase overhead and reduce the bandwidth savings of the compression.
Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.Compression does not seem to have security impact to a SSH connection itself.
Because of the security risk described above, I'd prefer "delayed" as a setting to this in a second version of the patch.
That doesn't have anything to do with the stated attack, so I guess it doesn't make much of a difference to me.
[...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376... sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
22 is now default, but of course the switch on the webUI should still work.
Okay, thanks. Will send in a second version of this patch.
Best regards, Peter Müller
[snip]--
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2018-08-23 at 21:37 +0200, Peter Müller wrote:
Hello Michael,
[snip]
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
Is 30 seconds enough (default setting in IPFire 2.x)?
Yes I think so. I don't even see that there is a huge desire in a very low limit. This only allows to brute-force a little bit faster. However, the keys should be virtually un-brute-force-able and therefore dividing the time you need to search by 10 isn't making any difference in practise.
Provided people are using SSH keys, yes. We have had that discussion.
Or very long passwords.
+MaxSessions 5
Per user? Why?
Because most users do not connect to a machine multiple times - at least not more than five times. Many active logins for one account are a clear indicator of compromise, especially if the account is only secured by a password.
Well, true. But I often use an IPFire system as a jump host and for that open multiple connections.
Hm, have you tried something like this for jumping (snip from ~/.ssh/config):
Host *.ipfire.org ProxyCommand ssh -q [proxy IP] nc %h %p
It avoids open SSH sessions on systems, which need some scheduled downtime entries in my network (paranoia...), so I am very happy with this. :-)
No.
OpenSSH default is 10, but this seems too high for me.
This sounds good to me.
All right, I will use this value.
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH) can be used.
Your first comment stated *very* outdated. One year isn't outdated.
Talking about software updates, one year is _very_ outdated. Especially if you are running Windows. Assumption here is if a client cannot use a service because it is too old to support the cryptography required, it did not receive other important updates, too.
PuTTY doesn't have an update mechanism and therefore will probably be installed once and never updated on the average admin's machine.
You are right and I gnashingly agree in case of normal distributions. Talking about a firewall system, I do not. Similar to TLS 1.2, which we enforced a few Core Updates ago, we should enforce strong cryptography for SSH.
If an admin's machine does not support that because it is outdated, I couldn't care less.
I do care here. In this order: Security, Interoperability, Usability.
In case a system is older than that, I doubt it can be considered secure anymore.
Because of? Using RSA?
Lack of updates (see above). RSA is a smaller (performance) problem in my eyes.
So if there is a reason why RSA should not be used here anymore I would agree to drop it. Now, we are just diminishing interoperability without any gain in security. There is no point in that.
Performance? How many logins do you perform a second? Thousands? This matters for HTTPS maybe with hundreds or thousands of handshakes per second but not for SSH.
If you disable RSA in your client, you will still use the new fancy crypto stuff and save a couple of nanoseconds :)
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more for compression is more secure as it avoids possible zlib vulnerabilities to unauthenticated users (Simple, but I was unaware of it.):
That is a different attack then.
ACK. Sorry for mixing things up here.
The OpenVPN issue is about a known-plaintext attack which could also be done (in theory - I think) on SSH unless they add any random padding which would increase overhead and reduce the bandwidth savings of the compression.
Added a new compression method that delays the start of zlib compression until the user has been authenticated successfully. The new method ("Compression delayed") is on by default in the server. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.Compression does not seem to have security impact to a SSH connection itself. Because of the security risk described above, I'd prefer "delayed" as a setting to this in a second version of the patch.
That doesn't have anything to do with the stated attack, so I guess it doesn't make much of a difference to me.
[...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376... sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
22 is now default, but of course the switch on the webUI should still work.
Okay, thanks. Will send in a second version of this patch.
Best regards, Peter Müller
[snip]--
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
-
Michael Tremer -
Peter Müller