Setup Openssl + freeRADIUS

Openssl Ceritification Step

1. Create ca certification by openssl
#cd /etc/ssl/
#/usr/lib/ssl/misc/CA.pl -newca -- ubuntu directory
or
#/usr/share/ssl/misc/CA.pl -newca -- opensuse directory

CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
..........................++++++
..........++++++
writing new private key to './CA/private/cakey.pem'
Enter PEM pass phrase: 12345
Verifying - Enter PEM pass phrase: 12345
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:TW
State or Province Name (full name) [Some-State]:Taipei
Locality Name (eg, city) []:Taipei
Organization Name (eg, company) [Internet Widgits Pty Ltd]:QMI
Organizational Unit Name (eg, section) []:DQA
Common Name (eg, YOUR name) []:rootca
Email Address []:bryan.yu@qmitw.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: don't need to input
An optional company name []: don't need to input
Using configuration from /usr/lib/ssl/openssl.cnf
Using configuration from /usr/share/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem: 12345

Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            91:23:c3:97:8a:c5:d8:e5
        Validity
            Not Before: Mar 17 14:38:09 2008 GMT
            Not After : Mar 17 14:38:09 2011 GMT
        Subject:
            countryName               = TW
            stateOrProvinceName       = LinKou
            organizationName          = QMI
            organizationalUnitName    = DQA
            commonName                = rootca
            emailAddress              = bryan.yu@qmitw.com
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                FF:DA:F6:63:4E:6F:20:16:85:BC:CE:E4:6E:EA:17:48:B5:DE:87:25
            X509v3 Authority Key Identifier:
                keyid:FF:DA:F6:63:4E:6F:20:16:85:BC:CE:E4:6E:EA:17:48:B5:DE:87:25
                DirName:/C=TW/ST=LinKou/O=QMI/OU=DQA/CN=rootca/emailAddress=
                bryan.yu@qmitw.com
                serial:91:23:C3:97:8A:C5:D8:E5

            X509v3 Basic Constraints:
                CA:TRUE
Certificate is to be certified until Mar 17 14:38:09 2011 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated

RADIUS Issues

Response authenticator based Shared Secret Attack
Attacker observes a valid access request packet and the associated return packet(access-accept/access-reject packet), then launch offline exhaustive attack on the shared secret.
They can guess shared secret by pre-compute MD5(Code+ID+length+RequestAuth+Attributes) and resume the hash once.

User-Password Attribute Based Shared Secret Attack

Attacker observes the traffic and try to authenticate to client with a known password, and capture the resulting Access-Request packet and XOR the User-password attribute with the password they provided to client. This results in the value of MD5(S+RA). RA is known in the client request packet, so attacker can launch offline exhaustive attack to get shared secret.

User-Password Based Password Attack
As the previous attack method, attacker can get the value of MD5(S+RA), and replay the modified access request packet as pretending a client. If server dosen't impose user based rate limits, this will allow the attacker to get the correct password.

Request Authenticator Based Attacks
The security of RADIUS depends on the generation of the RA(Request Authenticator)  field, but a lot of implementations using poor PRNG(pseudo random number generation) to generate the RA. If the client uses a PRNG that repeats values (or has a short cycle), the protocol ceases to provide the intended level of protection.

These attacks require the attacker to cause client to produce a particular identifier value. An attacker can insert a series of extra requests to the client, forcing the desired identifier. Even if the identifier were not generated in a readily attackable way, it would still only increase the work factor by 256 times.

Passive User-Password Compromise Through Repeated Request Authenticator
Build dictionary RA--User Password Attribure
If the attacker can sniff the traffic between the RADIUS client and the RADIUS server, they can passively produce a dictionary of Request Authenticators, and the associated (protected) User-Password attributes. If the attacker observes a repeated Request Authenticator, they can remove any influence of the Shared Secret from the first 16 octets of the passwords by XORing the first 16 octets of the protected passwords together. This yields the first 16 octets of the two (now unprotected) user passwords XORed together.

Active User-Password Compromise through Repeated Request Authenticators
Build dictionary RA--MD(S+RA)
Attacker authenticate many times using known passwords and intercept the generated Access-Request packets, extracting the RA and user-password attribute. Then XOR the known password with user-password attribute and be left with the MD5(S+RA) value. Finally, the attacker generates a dictionary of RA and associated MD5(S+RA) value.
Attacker can use this dictionary(RA--MD(S+RA)) to recover the first 16 octets from the protected region of the user password, since c1=p1 XOR MD5(S+RA).

Replay of Server Responses through Repeated Request Authenticators

Using dictionary RA--ID--associate server response

Attacker observe the client request, check RA and ID from the dictionary, then pretend as server the return the associate response to client.

DOS arising from the prediction of the Request Authenticators
Build dictionary predict RA values and associated server response, then response the client's valid request with access-reject packets, implement DOS.

RADIUS authentication procedure

RADIUS packet is below (from the RFC):

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Authenticator                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

• The code establishes the type of RADIUS packet. The codes are:
  

Value	Description
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server (experimental)
13	Status-Client (experimental)
255	Reserved

•  The identifier is a one octet value that allows the RADIUS client to match a RADIUS response with the correct outstanding request. it is usually implemented as a simple counter that is incremented for each request.
• The attributes section is where an arbitrary number of attribute fields are stored. The only pertinent attributes for this discussion are the User-Name and User-Password attributes. 
  

Initial client processing

The client creates an Access-Request RADIUS packet, including at least the User-Name and User-Password attributes.

The Access-Request packet's identifier field is generated by the client.

The Access-Request packet contains a 16 octet Request Authenticator in the authenticator field. This Request authenticator is a randomly chosen 16 octet string. 

This packet is completely unprotected, except for the User-Password attribute, which is protected as follows:

c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
.
.
.
cn = pn XOR MD5(S + cn-1)

The User-Password attribute contains c1+c2+...+cn, Where + denotes concatenation.

Here S is shared secret in server or client, RA is psuedo-random 128bit request authenticator, p1,p2 and so on is 16 octet block by breaking the password

Server processing

• Extract the username and password using the same shared secret
• Validate the account
• Compute response authenticator which is MD5(code+ID+Length+RequestAuth+Attribute+secret), and send back the response packet to client
  

The server receives the RADIUS Access-Request packet and verifies the packet with shared secret first, it can go through a slightly modified version of the client's protection process on the User-Password attribute and obtain the unprotected password. It then uses its authentication database to validate the username and password. If the password is valid, the server creates an Access-Accept packet to send back to the client, otherwise, send back with Access-Reject packet. Both the Access-Accept packet and the Access-Reject packet use the same identifier value from the client's Access-Request packet, and put a Response Authenticator in the Authenticator field. The response authenticator = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

Client post processing

• Match ID
• Compute the Response Authenticator as the server performed
• Check the code field for the result
  

When the client receives a response packet, it attempts to match it with an outstanding request using the identifier field, then verifies the Response Authenticator by performing the same Response Authenticator calculation the server performed, and then comparing the result with the Authenticator field.

If the client received a verified Access-Accept packet, the username and password are considered to be correct, and the user is authenticated.

Linux - Ubuntu general shortcut

General keyboard shortcuts

Ctrl+A = Select all (In Documents, Firefox, Nautilus, etc, not Terminal)
Ctrl+C = Copy (In Documents, Firefox, Nautilus, etc, not Terminal)
Ctrl+V = Paste (In Documents, Firefox, Nautilus, etc, not Terminal)

Ctrl+N = New (Create a new document, not in terminal)
Ctrl+O = Open (Open a document, not in terminal)
Ctrl+S = Save (Save the current document, not in terminal)
Ctrl+P = Print (Print the current document, not in terminal)

Ctrl+E = Send To... (Send the current document to an email recipient or remote location, not in terminal)
Ctrl+W = Close (Close the current document, not in terminal)
Ctrl+Q = Quit (Quit the application, not in terminal)

Ctrl + Alt + F1 = Switch to the first virtual terminal
Ctrl + Alt + F2(F3)(F4)(F5)(F6) = Select the different virtual terminals
Ctrl + Alt + F7 = Switch to current terminal session with X

Ctrl+Alt++ = Switch to next X resolution (Depends of your X configuration)
Ctrl+Alt+- = Switch to previous X resolution (Depends of your X configuration)

Ctrl + Alt + Backspace = Kill X server

Alt+Tab = Switch between open programs
Printscrn = Print sreen

OSPF

1. Hello - Hello packets are used to establish and maintain adjacency with other OSPF routers. The hello protocol is discussed in detail in the next topic.

2. DBD - The Database Description (DBD) packet contains an abbreviated list of the sending router's link-state database and is used by receiving routers to check against the local link-state database.

3. LSR - Receiving routers can then request more information about any entry in the DBD by sending a Link-State Request (LSR).

4. LSU - Link-State Update (LSU) packets are used to reply to LSRs as well as to announce new information. LSUs contain seven different types of Link-State Advertisements (LSAs). LSUs and LSAs are briefly discussed in a later topic.

5. LSAck - When an LSU is received, the router sends a Link-State Acknowledgement (LSAck) to confirm receipt of the LSU.

OSPF router initial procedure

1. Sending Hello packets on all OSPF-enabled interfaces to determine if there are any neighbors on those links. OSPF Hello packets are sent as multicast to an address reserved for ALLSPFRouters at 224.0.0.5 (By default, OSPF Hello packets are sent every 10 seconds on multiaccess and point-to-point segments and every 30 seconds on non-broadcast multiaccess (NBMA) segments (Frame Relay, X.25, ATM). )
   
2. Before two routers can form an OSPF neighbor adjacency, they must agree on three values: Hello interval, Dead interval, and network type.
3. Send Link-state updates (LSUs) to advertise routing information. An LSU packet can contain 11 different types of Link-State Advertisements (LSAs).
•  LSA type: 1    Router LSAs
• type 2             Network LSAs
• type 3 or 4      Summary LSAs
• type 5             Autonomous System Extrenal LSAs
• type 6             Multicast OSPF LSAs
• type 7             Defined for Not-So-Stubby Areas
• type 8             External Attributes LSA for BGP
• type 9,10,11   Opaque LSAs
  
4. Each OSPF router maintains a link-state database containing the LSAs received from all other routers. Once a router has received all of LSAs and built its local link-state database.
   
5. OSPF uses Dijkstra's shortest path first (SPF) algorithm to create an SPF tree. 
6. The SPF tree is then used to populate the IP routing table with the best paths to each network.
   

Eigrp - what happens after network command is issued

Here is EIGRP message

As soon as you configure network command on eigrp, following things happen in the given order:

Step 1. Hellos are sent.

Step 2. Receive Update.

Step 3. Run the dual and install the best route for the network learned in 2nd step.

Step 4. Send update about that interface.

An important observation here is that first of all, the above 4 steps are executed for directly connected networks.

You must be knowing this..i guess..

But notice their order..

Suppose there are two routers R1 and R2 connected via a serial link

Suppose there is a fast ethernet on each of the router R1 and R2..

Let the serial interfaces be named as R1S and R2S.

Let the fast ethernet interfaces be named as R1F and R2F

So R1 and R2 are connected via R1S and R2S...

As soon as u configure the network command, following things happen on Router R1..

a) Hello sent to R1F

b) Received update from R1F about that network

c) Run Dual and calculate the best path with the available data and feasible successor for the network learnt in step b. Enter the successor in routing table.

So you see, although local networks are already in the routing table, yet DUAL recalculates the best path and recreate the routing table with that network ..

d) Send update about network of R1F

"" At this stage ROUTING TABLE IS CREATED ( With one fastethernet network )...although Hellos are YET TO BESENT TO serial interface R1S. """

e) Hello sent to R1S

f) Received update from R1S about that network

g) Run Dual and calculate the best path and feasible successor for the network learnt in step f. Enter the successor in routing table.

h) Send update about network of R1S

After the above steps, neighbour adjancency is established with R2 if all the parameters are okay..

SO IT MEANS HELLOS ARE NOT IMMEDIATELY SENT ON ALL THE APPROPRIATE INTERFACES..

It is sent on one interface and then above 4 steps get executed in the above order.

Then hello is sent on 2nd interface and then again above 4 steps get executed in the given order.

Similar process goes on for the other interfaces that are enabled for receiving and sending EIGRP updates.

So routing table is created (though it is not complete) BEFORE hellos are sent out all the appropriate interfaces.

ref.:https://cisco.hosted.jivesoftware.com/message/5596

Sample IPTABLES configuration for workstation

# /etc/sysconfig/iptables
#
# IPTABLES sample config file for workstation
#
# Make sure you fix the appropriate <IPADDR> sections below, and add
# duplicate entries as necessary (with different IPADDR's of course)

# created by Bryan Cardillo
# modified by Daniel Widyono

# default policy - deny
#
# allow unrestricted icmp (should be tightened)
# allow in/out dns to name servers
# allow in/out ntp to ntp servers
# allow unrestricted ssh out
# allow ssh in from designated hosts
# allow unrestricted in/out from internal interfaces
# allow amanda server to contact and backup local filesystems
# allow http, https access out
# allow lpr client out
# allow ftp client out

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]



# LOGGING / DEBUGGING
-N accept-n-log
-A accept-n-log -j LOG --log-level 4 --log-prefix "accept-n-log:"
-A accept-n-log -j ACCEPT
-N drop-n-log
-A drop-n-log -j LOG --log-level 4 --log-prefix "drop-n-log:"
-A drop-n-log -j DROP



# internal interfaces
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT



# all outgoing
-A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT



# icmp
-A INPUT -p icmp -j ACCEPT



# ssh client
-A INPUT -p tcp -m tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT



# http client
-A INPUT -p tcp -m tcp --sport http --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport https --dport 1024: -m state --state ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport webcache --dport 1024: -m state --state ESTABLISHED -j ACCEPT



# lpr client
-A INPUT -p tcp -m tcp --sport printer -m state --state ESTABLISHED -j ACCEPT



# ftp client (active and passive)
-A INPUT  -p tcp -m tcp --sport ftp -m state --state ESTABLISHED -j ACCEPT
-A INPUT  -p tcp -m tcp --sport ftp-data -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT  -p tcp -m tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT

RIP Timers

RIP uses four different kinds of timers to regulate its performance:

Route update timer   Sets the interval (typically 30 seconds) between periodic routing updates
in which the router sends a complete copy of its routing table out to all neighbors.

Route invalid timer   Determines the length of time that must elapse (180 seconds) before a
router determines that a route has become invalid. It will come to this conclusion if it hasn’t
heard any updates about a particular route for that period. When that happens, the router will
send out updates to all its neighbors letting them know that the route is invalid.

Holddown timer   This sets the amount of time during which routing information is sup-
pressed. Routes will enter into the holddown state when an update packet is received that indi-
cated the route is unreachable. This continues either until an update packet is received with a
better metric or until the holddown timer expires. The default is 180 seconds.

Route flush timer   Sets the time between a route becoming invalid and its removal from the
routing table (240 seconds). Before it’s removed from the table, the router notifies its neigh-
bors of that route’s impending demise. The value of the route invalid timer must be less than
that of the route flush timer. This gives the router enough time to tell its neighbors about the
invalid route before the local routing table is updated.

ref.: Cisco Certified Network Associate Study Guide

Virtual(portable) desktop for XP - using MojoPAC

Installation:
Step 1: go to the site http://www.mojopac.com/ and download mojopac
Step 2: When install the mojopac, you can select the locatation(C:, D: or removable USB) to install the virtual XP

When you finish the installation, you can find the mojo.exe, execute it to launch your virtual XP.
If you installed to other location, you can copy whole mojo directory to usb drive or other pc, so that you not need to install again.

Cisco router password recovery

step 1: press Ctrl+Break once the router boot up

step 2:
rommon 1>confreg 0x2142
rommon 2>reset

======================================================
remark:
0x2000 is boot default ROM software
0x0040 is ignore NVRAM
the last 2 is to specifies default boot file name

Router default register is 0x2102, you can check it by "sh version"

Ubuntu 9.04 on intel GMA500 configuration

sudo apt-get update
sudo apt-get dist-upgrade

sudo vi /etc/apt/sources.list.d/ubuntu-mobile.list
deb http://ppa.launchpad.net/ubuntu-mobile/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mobile/ppa/ubuntu jaunty main
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C6598A30
Now that your Ubuntu-Mobile Key is added do the Following.

The Following Packages need to be Installed Most are Dependences.
* psb-firmware - Binary firmware for the Poulsbo (psb) 3D X11 driver
* psb-modules - Kernel module built for -generic or -lpia kernel
* psb-kernel-source - Kernel module for the Poulsbo (psb) 2D X11 driver
* psb-kernel-headers - Kernel module headers for the Poulsbo (psb) 2D X11 driver
* xpsb-glx - X11 drivers for Poulsbo (psb) 3D acceleration
* poulsbo-driver-3d - Metapackage for the 3D Poulsbo (psb) X11 driver.
* poulsbo-driver-2d - Metapackage for the 2D Poulsbo (psb) X11 driver.

sudo apt-get update
sudo apt-get install poulsbo-driver-2d poulsbo-driver-3d psb-firmware
sudo apt-get install psb-kernel-source

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak

sudo vi /etc/X11/xorg.conf

############################
Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

Section "Device"
Identifier "Configured Video Device"
Option "AccelMethod" "EXA"
#Option "DRI" "off"
Option "IgnoreACPI" "yes"
Option "MigrationHeuristic" "greedy"
EndSection

Section "ServerFlags"
Option "DontZap" "False"
EndSection
##########################