Forum Discussion
Chronos_258816
Nimbostratus
NimbostratusHost 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...
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:
- HTTP/1.1 Host header xyz.com;
- HTTP/1.1 Host header foo.com;
- HTTP/1.0 no Host header;
- HTTP/1.1 Host header xyz.com followed by HTTP/1.0 no Host header;
- 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
Employee
EmployeeA 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:
- HTTP/1.1 Host header xyz.com;
- HTTP/1.1 Host header foo.com;
- HTTP/1.0 no Host header;
- HTTP/1.1 Host header xyz.com followed by HTTP/1.0 no Host header;
- 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.
Chronos_258816Nimbostratus
NimbostratusGood to know that it should be working as intended as per your examples above. I have placed the return after the reject and hope that takes care of the issue. If not, I need to see just how the exploits are being done.