Re: (http_inspect) UNKNOWN METHOD for SSL over http proxy

["Tawanda Purazi" <Tawanda () tsi co za>]

Dear Sss,

 

 

You can suppress that by adding: 

suppress gen_id 119, sig_id 31

 

in your threshold.conf filr and restart snort.

 

Kind regards,

 

Tawanda

 

From: Sss kkk [mailto:sk.snort.user () gmail com] 
Sent: 27 March 2015 14:44
To: snort-users () lists sourceforge net
Subject: [Snort-users] (http_inspect) UNKNOWN METHOD for SSL over http proxy

 

Hello,

I'm new to snort, running version 2.9.7.2

 

For http traffic going through the proxy server I'm receiving huge amount of 'unknown method' (119:31:1) alerts.

It happens for every HTTPS connection going through the proxy server. 

There is nothing special in the traffic - simple opening https://github.com in the browser causes bunch of alerts 
generated by snort.

Dump captured at the proxy server side and presented in wireshark seems to be correct:

CONNECT github.com:443 HTTP/1..1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: github.com:443

HTTP/1.0 200 Connection established

............s.7..~v..J.z....h.=.)...T...k... .t_..3....-.m'7g..........0..o.....+./.
.......3.2.9./.5.
...x.....
..
github.com......
.................#..3t.....#.!.h2-15.h2-14.h2.spdy/3.1.http/1.1..........
........................l...h..U.B..j.D-.#.;.P.d]r_
....ni\3$.. .T........v......E.
.4>uH..J.*..../.. ........................http/1.1...
...
..
(...) 

Page displays without any errors anyway. The packet above with hex payload is decoded as "Client Hello" (TLSv1.2) in 
the Wireshark.

At the same time at the snort I have alert generated for all packets after "connection established" response.

First one comes for the same payload visible in the dump:


(snorby output):
http_inspect: UNKNOWN METHOD

Src Port        Dst Port        Seq     Ack     Off     Res     Flags   Win     Csum    URP
47100   8080    3070814240      2482041191      8       0       24      229     56036   0

0000000: 16 03 01 00 dd 01 00 00 d9 03 03 fd 73   83 37 ba a9 7e 76 93 9b 4a e3 7a da ff  ............s.7..~v..J.z..
000001A: 19 0e 68 f4 3d 95 29 de 1b 54 bd e8 c5   6b c5 8e f1 20 bf 74 5f eb b8 33 97 e7  ..h.=.)..T...k.....t_..3..
0000034: f1 ea 2d be 6d 27 37 67 93 b2 0e df b3   b3 f6 ab fd f9 30 ad 97 6f dd 9d 00 18  ..-.m'7g..........0..o....
000004E: c0 2b c0 2f c0 0a c0 09 c0 13 c0 14 00   33 00 32 00 39 00 2f 00 35 00 0a 01 00  .+./..........3.2.9./.5....
0000068: 00 78 00 00 00 0f 00 0d 00 00 0a 67 69   74 68 75 62 2e 63 6f 6d ff 01 00 01 00  .x.........github.com.....
0000082: 00 0a 00 08 00 06 00 17 00 18 00 19 00   0b 00 02 01 00 00 23 00 00 33 74 00 00  ....................#..3t..
000009C: 00 10 00 23 00 21 05 68 32 2d 31 35 05   68 32 2d 31 34 02 68 32 08 73 70 64 79  ...#.!.h2-15.h2-14.h2.spdy
00000B6: 2f 33 2e 31 08 68 74 74 70 2f 31 2e 31   00 05 00 05 01 00 00 00 00 00 0d 00 12  /3.1.http/1.1.............
00000D0: 00 10 04 01 05 01 02 01 04 03 05 03 02   03 04 02 02 02                          ...................

It is replicable and it always happens for HTTPS going over the http proxy. There are no timeouts or something.

TCP session from the client to the proxy server has been established just before CONNECT so should be properly tracked.

I was wondering if it is expected behavior for http_inspect in such a proxing scenario? Could be I misunderstood 
something.

Related configuration:

(increased memcap for session tracking, however haven't seen drops due to this anyway)

preprocessor stream5_global: track_tcp yes, \
   track_udp yes, \
   track_icmp no, \
   memcap 67108864, \
   max_tcp 262144, \
   max_udp 131072, \
   max_active_responses 2, \
   min_response_seconds 5
preprocessor stream5_tcp: policy windows, detect_anomalies, require_3whs 180, \
   overlap_limit 10, small_segments 3 bytes 150, timeout 180, \
    ports client 21 22 23 25 42 53 70 79 109 110 111 113 119 135 136 137 139 143 \
        161 445 513 514 587 593 691 1433 1521 1741 2100 3306 6070 6665 6666 6667 6668 6669 \
        7000 8181 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, \
    ports both 36 80 81 82 83 84 85 86 87 88 89 90 110 311 383 443 465 563 555 591 593 631 636 801 808 818 901 972 989 
992 993 994 995 1158 1220 1414 1533 1741 1830 1942 2231 2301 2381 2809 2980 3029 3037 3057 3128 3443 3702 4000 4343 
4848 5000 5117 5250 5600 6080 6173 6988 7907 7000 7001 7071 7144 7145 7510 7802 7770 7777 7778 7779 \
        7801 7900 7901 7902 7903 7904 7905 7906 7908 7909 7910 7911 7912 7913 7914 7915 7916 \
        7917 7918 7919 7920 8000 8008 8014 8028 8080 8081 8082 8085 8088 8090 8118 8123 8180 8181 8222 8243 8280 8300 
8333 8344 8500 8509 8800 8888 8899 8983 9000 9060 9080 9090 9091 9111 9290 9443 9999 10000 11371 12601 13014 15489 
29991 33300 34412 34443 34444 41080 44449 50000 50002 51423 53331 55252 55555 56712


preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535 
max_gzip_mem 104857600 proxy_alert
preprocessor http_inspect_server: server default \
    http_methods { GET POST PUT SEARCH MKCOL COPY MOVE LOCK UNLOCK NOTIFY POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS 
HEAD DELETE TRACE TRACK CONNECT SOURCE SUBSCRIBE UNSUBSCRIBE PROPFIND PROPPATCH BPROPFIND BPROPPATCH RPC_CONNECT 
PROXY_SUCCESS BITS_POST CCM_POST SMS_POST RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
    chunk_length 500000 \
    server_flow_depth 0 \
    client_flow_depth 0 \
    post_depth 65495 \
    oversize_dir_length 500 \
    max_header_length 1500 \
    max_headers 100 \
    max_spaces 200 \
    small_chunk_length { 10 50 } \
    ports { 36 80 81 82 83 84 85 86 87 88 89 90 311 383 555 591 593 631 801 808 818 901 972 1158 1220 1414 1533 1741 
1830 1942 2231 2301 2381 2809 2980 3029 3037 3057 3128 3443 3702 4000 4343 4848 5000 5117 5250 5600 6080 6173 6988 7000 
7001 7071 7144 7145 7510 7770 7777 7778 7779 8000 8008 8014 8028 8080 8081 8082 8085 8088 8090 8118 8123 8180 8181 8222 
8243 8280 8300 8333 8344 8500 8509 8800 8888 8899 8983 9000 9060 9080 9090 9091 9111 9290 9443 9999 10000 11371 12601 
13014 15489 29991 33300 34412 34443 34444 41080 44449 50000 50002 51423 53331 55252 55555 56712 } \
    non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
    enable_cookie \
    extended_response_inspection \
    inspect_gzip \
    normalize_utf \
    unlimited_decompress \
    normalize_javascript \
    apache_whitespace no \
    ascii no \
    bare_byte no \
    directory no \
    double_decode no \
    iis_backslash no \
    iis_delimiter no \
    iis_unicode no \
    multi_slash no \
    utf_8 no \
    u_encode yes \
    webroot no

 

proxy_alert added as a try also doesn't raise an alert for https connections. It works fine and rise alerts 
(UNAUTHORIZED PROXY USE DETECTED) for HTTP sessions going through the proxy server. For HTTPS ones 'unknown method' is 
raised only.

 

Could someone advise how to get that traffic analyzed without false alarms and without a need to suppress the 
inspection.

 

Best regards,

stan

 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!