Sancp Insight

Security Analyst Network Connection Profiler(SANCP) - the network tool that is designed for the purpose of network traffic profiling, trail auditing, and historical analysis with the capabilities to collect statistical/flow/pcap data. For further information regarding sancp, you can check out its main site -

http://www.metre.net/sancp.html

Many of us never heard of Sancp until we come across Sguil where Sancp is merged into it to feed the flow/session data. I'm also one of those until I find out that there are actually lots of interesting features and functions in Sancp.

Thanks to John Curry who spared his precious time discussing about sancp with me, while the conversation went like an interview and some insights about sancp, I have permission to post this to my blog and share it with everyone -

geek00l> hey
jlcurry> hey geek00l I want to say thanks for your comment last week about graphviz
jlcurry> i've been playing around with connection stats
jlcurry> it's not really good for lots of connections - but works nice to show a snapshot of current activity
jlcurry> the images get pretty insanely large
geek00l> :)
geek00l> jlcurry, :)
jlcurry> anyway, I wasn't sure if you had worked with it in that way much
geek00l> jlcurry, actually i was playing a lot with sancp tuning
jlcurry> sweet
jlcurry> I'm gonna blog about what I do with it
geek00l> jlcurry, do u have rss
jlcurry> I have nothing yet
jlcurry> I'm going to setup a blogger.com account
geek00l> that's great
geek00l> jlcurry, i remember you said that sancp will see the first packet and putting the source ip as the host that starting the connection
geek00l> jlcurry, and in the sancp config, how to improve its direction sensitiveness
geek00l> jlcurry, i read the defining the services port
jlcurry> back
jlcurry> are those questions?
jlcurry> I hope things are working as I explained ;)
jlcurry> I believe you are referring to the 'know_ports' option
jlcurry> err 'known_ports'
* jlcurry goes to look it up
geek00l> yeah
geek00l> i'm refering to that
jlcurry> you can do something like: known_ports 6 8734, 22, 25, 80, 443, 53, 993, 933, 8734, 110
jlcurry> var tcp 6
jlcurry> known_ports tcp 8734, 22, 25, 80, 443, 53, 993, 933, 8734, 110
jlcurry> that is usually easier to read
geek00l> jlcurry, yes, but i wanna know how it improves the direction guessing
jlcurry> oh, well - in the case of UDP - it will swap the dest and source of the connection if the source port is in the known_ports 17 list
jlcurry> oh, well - in the case of TCP - it gets complicated
jlcurry> in the case of TCP - it will swap the dest and source of the connection if the source port is in the known_ports 6 list AND the first packet is NOT in the known_ports list.
jlcurry> basically when sancp is uncertain about the direction of a TCP connection, it consults the known_ports 6 list
geek00l> jlcurry, so if the port is defined in the known ports, so it won't be the one that starting the connection instead it is the one that receiving the packet first when sancp is uncertain about it?
jlcurry> sometime sancp gets a TCP packet mid-session- if it happens to come from the destination - since this is the first packet sancp sees, it will assume it is from the source
jlcurry> in such a case, no tcpflags are present that can help deduce the direction
geek00l> jlcurry, no tcpflags?
jlcurry> my bad, - without a 'SYN', or 'SYN+ACK' tcpflag combination - sancp must rely on the first packet - or secondly on the known_ports matching on the 'dest port' (in the packet recieved).
geek00l> read you now
geek00l> jlcurry, have you done performance benchmarking on sancp regarding its pcap logging
jlcurry> unfortunately no, any ideas on how you would do this reliably?
geek00l> jlcurry, not yet, but i'm interested in this - bytes of pcap data to collect per connection
geek00l> jlcurry, i think it is great feature to reduce the full content data
jlcurry> fyi - the alpha version supports logging the first X bytes of payload data from the source and dest separately to stats (in filtered ascii or hex notation)
jlcurry> those will be a fun fields to work with
geek00l> jlcurry, interesting
geek00l> jlcurry, the first X bytes of payload separately, i thought it is defined to log how many bytes per connection
jlcurry> geel00l, this feature is memory hungry - pcap limit affects pcap logging - sample_src_ascii (for example) is a stats output field (so packet data payload can go to stats output)
jlcurry> pcap limit is separate from the sampling that I am referring to now
geek00l> jlcurry, same with bro-ids time machine, it is mem hungry :)
jlcurry> you can control how much data is sample from each end
jlcurry> this helps collect things like URI's which occurr early in the packet and don
jlcurry> don't require pcap (nessarily) to confirm nature
I really don't like talking - I usually find faults in my statements (i.e. most browsers send more than one request per connection, some attacks do the same, some attacks start with a normal request)
geek00l> jlcurry, just to confirm with you, if i just want to log the first X bytes of payload data, pcap limit is the one i need to tune?
jlcurry> yes this is correct for logging data to pcap
jlcurry> SANCP will still count statistics on all packets
geek00l> jlcurry, what's the recommended range for pcap limit
geek00l> jlcurry, yup, that's to reduce full content data while retain the session/flow data
jlcurry> I use full content logging - and yes I use the pcap limit to reduce pcap files I want to archive a little longer - but I don't need the wasted data (i.e. 1500bytes of the FTP binary is fine for me)
geek00l> jlcurry, thanks
geek00l> jlcurry, can i post our conversation to my blog?
jlcurry> geek00l you're welcome
jlcurry> yes
geek00l> cool :)

I have edited the conversations so that it looks cleaner while retain the contents. I hope this dialog can give you some insights about sancp and feel free to download, install and play with it now.

Thanks again, John!

Cheers ;]