[Snort-users] (http_inspect) UNKNOWN METHOD for SSL over http proxy

Sss kkk sk.snort.user at ...11827...
Fri Mar 27 11:35:37 EDT 2015


2015-03-27 15:54 GMT+01:00 Al Lewis (allewi) <allewi at ...589...>:

>  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 at ...589...
>
>
>
> *From:* Sss kkk [mailto:sk.snort.user at ...11827...]
> *Sent:* Friday, March 27, 2015 8:44 AM
> *To:* snort-users at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20150327/877dbdfb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown_method.pcap.gz
Type: application/x-gzip
Size: 24185 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20150327/877dbdfb/attachment.bin>


More information about the Snort-users mailing list