Forum Discussion

Chronos_258816's avatar
Chronos_258816
Icon for Nimbostratus rankNimbostratus
Jul 28, 2016

Host Header Validation

Greetings,   I have been tasked with crafting an iRule to validate the host header of incoming packets to a given virtual server. I have tried a few different irules to attempt this an yet I am t...
iRules
security
  • VernonWells's avatar
    VernonWells
    Jul 28, 2016

    A data-group is a convenience rather than a necessity.

    I tried the following on 11.5.4:

     

     

    when HTTP_REQUEST {
    if { [HTTP::host] ne "xyz.com" } {
        reject
    }
}

     

     

    I tried all of the following combinations:

    1. HTTP/1.1 Host header xyz.com;
    2. HTTP/1.1 Host header foo.com;
    3. HTTP/1.0 no Host header;
    4. HTTP/1.1 Host header xyz.com followed by HTTP/1.0 no Host header;
    5. HTTP/1.1 Host header xyz.com followed by HTTP/1.1 Host header foo.com

    Case 1: allowed;

    Case 2: rejected (i.e., TCP RST);

    Case 3: rejected;

    Case 4: allowed then rejected;

    Case 5: allowed then rejected.

    Incidentally, if a pool is assigned to the VS, then the else clause isn't needed (it's the default anyway).

    Having said all of that, your issue may be relate to this note, found in the reject explanation:

     

    Subsequent code in the current event in the current 
iRule or other iRules on the VS are still executed 
prior to the reset being sent.

     

    I recommend putting a return after the reject.

     

VernonWells's avatar
VernonWells
Icon for Employee rankEmployee

A data-group is a convenience rather than a necessity.

I tried the following on 11.5.4:

 

 

when HTTP_REQUEST {
    if { [HTTP::host] ne "xyz.com" } {
        reject
    }
}

 

 

I tried all of the following combinations:

  1. HTTP/1.1 Host header xyz.com;
  2. HTTP/1.1 Host header foo.com;
  3. HTTP/1.0 no Host header;
  4. HTTP/1.1 Host header xyz.com followed by HTTP/1.0 no Host header;
  5. HTTP/1.1 Host header xyz.com followed by HTTP/1.1 Host header foo.com

Case 1: allowed;

Case 2: rejected (i.e., TCP RST);

Case 3: rejected;

Case 4: allowed then rejected;

Case 5: allowed then rejected.

Incidentally, if a pool is assigned to the VS, then the else clause isn't needed (it's the default anyway).

Having said all of that, your issue may be relate to this note, found in the reject explanation:

 

Subsequent code in the current event in the current 
iRule or other iRules on the VS are still executed 
prior to the reset being sent.

 

I recommend putting a return after the reject.

 

VernonWells's avatar
VernonWells
Icon for Employee rankEmployee
Jul 29, 2016

Naturally, but actually, that snippet is "more secure", in the sense that it is stricter. That is, if the Host header is Xyz.com (which, by RFC, means exactly the same thing as xyz.com), then it will be rejected. To allow any case (which, again, would be the RFC conforming choice):

 

if { [string tolower [HTTP::host]] ne "xyz.com" } { reject }