Thursday, November 7, 2013

MVC4: Remove unnecessary headers

For some reason, Microsoft by default loves to advertise that you are running their products.  This is probably so that they can skew the webserver stats in their favour.

Even so, it is a good idea to hide these headers, or use them to provide misleading information.

In an MVC application, there are generally  3 headers you are going to want to target.

The first one is the server header.  This one is IIS specific.  Unfortunately, MS has not provided an easy way to change this header.  The two options you have are to use a WAF that will mask it for you, or to change it in code.  The code option involves creating a http module and adding it to the pipeline in the appropriate place.


    public class CustomServerHeaderModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.PreSendRequestHeaders += OnPreSendRequestHeaders;
        }

        private void OnPreSendRequestHeaders(object sender, EventArgs e)
        {
            HttpContext.Current.Response.Headers.Set("Server","Jetty(6.0.x)");
        }

        public void Dispose()
        {
            
        }
    }

In the above case, I am setting the server header similar to that of Jetty.  Why?  Well, why not?

The second one you will want to target is the x-powered-by header.  I mean, who cares what powers your site.  Oh wait, an attacker does.  In any event, this a custom header that is set in one of the .config files that IIS reads.  You can override this by adding a clear tag.


<httpProtocol>
  <customHeaders>
    <clear />
  </customHeaders>
<httpProtocol>

The last one is the X-AspNetMvc-Version. Once again, I'm not sure why you would want to advertise this to anyone.  Luckily this one can easily be disabled by code.  In the application start of your global.asax simply add the following line.


MvcHandler.DisableMvcResponseHeader = true;

Trying to minimize the amount of information leaked by your application is always a good thing.

MVC4 Cookie Obsfucation

When building a MVC4 application with authentication, there are two cookie values that will generally be issued by your app.

The first one has to do with forms authentication and allows the MVC framework to determine if a user is authenticated (useful for the authorize attribute, etc).  This one is, by default, set to .ASPXAUTH.

The second is used to store session state.  This is actually an IIS setting (although it can be controlled via the web config).  The default is ASP.NET_SessionId. 

When conducting a review of a site, looking at the default cookie names to get an idea of the underlying technology is one of the first things one would do.  It is a good idea for a production facing Internet site to change these defaults.  Luckily this is quite easy to do.

In order to change the forms authentication cookie name, simply add the name attribute to the forms tags in your authentication section.  For example, you could add name="myauthcookie".

See this link for more info.

In order to change the session state one, you can add a session state tag to your system.web configuration section.  In this case you will use the cookieName attribute and you can try and emulate some other webserver default.  For example, cookieName=".jessionid".

See this link for more info.

Tuesday, November 5, 2013

Installing NTOP NG on CentOS 6.4

With my linux router in place between my cable modem and safe@office, I'm ready to start playing around with some network IDS/IPS/visualization tools.  The first one I want to play around with is ntop.

For the most part, I followed this link

NTOP has created a couple of YUM repos that store most of the binaries/etc you will need to run ntop on CentOS.  This makes it pretty easy to install.

Here is what my ntopng config looks like:


-G=/var/tmp/ntopng.gid
-i eth1
--data-dir /var/ntop
--local-networks 192.168.10.0/24,192.168.12.0/24,192.168.252.0/24


In my case, my inside interface is eth1.  Cable can be quite noisy, so I rather monitor the inside interface then the outside one.  Local networks just tells ntop what to consider local, and what not to.  Make sure the data-dir is writable by the user that ntop switches to after startup (usually nobody).

Other than that, have fun looking at the flows.  I've noticed that ntop is only taking up about 30mb of ram.  Nice!

Saturday, November 2, 2013

Centos 6.3 and static routes

I recently added a centos box inline between my cable modem and my checkpoint safe@office.  One of the things that I want to be able to do is run ntop.  Unfortunately, my safe@office was setup to NAT my wireless and wired connections behind it.  According to ntop, all I had was one host.

Disabling natting on the safe@office is easy, except, but default wireless clients and wired clients connect up on different subnets.  I could probably disable DHCP on the safe@office and have everything run via the centos box...but that is a project for another day.  For right now, I need to configure some static routes so that my centos box will properly relay traffic.

Standard route commands work, and are a great way for getting a configuration up and running.

For example:


ip route add 192.168.111.0/24 via 192.168.11.2 dev eth1


In the above example, I am adding a route for the 192.168.111.0/24 network and instructing all traffic to be sent to 192.168.11.2 via eth1.  Pretty sweet.  The problem is that adding routes like this does not persist the configuration after reboot.

I tried to edit the appropriate files as found in this doc, but I found that the configuration did not persist.  I may have messed up somewhere, but I didn't get that method to work.

I decided to go dirty and add the commands directly to rc.local.