Snort mailing list archives

Re: (http_inspect) UNKNOWN METHOD error on squid


From: Terry John <Terry.John () completeautomotivesolutions co uk>
Date: Wed, 4 Mar 2015 16:08:46 +0000

I've managed to have another look and I think I've found the offending packets. The http CONNECT is fine and the 
exchange of certificates looks good.

We gate an HTTP/1.0 200 Connection established message.

The problem comes when the TLS connection is being established

The offending packets are
TLS Record Layer: Handshake Protocol: Client Hello

Is there anything in the http_inspect that covers this?

Terry

From: Al Lewis (allewi) [mailto:allewi () cisco com]
Sent: 04 March 2015 13:41
To: Terry John
Cc: snort-users
Subject: RE: (http_inspect) UNKNOWN METHOD error on squid

Understood. My advice would be to check the traffic and look at the http methods being used first. Most (if not all) of 
the preprocessor and decoder rules alert only when something out of the ordinary (malformed/invalid) happens. They 
shouldn't be alerting on normal traffic.

Hope this helps!

Albert Lewis
QA Software Engineer
SOURCEfire, Inc. now part of Cisco
9780 Patuxent Woods Drive
Columbia, MD 21046
Phone: (office) 443.430.7112
Email: allewi () cisco com<mailto:allewi () cisco com>

From: Terry John [mailto:Terry.John () completeautomotivesolutions co uk]
Sent: Wednesday, March 04, 2015 7:17 AM
To: Al Lewis (allewi); snort-users
Subject: RE: (http_inspect) UNKNOWN METHOD error on squid

It's difficult to sanitise the data for public viewing unfortunately. But what I can say, from the squid logs, is that 
it is coming from a fisheye server connecting to a code repository service providing source code management. It 
connects successfully to port 443 of the destination server.

The data comes as a burst of 3 or 4 packets in a second waits about 15 seconds then sends another burst of packets.

Sorry if it's a bit vague

From: Al Lewis (allewi) [mailto:allewi () cisco com]
Sent: 04 March 2015 11:22
To: Terry John; snort-users
Subject: RE: (http_inspect) UNKNOWN METHOD error on squid

Hello,

Can you provide a pcap of the traffic that is causing the alerts?

What this alert is telling you is that one of the http_methods used in the packet is either not in your preprocessor 
config or malformed/invalid.


Albert Lewis
QA Software Engineer
SOURCEfire, Inc. now part of Cisco
9780 Patuxent Woods Drive
Columbia, MD 21046
Phone: (office) 443.430.7112
Email: allewi () cisco com<mailto:allewi () cisco com>

From: Terry John [mailto:Terry.John () completeautomotivesolutions co uk]
Sent: Wednesday, March 04, 2015 5:52 AM
To: snort-users
Subject: [Snort-users] (http_inspect) UNKNOWN METHOD error on squid

I am trying to work out how to stop of thousands of false positives caused by access to squid proxy on port 3128. Here 
is a typical error.

[119:31:1] (http_inspect) UNKNOWN METHOD [**]
[Classification: Unknown Traffic] [Priority: 3] <date>-<time> <src_ip>:35360 -> <squid_server_ip>:3128
TCP TTL:128 TOS:0x0 ID:87051 IpLen:20 DgmLen:775 DF
***A**** Seq: 0x126F0768 Ack: 0x859E62D4 Win: 0x4980 TcpLen: 32

Here is what I think  is the relevant section of the pre-processor declaration

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 } \
    allow_proxy_use \
    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 2231 2301 2381 2809 3029 3037 3057 3128 3443 3702 4000 4343 4848 5117 5250 6080 6173 6988 7000 7001 7071 7144 7145 
7510 7770 7777 7779 8000 8008 8014 8028 8080 8081 8082 8085 8088 8090 8118 8123 8180 8181 8222 8243 8280 8300 8500 8509 
8800 8888 8899 9000 9060 9080 9090 9091 9111 9443 9999 10000 11371 12601 15489 29991 33300 34412 34443 34444 41080 
44449 50000 50002 51423 53331 55252 55555 56712 } \

I have a local rule to reduce the number of errors but I would rather not have to do that

# This is to reduce the number of 'unknown method' http alerts
event_filter gen_id 119, sig_id 31, type limit, track by_src, count 1, seconds 10

I feel that squid proxy is so common that there should be a standard setting for this but at the moment I just can't 
find it.

If I delete port 3128 from the list of ports then the rule is not applied but I don't think that is what we want.

Thanks



The Manheim group of companies within the UK comprises: Manheim Europe Limited (registered number: 03183918), Manheim 
Auctions Limited (registered number: 00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications Limited (registered number: 04277845) and 
Complete Automotive Solutions Limited (registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group 
of companies operates under various brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC


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