Alhamdullilah, thx god, I'm finaly completed my study on Dayeuhkolot
even it's too late ... 7 Years studying ...??
But now I must finishing my revision that given to me to fix my final assesment books and after that I must go home, find a job and get merried (Amin).
but still I must countinue my research about bayesian, because I had make it as a project on sourceforge , just click This Link and give me some advise about it

   Last day I had lost about 14 GB data, and guest what ... that's because Gentoo had a new installer system. Arhhh I dunno what the fu*k that Gentoo developer had in their mind.That new installer didn't stable yet, one mistake and kabommmm the installation will failed, and if you unlucky like me last day, all your data will be wipe out from your drive.

   Btw do you have scripts that contain sensitive information like passwords and you pretty much depend on file permissions to keep it secure? If so, then that type of security is good provided you keep your system secure and some user doesn't have a "ps -ef" loop running in an attempt to capture that sensitive info (though some applications mask passwords in "ps" output). There is a program called shc that can be used to add an extra layer of security to those shell scripts. SHC will encrypt shell scripts using RC4 and make an executable binary out of the shell script and run it as a normal shell script. This utility is great for programs that require a password to either encrypt, decrypt, or require a password that can be passed to a command line argument.
   To used it you must download shc first, and than you can do like this

toor@l33t#tar -xzvf shc-3.8.3.tgz
toor@l33t#cd shc-3.8.3.tgz
toor@l33t#make
toor@l33t#make install

   If all above process are success, then you just type "shc --help" ,
now try to make a script called hello.sh, and add the following word

#!/bin/bash
echo "I love Novan's personal blog and will send him a donation via PayPal."

and then save the file , Now run command :
toor@l33t#shc -f hello.sh

The argument -f specifies the source script to encrypt. The above command will create two files: hello.sh.x.c and hello.sh.x
The program "shc" creates C source code out of your shell script then encrypts it (hello.sh.x.c). The encrypted shell script is: hello.sh.x. Run that binary and see the output:

toor@l33t#./hello.sh.x
I love Novan's personal blog and will send him a donation via PayPal.

If that output is seen in your console now you can copy the original "hello.sh" file to a floppy disk or some other system for backup or in case you need to edit it in the future. Then, delete it from the server and delete the "hello.sh.x.c" file it creates.

   You can find other feature that shc had, with "shc --help" or just read the shc.README file.

   This past two weeks, is my wilding time (Wireless Lan Driving ), in my area i found some interest ssid, and guest what, some of them use WEP key and MAC filtering to access their network.
   Then as usual, i ask mr google about wilding and wep and ta daaaaa... I found some interesting software that can help me to break into wlan .
   And then I think "Ok, I cracked the WEP key and I can login to the network, but what about these encrypted packet captures?". Well I looked into it and managed to decrypt packet dumps and sniff a network with WEP without associating (Assuming I have the WEP key).

   Let me try to write down the process on it
WEP Decryption

Three tested methods exist to decrypt WEP encrypted packet dumps.
1) decrypt tool that is included with airsnort
2) Ethereal
3) Kismet

 Decrypt tool

   This program will decrypt saved packet dumps and remove the beacons within for an easier to read packet dump. You can provide the known WEP key or provide a file with WEP keys to attempt to find the correct key.

toor@l33t#decrypt -p 1E:A5:A5:6D:**:**:**:**:**:**:**:**:** -b -m **:**:**:FE:80:1C -e encrypted.pcap -d decrypted.pcap

Syntax: decrypt -p (WEP-KEY) -b -m (BSSID) -e (infile) -d (outfile)

When entering the WEP key make sure you seperate it with colons like the example above. The -b option removes beacons out of the packet dump. The BSSID of the network to decrypt is specified and the encrypted packet dump is specified and the desired output name added.

 Ethereal

   Using Ethereal you can do :
(a)decrypt packet dumps and
(b) decrypt packets on the fly without associating to the wireless network.
This is the most convenient solution out of all the three.

Open Ethereal then select EDIT -> PREFERENCES -> PROTOCOLS -> IEEE 802.11

Enter your WEP key into 'WEP key #1' box. Select 1 in the 'WEP key count' and check the 'Assume packets have FCS:' and click 'OK'. Any packets captured now will be decrypted and previously captured packets. You can add more WEP keys for Ethereal to use and if you do add more increase the 'WEP key count' value.

 Kismet

   Kismet also provided on the fly decryption of WEP encrypted traffic like Ethereal. Open the /usr/local/etc/kismet.conf file with an editor and add the wepkey directive as so:

wepkey=**:**:**:FE:80:1C,1EA5A56D28F520B66023E24211

Syntax: wepkey=(BSSID),(WEP KEY)

Multiple wepkey entries can be used to decode multiple networks.

But remember, your wlan card must be in prism or orinoco type or that software will not work correctly

   Arhh now I must sleep, 'cause I must go to my campus

Just remember guys Sleep well, Coding well
ps :: to admin, just read my last blog to prevent this

   Pyuhhh ... What a day, I must installed and configured my pc because my own stupid mistake ... lol, bad day huh!!!
   I hope my windoze and wlan connection willn't have any trouble anymore. or I just got April Mop ?

   This week I learn a lot about Wardriving , yeah for a students like me, I can't afford the monthly payment or event go to internet cafe, eventualy there's some interesting tools, an operating system and a bit of thinking to solve a not-entirely-artificial problem of getting wireless internet access where measureas are in place to stop it. Both the technical side as well as some of the reasoning behind the actions are explained.
   But If there's a sickness there's always a medicine right ?
   Many WLAN administrators are familiar with NetStumbler, a free discovery tool that sniffs out nearby 802.11 Access Points (APs). Unauthorized "rogue" APs get a lot of press, but are not the only threat.
Now we try to find how to see a sign of WLAN intrusion

Step 1: Capture traffic
   You'll need to capture wireless traffic being sent in the 2.4 and 5 GHz bands at your location. Start by getting yourself a wireless traffic analyzer and/or intrusion detection system (IDS).
Like Ethernet analyzers, WLAN analyzers capture and decode frames. They run on laptops and PDAs equipped with Wi-Fi NICs, passively scanning channels or watching one channel. They parse 802.11, 802.1X, and higher-layer protocols and display traffic capture results for visual inspection. They also analyze results to derive traffic statistics and generate alerts that help you get a better handle on WLAN security and performance.

Step 2: Analyze results
   Once you've captured traffic, then what? Sure, you can watch the frames roll by, or stop and expand header and data fields. But what should you be looking for?
Watch for security policy violations, like stations or APs operating in Open System mode if you require Shared Key authentication. Or devices operating without WEP if you require link encryption. Look for APs using default SSIDs, as these are often unconfigured (aka easily-attacked.) Keep an eye out for peer-to-peer "ad hoc" stations if not permitted in your WLAN. Tools can flag policy violations for you by generating alerts for these and other events like unauthorized stations/APs, stations associating with the wrong AP, or APs operating on unexpected channels.
You can't detect a completely passive sniffer. But you can watch for signs of active war driving. Look for excessive Probe Requests from stations that never associate, or stations that probe for vendor-default or "ANY" SSIDs. Watch for stations racking up 802.11/802.1X authentication or DHCP failures. Look for stations using IPs that lie within your subnet but not been assigned by your DHCP server, and for stations that use a valid MAC address but have a different name than usual. Intruders use these techniques to get past your access control lists. If you see SNMP traffic on your WLAN, particularly aimed at your AP, suspect active NetStumbling.
SNMP, Telnet, or HTTP traffic generated by wireless stations, aimed at your APs or WLAN gateway, often signal an attempted attacks. So do excessive frame counts -- for example, a spike in CRC errors may indicate jamming, while a spike in 802.11 Disassociate or Deauthenticate frames may indicate DoS attack. Larger-than-usual WEP ICV errors or TCP resends may indicate packet injection or replay attacks. Here, you must baseline your WLAN to understand what's normal and what isn't; expert tools can help you do that.

Intruders may also try to attack servers on the adjacent wired network; look for routing protocols like OSPF or IGRP, ICMP port unreachables, and large numbers of TCP SYNs aimed at your Intranet servers. If you're using robust authentication (802.1X or VPN) and good gateway access control, these requests really should not make it into the wired network. Even so, their presence can alert you before the attacker finds your weak spot and exploits it.

Like NetStumbler, these tools also help you spot Rogue APs. Watch for Beacons from previously-unknown APs and APs using the same SSID and MAC address on more than one channel. Unauthorized APs may inadvertently expose the "soft underbelly" of your network if placed inside your firewall. Malicious rogue APs are worse -- they try to masquerade as a legitimate AP, tricking stations into associating with them. They listen to and record all traffic, without the legitimate station or AP realizing it. Analyzers and IDSs generate alerts that warn about suspicious APs, but don't assume all new APs are malicious. Chances are good that you will spot APs that simply belong to a neighbor.

Step 3: Take action
   Once you've spotted a suspicious device, take action to find and correct the problem. WLAN analyzers -- particularly portable analyzers -- are handy for locating devices. When using an IDS, start from the sensor with the strongest signal. The idea is to find the device by monitoring signal strength. However, by the time you notice the possible intrusion, the source may be long gone. You may also find that the "intruder" is just a visitor or employee with an unauthorized Wi-Fi interface; you may choose to authorize or ignore the visiting device. This is where configuring policies into your analyzer or IDS comes in handy, so that you don't waste time on "false positives" and devote your efforts to addressing real threats. Analyzers and IDS tools help you "hear" what's happening in your WLAN, but ultimately it's up to you to interpret suspicious events and decide whether remedial action is required.

   Arghhh another boring day, but perhaps I'll post about my final assesment on dayeuhkolot
I work on it about 2 years, and still not perfect yet

Just like I wrote on my website, this time I only write about the history

   In 1761, Reverend Thomas Bayes brought us a concept for govern the logical inference, determining the degree of confidence we may have, in various possible conclusions, based on the body of evidence available. Therefore, to arrive at a logically defensible prediction one must use Bayes’ theorem.

   The Bayesian Detection Rate was first used to measure IDS effectiveness in Mr. Stefan Axelson paper "The Base-Rate Fallacy and its Implications for the Difficulty of Intrusion Detection" presented on RAID 99 which gives a realistic perspective on how "False Alarm" rate can limit the performance of an IDS.
   As said, the paper aims to increase the detection rate reducing false alarms on the IDS model, therefore we must know the principles of Bayesian Detection Rate (BDR):

                           P(D|H)P(H)
P(H|D) = ------------------------------------
                    P(D|H)P(H) + P(D|H')P(H')

Let's use a simple example to ilustrate how Bayes Theorem Works:

   Suppose that 2% of people your age and heredity have cancer. Suppose that a blood test has been developed that correctly gives a positive test result in 90% of people with cancer, and gives a false positive in 10% of the cases of people without cancer. Suppose you take the test, and it is positive. What is the probability that you actually have cancer, given the positive test result?
   First, you must identify the Hypothesis, H, the Datum, D, and the probabilities of the Hypothesis prior to the test, and the hit rate and false alarm rates of the test.

H = the hypothesis; in this case H is the hypothesis that you have cancer, and H' is the hypothesis that you do not.

D = the datum; in this case D is the positive test result.

P(H) is the prior probability that you have cancer, which was given in the problem as 0.02.

P(D|H) is the probability of a positive test result GIVEN that you have cancer.
This is also called the HIT RATE, and was given in the problem as 0.90.

P(D|H') is the probability of a positive test result GIVEN that you do not have cancer. This is also called the FALSE ALARM rate, and was given as 0.10.

P(H|D) is the probability that you have cancer, given that the test was positive. This is also called the posterior probability or Bayesian Detection Rate.

In this case it was 0.155(16% aprox., i'd not bet the rest of my days on this test).

   On my final assesment, I'm implementing bayesian on Gentoo Linux that used
· Snort 2.1.3
· Iptables v 1.2.8
· Libpcap as network library
· Mysql as database
· Shc-3.8.3 to convert my script

   I just got idea about this when I read Phrack Volume 0x0b, Issue 0x39, Phile #0x0c of 0x12,in the early time, I'm still confused about how to implemented it on Gentoo Linux, but now I believe, I must face my next future that I'm sure very different from today
    Wish me luck on April to face my final assesment jugde from my lecturer on dayeuhkolot .