I am currently testing the Snort IDS for a project, I followed the Snort 2.9.5.3 installation guide. I am having an issue to correctly configure http_inspect so that it alerts to traffic.
The (virtual) network Snort is monitoring consists of it, an Ubuntu machine running DVWA (192.168.9.30) and a Kali Linux VM (192.168.9.20). I have created a local rule for any packet's contents of /etc/passwd. This rule has detected fragmented packets sent from the Kali VM to the DVWA VM (using file inclusion)
I believe I have configured the http_inspect to generate alerts for URL encoding, multiply slashes and self-referencing (see below). After running the evasion methods I check the terminal output from Snort and it shows that it did detect the use of these methods but it doesn't generate an alert.
snort.conf
# HTTP normalization and anomaly detection. For more information, see README.http_inspect
preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 65535 decompress_depth 65535
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 750 \
max_headers 100 \
max_spaces 200 \
small_chunk_length { 10 5 } \
ports { 36 80 81 82 83 84 85 86 87 88 89 90 311 383 591 593 631 801 818 901 972 1158 1220 1414 1533 1741 1830 2301 2381 2809 3029 3037 3057 3128 3443 3702 4000 4343 4848 5117 5250 6080 6988 7000 7001 7144 7145 7510 7770 7777 7779 8000 8008 8014 8028 8080 8082 8085 8088 8090 8118 8123 8180 8181 8222 8243 8280 8300 8500 8509 8800 8888 8899 9000 9060 9080 9090 9091 9443 9999 10000 11371 12601 34443 34444 41080 50000 50002 55252 55555 } \
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 yes \
bare_byte no \
directory yes \
double_decode yes \
iis_backslash no \
iis_delimiter no \
iis_unicode no \
multi_slash yes \
utf_8 yes \
u_encode yes \
webroot no
Local rule
alert tcp any any -> 192.168.9.30 80 (msg:"Potential File Inclusion of /etc/passwd"; flow:to_server,established; classtype:attempted-recon; content:"/etc/passwd"; nocase; sid:1122; rev:1;)
Discovered the answer, more through luck. Turns out the rule I have supplied in the question needed a slight modification over the snort.conf file. The 'content' field needed to be changed to 'uricontent'. With this modification the http_inspect pre-processor will examine the URI field of any packets examined.
Click here for more detail
Related
I have two namespaces srv1 and srv2, interconnected via a softswitch (p4 bmv2) with veth pairs. The softswitch does just simple forwarding. The veth interfaces inside the namespaces have IP addresses assigned to them (respectively 192.168.1.1 and 192.168.1.2). I could ping between the two namespaces using those IP addresses:
sudo ip netns exec srv1 ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.03 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=1.04 ms
but when I try netcat I dont receive messages on the server side:
client:
sudo ip netns exec srv1 netcat 192.168.1.2 80 -u
hello!
server:
sudo ip netns exec srv2 netcat -l 80 -u
The interface receives the packets with proper format.I verified with tcpdump on on both namespaces and I saw the packets being sent and received properly:
client:
sudo ip netns exec srv1 tcpdump -XXvv -i srv1p
[sudo] password for simo:
tcpdump: listening on srv1p, link-type EN10MB (Ethernet), capture size 262144 bytes
^C06:09:41.088601 IP (tos 0x0, ttl 64, id 14169, offset 0, flags [DF], proto UDP (17), length 35)
192.168.1.1.55080 > 192.168.1.2.http: [bad udp cksum 0x8374 -> 0x5710!] UDP, length 7
0x0000: 00aa bbcc dd02 00aa bbcc dd01 0800 4500 ..............E.
0x0010: 0023 3759 4000 4011 801d c0a8 0101 c0a8 .#7Y#.#.........
0x0020: 0102 d728 0050 000f 8374 6865 6c6c 6f21 ...(.P...thello!
0x0030: 0a .
1 packet captured
1 packet received by filter
0 packets dropped by kernel
server:
sudo ip netns exec srv2 tcpdump -XXvv -i srv2p
tcpdump: listening on srv2p, link-type EN10MB (Ethernet), capture size 262144 bytes
^C06:09:41.089232 IP (tos 0x0, ttl 64, id 14169, offset 0, flags [DF], proto UDP (17), length 35)
192.168.1.1.55080 > 192.168.1.2.http: [bad udp cksum 0x8374 -> 0x5710!] UDP, length 7
0x0000: 00aa bbcc dd02 00aa bbcc dd01 0800 4500 ..............E.
0x0010: 0023 3759 4000 4011 801d c0a8 0101 c0a8 .#7Y#.#.........
0x0020: 0102 d728 0050 000f 8374 6865 6c6c 6f21 ...(.P...thello!
0x0030: 0a .
1 packet captured
1 packet received by filter
0 packets dropped by kernel
I added on srv2 iptable rules to ACCEPT udp packets on port 80 and to LOG:
sudo ip netns exec srv2 iptables -t filter -A INPUT -p udp --dport 80 -j ACCEPT
sudo ip netns exec srv2 iptables -I INPUT -p udp --dport 80 -j LOG --log-prefix " IPTABLES " --log-level=debug
I could see the stats increasing on the entry and the packets being logged on /var/log/kern.log, but the message never reachets the netcats listening socker.
sudo ip netns exec srv2 iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1 33 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:80 LOG flags 0 level 7 prefix " IPTABLES "
4 133 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:80
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
kernel logs:
kernel: [581970.306032] IPTABLES IN=srv2p OUT= MAC=00:aa:bb:cc:dd:02:00:aa:bb:cc:dd:01:08:00 SRC=192.168.1.1 DST=192.168.1.2 LEN=33 TOS=0x00 PREC=0x00 TTL=64 ID=51034 DF PROTO=UDP SPT=48784 DPT=80 LEN=13
When I replace the softswitch with a bridge the netcat works. I thought maybe the softswitch corrputs the packets but the tcpdump shows the right format. The UDP checksum is not correct but it is generated like that from the source server, and it is the same thing when using the linux bridge anyways but it works in that case. Is ther a way to know the reason those packets do not reach the netcat server ?
I'm new to the forum, so apologies if I'm breaking any rules here (feel free to correct and/or re-direct)
That said: I'm trying to understand what the "-d" option does in tpcdump
(i.e. tcpdump -i any -d)
Running the example command above, it's clear that the output is different than without -d, but I'm not understanding the output or its purpose
The man page states
"Dump the compiled packet-matching code in a human readable form to standard output and stop."
but I'm having trouble parsing the meaning - What does it mean by packet-matching code? And what are some of the purposes of using this output?
Many thanks for any responses
When you use a capture filter with tcpdump like tcpdump -i <any> tcp port 443, you are filtering out packets that are not TCP packets or that aren't sent on port 443. But how, you ask, does tcpdump know how to do this?
Packet-matching code here refers to BPF (Berkeley Packet Filter) syntax code. In other words, what does tcp port 443 break down into at a lower level? If we run tcpdump -i <any> tcp port 443, we can see:
$ tcpdump -i en0 -d tcp port 443
(000) ldh [12]
(001) jeq #0x86dd jt 2 jf 8
(002) ldb [20]
(003) jeq #0x6 jt 4 jf 19
(004) ldh [54]
(005) jeq #0x1bb jt 18 jf 6
(006) ldh [56]
(007) jeq #0x1bb jt 18 jf 19
(008) jeq #0x800 jt 9 jf 19
(009) ldb [23]
(010) jeq #0x6 jt 11 jf 19
(011) ldh [20]
(012) jset #0x1fff jt 19 jf 13
(013) ldxb 4*([14]&0xf)
(014) ldh [x + 14]
(015) jeq #0x1bb jt 18 jf 16
(016) ldh [x + 16]
(017) jeq #0x1bb jt 18 jf 19
(018) ret #262144
(019) ret #0
For an information about what people use tcpdump -d for, there are articles on it. For a thorough breakdown of how BPF code works, tshark.dev has an article on it.
I am getting error when I run the following command:
docker run --name freeipa-server-container -ti \
-h ipa.example.test \
--read-only \
-v /var/lib/ipa-data:/data:Z freeipa-server [ opts ]
ERROR:
systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA
-APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=legacy)
Detected virtualization container-other.
Detected architecture x86-64. Set hostname to <ipa.example.test>.
Initializing machine ID from random generator.
Couldn't move remaining
userspace processes, ignoring: Input/output error
Sun Mar 22 16:47:43
UTC 2020 /usr/sbin/ipa-server-configure-first
IPv6 stack is enabled
in the kernel but there is no interface that has ::1 address assigned.
Add ::1 address resolution to 'lo' interface. You might need to enable
IPv6 on the interface 'lo' in sysctl.conf. The ipa-server-install
command failed. See /var/log/ipaserver-install.log for more
information
Last part says I need to enable enable IPv6 on the interface 'lo' in sysctl.conf.
Here is the output of ifconfig. It is already enabled. Isn't it?
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 661 bytes 56283 (56.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 661 bytes 56283 (56.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and also I couldn't find much about
Couldn't move remaining userspace processes, ignoring: Input/output error
Any pointers??
I am following this resource: https://github.com/freeipa/freeipa-container
I was able to resolve the same issue following this other answer, basically by adding --sysctl net.ipv6.conf.lo.disable_ipv6=0 into my docker run ... command. I don't actually know why it needs to be there but my symptoms were the same as yours and this did the trick. Here is my full command for testing:
$ docker run -it --rm \
--sysctl net.ipv6.conf.lo.disable_ipv6=0
--name freeipa-server-container \
-h idm.example.test \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-v /var/lib/ipa-data:/data \
--tmpfs /run \
--tmpfs /tmp \
freeipa/freeipa-server:latest
Sorry this isn't a great answer, but it might at least get you further down the road if you're still stuck.
I have setup a pxeboot which basically works fine. I can run any configured linux image.
Then I have enabled the firewall, released UDP port 69 for TFTP
~# iptables -L |grep tftp
ACCEPT udp -- anywhere anywhere udp dpt:tftp
ACCEPT udp -- anywhere anywhere udp dpt:tftp
~# netstat -tulp|grep tftp
udp 0 0 0.0.0.0:tftp 0.0.0.0:* 15869/in.tftpd
udp6 0 0 [::]:tftp [::]:* 15869/in.tftpd
~# cat /etc/services|grep tftp
tftp 69/udp
and now I get a timeout when pxeboot is pulling tftp://192.168.0.220/images/pxelinux.0 (rc = 4c126035).
Anywhere is ok here for now as there is another firewall running between the pxeserver and the router which blocks everything unwanted from/to WAN
The funny part is that tcpdump shows that the request is incoming on the pxeboot server:
~# tcpdump port 69
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:00:47.062723 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:47.415412 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:48.184506 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:49.722630 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
14:00:52.798136 IP 192.168.0.136.1024 > mittelerde.tftp: 47 RRQ "images/pxelinux.0" octet blksize 1432 tsize 0
Once I stop the firewall service pxeboot works fine again. Of course the conntrack module is loaded:
~# lsmod|grep conntrack
nf_conntrack_tftp 16384 0
nf_conntrack_ftp 20480 0
xt_conntrack 16384 4
nf_conntrack_ipv4 16384 20
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
nf_conntrack 131072 9 xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_nat,nf_conntrack_tftp,ipt_MASQUERADE,nf_nat_ipv4,xt_nat,nf_conntrack_ftp
libcrc32c 16384 2 nf_conntrack,nf_nat
x_tables 40960 8 xt_conntrack,iptable_filter,xt_multiport,xt_tcpudp,ipt_MASQUERADE,xt_nat,xt_comment,ip_tables
What I am missing here?
Problem solved. For tftpd-hpa the following UDP ports must be open as well:
1024
49152:49182
i have managed to cross compile ntpd 4.2.6p5 for my arm box. I have a custom toolchain provided by the manufacturer.
Box is running busybox + some variant of debian linux.
So I have no installation of ntp and did a manual copy, created a conf file for the ntpd and tried to run it.
ntpd always returns this when in debug mode:
~/ntp # ./ntpd -c ntp.conf -d
ntpd 4.2.6p5#1.2349 Mon Apr 7 19:58:25 UTC 2014 (1)
9 Apr 07:39:44 ntpd[3592]: signal_no_reset: signal 13 had flags 4000000
9 Apr 07:39:44 ntpd[3592]: proto: precision = 91.000 usec event at 0 0.0.0.0 c01d 0d
kern kernel time sync enabled
Finished Parsing!!
9 Apr 07:39:44 ntpd[3592]: ntp_io: estimated max descriptors: 1024, initial socket
boundary: 16
9 Apr 07:39:44 ntpd[3592]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
9 Apr 07:39:44 ntpd[3592]: unable to bind to wildcard address :: - another process
may be running - EXITING
before that I had to add into /etc/services also
ntp 123/udp
my ntp.conf looks like:
~/ntp # cat ntp.conf
server 193.2.4.6
server 193.2.4.2
driftfile ntp.drift
So I have checked netstat and nothing is running on port 123, no ntpdate etc...
~/ntp # netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.3.1 0.0.0.0 UG 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
~ # netstat -a | grep 123
~ #
Therefore it must be something with the config, or this arm box does not have something configured...
Oh and running manually ntpdate works:
~/ntp # ./ntpdate 193.2.4.6
9 Apr 07:49:16 ntpdate[3614]: step time server 193.2.4.6 offset -0.755704 sec
~/ntp #
So yes i could use ntpdate in cron, but this is not my intent!
Any idea?
Thank you and best regards!
The following error indicates that ntp had trouble binding to the ipv6 wildcard:
9 Apr 07:39:44 ntpd[3592]: unable to bind to wildcard address :: - another process
may be running - EXITING
I think your problem is ipv6 but it is hard to tell because your diagnosticinformation was not very good. Your netstat -a |grep 123 command is useless because netstat would substitute ntp for port 123. Try it again with:
netstat -a -n | grep 123
Along those lines netstat -rn only works with ipv4, try it again with -6:
netstat -r -n -6
Your test ntpdate used an ipv4 host. Does your server support ipv6? What happens when you run:
$ sntp -d -6 time.nist.gov
I used sntp because I do not know if ntpdate has a -6option and sntp does.