Snort mailing list archives

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


From: Sss kkk <sk.snort.user () gmail com>
Date: Fri, 27 Mar 2015 16:35:37 +0100

2015-03-27 15:54 GMT+01:00 Al Lewis (allewi) <allewi () cisco com>:

 It would help if we had a pcap to look at. Where is the snort sensor in
relation to the proxy server?




Snort is between proxy and the client (browser).  Pcap attached.



 It looks like the preprocessor alerts are firing because the https
traffic cant be preprocessed correctly. I believe you are sending encrypted
traffic over the same port as unencrypted traffic (8080). The http
preprocessor is inspecting for http traffic on that port by default.


Yes, you are correct. 8080 can proxy both http and https on that port. I
believe 99% of sessions after CONNECT is https encrypted while GET and
others are used for clear http. So cannot remove 8080 from preprocessing as
I still want to inspect http traffic (and ideally correct ssl handshakes).
Possibly could remove CONNECT method from preprocessor config to avoid
false alarms? Not sure if there are any valid cases where CONNECT is
followed by unencrypted traffic.




If the traffic was separated (and the ssl preprocessor enabled) the
handshake would be inspected by snort then everything else encrypted (on
port 443) should be ignored.




Is ssl preprocessor able to inspect the handshake correctly when it comes
after http CONNECT?




Take a look at the README.ssl and the section in the snort.conf on the ssl
preprocessor



From the README.ssl file:



Overview

========



Encrypted traffic should be ignored by Snort for both performance reasons
and

to reduce false positives.  The SSL Dynamic Preprocessor (SSLPP) inspects
SSL

and TLS traffic and optionally determines if and when to stop inspection
of it.



Typically, SSL is used over port 443 as HTTPS.  By enabling the SSLPP to

inspect port 443, only the SSL handshake of each connection will be

inspected.  Once the traffic is determined to be encrypted, no further

inspection of the data on the connection is made.





Snort preprocessor for SSL:



# SSL anomaly detection and traffic bypass.  For more information, see
README.ssl

preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7802
7900 7901 7902 7903 7904 7905 7906 7907 7908 7909 7910 7911 7912 7913 7914
7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted







Hope this helps!



Albert Lewis

QA Software Engineer

SOURCE*fire*, Inc. now part of *Cisco*

9780 Patuxent Woods Drive
Columbia, MD 21046

Phone: (office) 443.430.7112

Email: allewi () cisco com



*From:* Sss kkk [mailto:sk.snort.user () gmail com]
*Sent:* Friday, March 27, 2015 8:44 AM
*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



Attachment: unknown_method.pcap.gz
Description:

------------------------------------------------------------------------------
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!

Current thread: