Successful UTM install with HDMI, fix for stall at 66% on Hardware Detection

Hello,
thanks for the info
I followed your procedure but I have a error "bus error (core dump)" someone would have an idea, please?

I am in the same boat, i have a brand new SG230 that came with 9.500 preinstalled. I have to stay on 9.4 though because WAF from 9.5 wont work with https on windows server 2003 and we still have ONE.

Anyways so i tried to re-image the SG230 with ssi-9.414-2.1 and even ssi-9.358-3.1, both times the setup "hangs" on 66% Hardware Detection.

If i unplug the HDMI Port, Setup reports that no Appliance Hardware is detected.

If i try running the bootstrap --install command again i get the same "bus error (core dump)" and cant proceed.

Have you managed to solve this somehow ? This cant be faulty hardware, seems more like an HDMI issue to me.

You definitely want to get a case open with Support.

What is your current hardware appliance running 9.4? Is it on 9.413?

Cheers - Bob

We have Support Case open, as it turns out SG230 Rev2 only supports 9.500 upward. Our Partner tries to find a solution as we cannot go to 9.5 right now.

Our "old" UTM220 Cluster is on 9.415-1.

I would urge you to upgrade that new unit to 9.506 and to restore your 9.415 backup to it - it may do everything you need.  If not, look for a PM from me.

Cheers - Bob

Well if i could use 9.5+ i would not have the problem of re-imaging the rev2 sg230 with 9.4 :)

But as we learned the hard way, sophos in all its wisdom removed support for old (insecure) cyphers for the WAF in the 9.5 branch. This essentially breaks all HTTPS/SSL WAF applications running on older IIS. For us this was OWA running on our (sill win2k3) Exchange server.

We had our UTM 220 cluster upgraded to 9.502 (i think) and after a day analysing what the heck was going on and why our OWA / ActiveSync suddenly stopped working came to the conclusion that Sophos just removed thos cyphers with no way for the customer to work around this fact. The proxy not giving any information about it, just closing the connection.

I have found no indication that sophos is or will ever bring back support for these cyphers, leaving old IIS WAF SSL applications at "just not working with 9.5". So we cannot move to 9.5 until we have moved the Exchange setup to a newer OS (wich wont happen untill mid-next year).

We and our partner are trying to get our hands on a SG230 rev1 test Appliance from the distributor to be able to run 9.4 for the time beeing.

It should be possible to add those ciphers at the command line, and then remove them.  I don't know if first-level support knows how to do that, so I would immediately ask for escalation if you do try to go that direction.

Cheers - Bob

It should be possible to add those ciphers at the command line, and then remove them.  I don't know if first-level support knows how to do that, so I would immediately ask for escalation if you do try to go that direction.

Cheers - Bob

Well our partner had a ticket open at sophos support, though i dont know what level that is.

The answer (sorry in german) was:

"da Windows Server 2003 mittlerweile Out of Life ist wird dieser von uns nicht mehr supported.

Gerade im Zuge der Updates auf 9.5xx wurden die unsicheren Ciphers deaktiviert/entfernt.

Diese werden im Zuge weiterer Updates auch nicht mehr eingespielt, dies würde von unseren DEVs auch geblockt werden, da wir hierdurch ein Security Downgrade nicht nur riskieren, sondern wissentlich in Kauf nehmen würden und für Sie eine Version handeln müssten bei welcher dieser Change Update sicher ist."

So basically they would not help us re-enable those chipers. 

Many years ago, I worked in German for IBM Deutschland in Berlin for a year, so I understand - German support did not want to help or they didn't know how.  In fact, I didn't see any difference in the accepted ciphers.

Looking at 9.413 in a VM and 9.506 in our lab, I see only one line that needs to change in /var/chroot-reverseproxy/usr/apache/conf/reverseproxy.conf

Replace SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 with SSLProtocol all -SSLv2 -SSLv3

You might try just adding +SSLv1 to the line instead of replacing it with the line from 9.413.  If you try either approach and it works, please report back.  

Cheers - Bob

I think our partner tried that approach, modifying the reverseproxy.conf. But i'm not sure what the exact changes where.

I will try to test that next week, i dont have exchange servers lying around in our test-setup so i hope ill find some off-hours.

Thank you for your efford Bob.

I am digging into this right now. As it turns out, the reverseproxy.conf gets generated on multiple occasions:

a) on boot. no vhosts but the following content:

KeepAlive On
ServerName XY
ServerAdmin XY
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:ECDH+3DES:DH+3DES:RSA+3DES:!aNULL:!MD5:!DSS
ProxyProtocol Off

b) it appears the reverseproxy is trying to reach the local webserver and adds the WAF vhost only after success.

So basically we can't work around the SSLProtocol this way.

I suscpect the "template" (empty reverseproxy.conf) is coming from the database, at least thats how i would do it and i cant find any other template with these vars around.

There might be a way to overwrite those settings with a mod_ssl.conf or by setting SSLProtocol in the httpd.conf _after_ Include conf/reverseproxy.conf

But then ... i am not so sure if and when the httpd.conf might get overwritten.

Is there something like apachectl configtest for the reverseproxy?

UPDATE: tried to add SSLProtocol all -SSLv2 -SSLv3 at the bottom of httpd.conf to overwrite reverseproxy.conf, that didnt work.

The solution to this is cc set reverse_proxy min_tls 1 at the command line or as SteveU points out, look for 'Minimum TLS version:' on the 'Advanced' tab of 'Web Application Firewall'.

Cheers - Bob