Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASL disk thrashing and slow response when using webadmin?

Hi, I've just installed ASL to test it, P3-800 with 256mb ram. I have not connected the box to an external network, just using a back to back ethernet cable to connect to eth0 to set it up
via the web interface.

I notice login is slow via the webadmin, once logged in, access to any pages is very slow and the ASL box disk light is continually on (as though it is very busy doing something), this seems to coincide with me trying to load any pages from the web interface?

I tried to look at the process(es) that seem to be stressing the box each time I hit a page but could not really come up with anything definite?
'top' might have been nice here  [:)] 

Any pointers please.

thanks
Mike


This thread was automatically locked due to age.
Parents
  • Mine did that before I connected it to the lan.

    have you got any of the proxies turned on?

    Try loggin in via the console and running 'uptime' and do a ps axuw| more to see what its upto.

    mogul
  • Have connected the box to the outside world and configured DNS proxy, I can resolve hostname ok now.
    However still VERY slow when doing anything from the webadmin.
    After issuing a command, then jumping to a ssh login to the ASL, I notice:-

    wwwrun   24372  2.0 21.5 17476 6616 ? D   22:47   0:00 index.pl

    2.0 is the %CPU and 21.5 %MEM.

    This is the highest CPU process and memory. When the page is loaded the ssh login becomes responsive again.

    Any more pointers please? Its really too slow to do any serious config of it.  [:(] 

    thanks
    Mike
  • Weird, is nobody else seeing this? This is a stock install of ASL. I have applied the up2date stuff as well.
    Cant believe I am the only one?

    Practically all that is configured are 3 interfaces, lan, internet and dmz.

    Thanks
    Mike
Reply
  • Weird, is nobody else seeing this? This is a stock install of ASL. I have applied the up2date stuff as well.
    Cant believe I am the only one?

    Practically all that is configured are 3 interfaces, lan, internet and dmz.

    Thanks
    Mike
Children
  • I've done a little more investigation of this slow webadmin access. Whilst poking around I noticed a possible error in /etc/host.conf.
    there is a line which is like this:-

    order hosts bind

    As far as I know this hould be:-

    order hosts,bind

    Anyway, changing that did not fix it, so I did a tail -f on /var/log/http.ssl_engine_log whilst loading a webadmin page, here is what I see:-

    [14/Dec/2001 21:21:11 02252] [info]  Connection to child 1 established (server asl.yourdomain.com:443, client 192.168.1.10)
    [14/Dec/2001 21:21:11 02252] [info]  Seeding PRNG with 1160 bytes of entropy
    [14/Dec/2001 21:21:11 02252] [info]  Connection: Client IP: 192.168.1.10, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits)
    [14/Dec/2001 21:21:11 02252] [info]  Initial (No.1) HTTPS request received for child 1 (server asl.yourdomain.com:443)
    [14/Dec/2001 21:21:29 02252] [info]  Connection to child 1 closed with unclean shutdown (server asl.yourdomain.com:443, client 192.168.1.10)


    What is the "unclean shutdown" ? Notice it takes 18 seconds to load that page, in this case it was the toplevel "System" info page.

    Does this provide any further help with my problem?

    thanks
    Mike
  • What is an 'unclean shutdown'?  Well settle in for a long story--

    This has absolutely nothing to do with your firewall.  In order to insure that a bad person could not conduct a truncation attack against a SSLv3 or TSL encrypted link, a protection was built in.  A truncations attack would occur if someone sent a spoofed TCP packet with the FIN flag set before the actual SSL transaction finished.  To protect against this, the SSL standard specifies you must send an encrypted SSL alert called close_notify before a SSL connection can be closed by a standard TCP four way closure.  Failure to do this results in an unclean shutdown, and the SSL session hanging waiting for the proper closure until eventually it times out.  

    The biggest problem is that Microsoft IE does not follow the standard with regard to close_notify.  The data can not be displayed until the session is closed.  Some implementations correctly follow the standard and disregard an entire session that is not closed correctly, some just wait for it to time out then log it like you see in the log file.
    I see this everyday, implementors really should read the standard.

    http://home.netscape.com/eng/ssl3/draft302.txt

    and 

    Section 7.19 of Eric Rescorla's "SSL and TLS: Designing and Building Secure Systems"

    Eric's site is www.rtfm.com (wish I'd have thought of that one) he is also the author of SSLDump
  • Thanks for the information. I thought I'd try another browser, downloaded Mozilla 0.97. I still see the very slow response from the webadmin pages but now the log shows:-


    [29/Dec/2001 19:08:36 03926] [info]  Connection to child 0 closed with standard shutdown (server cedars-fw.edars.local:443, client 192.168.1.10)
    [29/Dec/2001 19:08:37 03962] [info]  Connection to child 1 established (server cedars-fw.edars.local:443, client 192.168.1.10)
    [29/Dec/2001 19:08:37 03962] [info]  Seeding PRNG with 1160 bytes of entropy
    [29/Dec/2001 19:08:38 03962] [info]  Connection: Client IP: 192.168.1.10, Protocol: TLSv1, Cipher: RC4-MD5 (128/128 bits)
    [29/Dec/2001 19:08:38 03962] [info]  Initial (No.1) HTTPS request received for child 1 (server cedars-fw.edars.local:443)


    No trace of the "unclean shutdown" now. Looks like Mozilla handles things better?

    Oh well, one step nearer.

    thanks
    Mike