Sunday, December 31, 2006
Welcome 2007!!!!
Monday, December 25, 2006
New Snort v 2.6.1.2
http://snort.org/dl/current/snort-2.6.1.2.tar.gz
Saturday, December 23, 2006
The Snort Top 10???
1. The Snort.conf file
2. Variables
3. Frag3 preprocessor
4. HTTP inspection preprocessor
5. Portscan preprocessor
6. The rest of the preprocessor to include the new "dynamic" preprocessors.
7. Rules
8. Output
9. Barnyard
10. Rule updates
The most important are variables and the rules. In variables, HOME_NET should always be configured. Common settings for HOME_NET should be your whole internal network. By default, EXTERNAL_NET is set to "any". "Any" also includes your HOME_NET. To make sure your Snort capture traffic that is NOT in your HOME_NET as EXTERNAL, you can set your "EXTERNAL_NET" to "!$HOME_NET".
The rules is very important in Snort. Turn OFF any rules category that have no application services running in your network. You can combine more than one rulesets in your Snort. If you want to combine two or three rulesets together, sure you can do it. For example, you can combine BleedingThreat ruleset with Snort VRT ruleset. However, you need to go through each rule file, and turn on/off what you are not interested in or what does not apply to your network. Snort rules is very important in order to minimize false positive alerts.
http://isc.sans.org/diary.php?storyid=1967
Zone-H to be zone hacked????
http://www.zone-h.org/content/view/14458/31/
Monday, December 18, 2006
PHP - Pretty Hard to Protect???
http://www.securityfocus.com/news/11430
Sunday, December 17, 2006
Sebek (Honeynet Tool)
http://www.honeynet.org/tools/sebek/
You also can see this link below about Sebek3:
http://www.securityfocus.com/infocus/1855
http://www.securityfocus.com/infocus/1858
I think i want to test it during my free time because i never develop, deploy and test honeynet technologies before this.
Saturday, December 16, 2006
Snort Inline (Nmap result)
Victim IP: 192.168.1.70
I’m testing it using this command:
nmap –P0 192.168.1.70
What we can see here, when the attacker is trying to attack 192.168.1.70. See the result here:
tail -f /var/log/snort/snort_inline-fast
tail -f /var/log/snort/snort_inline-full
Alert 1:
12/17-03:31:49.442610 [**] [1:1418:11] SNMP request tcp
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49786 -> 192.168.1.70:161
12/17-03:31:49.885321 [**] [1:1418:11] SNMP request tcp
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49787 -> 192.168.1.70:161
SNMP request tcp?? What does it means?
This event is generated when an SNMP-Trap connection over TCP to an SNMP
daemon is made. An attacker sends a packet directed to tcp port 161, if sucessful a
reply is generated and the attacker may then launch further attacks
against the SNMP daemon.
Alert 2
12/17-03:33:22.683878 [**] [1:1421:11] SNMP AgentX/tcp request
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49786 -> 192.168.1.70:705
12/17-03:33:23.152793 [**] [1:1421:11] SNMP AgentX/tcp request
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49787 -> 192.168.1.70:705
SNMP AgentX/tcp reques???
This event is generated when an attempt is made to attack a device using SNMP v1. Varies depending on the implementation. Ranges from Denial of Service (DoS) to code execution. A number of vulnerabilities exist in SNMP v1, including a community string buffer overflow, that will allow an attacker to execute arbitrary code or shutdown the service. An attacker needs to send a specially crafted packet to UDP port 705 of a vulnerable device, causing a Denial of Service or possible execution of arbitrary code.
Alert 3:
12/17-03:33:24.532724 [**] [1:1420:11] SNMP trap tcp
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49786 -> 192.168.1.70:162
12/17-03:33:25.010310 [**] [1:1420:11] SNMP trap tcp
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.1.30:49787 -> 192.168.1.70:162
The SNMP (Simple Network Management Protocol) Trap daemon usually listens on port 162, tcp or udp. An attacker sends a packet directed to tcp port 162, if successful a reply is generated and the attacker may then launch further attacks against the SNMP daemon.
We can conclude that the attacker is trying to find open ports in 192.168.1.70. The attacked was not successful because firewall/IPS blocked it. This is simple analysis. If you want more details about this, use Google , hehehe...
Friday, December 15, 2006
Password Management Concerns with IE and Firefox, (Part 2)
http://www.securityfocus.com/infocus/1883
Thursday, December 14, 2006
Tcpdump (Part One)
http://www.tcpdump.org/
Here, i will discuss about basic usage of Tcpdump. I'm using FreeBSD and you can install it from FreeBSD port. A port of newest version available in /usr/ports/net/tcpdump.
tcpdump –n –i
This syntax:
-n : Not resolve IP addresses to domain names and port numbers to service names
-i
-s
-n, -i and -s switches mandatory will prevent many problems such as packet loss. I read from The Tao of Network Security Monitoring Beyond Intrusion Detection book. One of the first recommendations from him was disabling name resolution because the user was sending Tcpdump output to a text file. You need to specify an interface with -i to ensure that you're sniffing where you expect to sniff. He said that if you don't tell Tcpdump a snaplen value, it defaults to collect 68 bytes. With the average IP header being 20 bytes, and the TCP header being 20 bytes without options, only 28 bytes are left for application data. If 20 or more bytes of TCP options are present, hardly any application data might be seen. Nothing is more frustrating than deploying a sensor to log full content data only to find most of the content was lost.
tcpdump –n –i
-w: Output tcpdump to specific file
Figure 1: Example of tcpdump to store full content data
How to read stored full content data???
You can use it to read trace files and see what they contain using the –r plus the name of the captured file to see its contents.
E.g: tcpdump -n -r zaha.lpc -c 5 (-c 5 to specify showing only 5 packets)
Figure 3: Example of tcpdump to read only 5 packet.
tcpdump -n -r zaha.lpc -c 5 tcp ( shows only 5 packets of TCP)
tcpdump -n -r zaha.lpc -c 5 udp ( shows only 5 packets of TCP)
Tcpdump representation of ICMP
Because ICMP has no concept of ports, the output is very simple for this example:
19:47:27. 18921 IP 192.168.1.101 > 209.73.186.238 :ICMP echo request, id 41992
19:47:27. 18921 - Timestamp
192.168.1.101 - Source IP
> - Direction Indicator
209.73.186.238 - Destination IP
ICMP echo request - ICMP message type
Tcpdump representation of UDP
Tcpdump representation in UDP is very easy. Tcpdump doesn't know how to interpret traffic to port 6348 , so it presents the information we see below.
19:15:01. 022565 IP 192.168.1.101.3743 > 83.24.191.219.6348: UDP, length 33
19:15:01. 022565 - Timestamp
192.168.1.101 - Source IP
3743 - Source port
> - Direction Indicator
83.24.191.219 - Destination IP
6348 - Destination port
UDP, length 33 - Size of UDP datagram in bytes
Tcpdump representation of TCP
TCP is more complicated than ICMP or UDP.
Packet1:
20:25:29.153180 192.168.1.100.34800 > 192.168.1.70.4201: S 3254677536:3254677536(0) win 5630
Packet 2:
20:25:2.153301 192.168.1.70.4201 > 192.168.1.100.34800: S 3206427300:3206427300(0) ack 3254677537 win 17520
Packet3:
2025:29.153767 192.168.1.100.34800 > 192.168.1.70.4201 . ack 3206427301 win 5630
Packet 1 analysis:
20:25:29.153180 -Timestamp
192.168.1.100 - Source IP
34800 - Source port
> - Direction Indicator
192.168.1.70 - Destination IP
4201 - Destination port
S - TCP SYN flag is set
3254677536 - TCP initial sequence number (ISN)
3254677536 - Sequence number of the next byte of application data expected by
TCP
0 - Count of application data in this segment
win 5630 - Size of the TCP window in bytes
mss 1460 - TCP option for maximum segment size (MSS) set to 1460 bytes
sackOK -Selective acknowledgement, another TCP option, supported by the
source host
timestamp 27027249 - Timestamp value (27027249) and timestamp echo reply setting (0)
o - Means "no operation"; included to pad the TCP options section
appropriately
wscale0 - Sender supports TCP window scaling; current multiplier is
(DF) - Specifies "do not fragment" for this packet
This represent three-way handshake. Packet 1 is the first step of 3-way handshake. The next two packets are packet 2 and packet 3 .
This is part one of Tcpdump. This is more on introduction to Tcpdump and the basic usage of tcpdump. In part two, i will discuss more about the usage of Tcpdump tool. If you want to learn more about TCPdump, you must have understanding about TCP/IP.
Tuesday, December 12, 2006
Microsoft Word 0 day Vulnerability Reported
More details available at SANS Internet Storm Center Diary:
http://isc.sans.org/diary.php?storyid=1925
The POC is available here:
http://milw0rm.com/exploits/2922
Affected Products:
Microsoft Word 2000
Microsoft Word 2002
Microsoft Word 2003
Microsoft Word Viewer 2003
Monday, December 11, 2006
How to detect an Intruder???
- Check your log files for any external locations , other unknown locations or other unusual activity.
- E.g: Check your last login, logs created by syslog, process accounting and other security logs
- Use netstat -natup to check for illegal connection
- Look for setuid or setgid files especially setuid root files in your systems. Intruders often leave setuid in /bin/bash or /bin/time.
- E.g: find / -user root -perm -4000 -print
- or find / -group kmem -perm -2000 -print
- Check your binaries system to make sure that they haven't been altered such as login, su, telnet, netstat, ifconfig, ls, find, du, df, and other binaries. Use can use rootkit detector such as chkrootkit tool.
- Check your systems for unauthorized use of a network monitoring program or packet sniffer. Maybe intruders may use a sniffer to capture your username and password info.
- Examine all the files that are run by 'cron'. Normally intruders leave backdoors in this file to let he back on the system. Verify all files /programs by cron jobs.
- Check for unauthorized services. Check /etc/inetd.conf file for unauthorized changes. Also check the legitimate services that you have commented in that file.
- Examine the /etc/passwd file on the system and check for any modifications to it. Look for unauthorized creation of new accounts, accounts with no passwords, or UID changes to existing accounts.
- Check your system and network configuration files for unauthorized entries. Look for additional entries or inappropriate non-local host names in /etc/hosts, /etc/hosts.allow or /etc/hosts.deny.
- Look for unusual or hidden files as these can be used to hide tools and information. Examine "..." or ".." or ".xx" file. Maybe this is hidden files hide by attacker.
- Check all PC's or servers on your network for signs of intrusion.
Enjoy it!!
Intrusion Detection, Honeypots and Incident Handling
http://www.honeypots.net/
I hope this link will help you to improve knowledges about network security concept, network security procedures and other things related to it.
Sunday, December 10, 2006
Password Management Concerns with IE and Firefox (Part 1)
http://www.securityfocus.com/infocus/1882
Saturday, December 09, 2006
Data Security Summary July-Dec 2006
http://www.f-secure.com/2006/2/
I think this article is helpful for you as a security analyst.
Thursday, December 07, 2006
Snort Inline (Part 2)
In a kernel, when a packets received, it runs through ipfw rules. After that, when a rule matches on divert line, packet is sent to divert socket port 600 for processing (In this example, i choose port 600 as a divert port). And then snort_inline received packet on divert port 600. When received packet, snort_inline checks packet against IDS rules and determine what to do with it :
- Rejected (packet is dropped and a TCP reset is send to the sender)
- Dropped (packet is dropped and not inserted back into ipfw)
- Accepted (packet is reinserted at the next ipfw rule number)
Note: Kernel does not keep track of successfully received packet by snort_inline. If nothing is listening on port 600 and you have a ipfw divert rule sending packets to port 600, the packets are dropped.
Firstly, you must install snort_inline in your FreeBSD box and you should simply have to cd/usr/ports/security/snort_inline && make install clean. To setup this, the first thing you need to recompile your FreeBSD kernel and add the following options:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
After recompile your FreeBSD kernel, you need to add the following options in /etc/rc.conf file. In this testing, i'm using 'open' firewall ruleset in /etc/rc.firewall.
firewall_enable="YES"
firewall_type="open"
firewall_script="/etc/rc.firewall"
firewall_quite="NO"
To start it, you need to tell snort_inline to receive packets from divert port 600, using the following steps:
# cd /usr/local/etc/
# snort_inline -J 600 -c snort_inline.conf
and you will see snort_inline running successfully.
Look at my ipfw firewall ruleset using this command:
#ipfw list
You need to find a spot which rule number you want to insert the ipfw divert rule. We know that ipfw uses a linear ruleset processing order. Here we can see a rule number 65000 allows 'ip from any to any'. We must insert ipfw divert port before 65000. This is due to the fact that once a rule is matched, the packet does not get checked against anything else. If we insert it after 65000, packets will not reach snort_inline.
So, i add to rule number 3000 to divert port 600 using this command:
#ipfw add 3000 divert 600 ip from any to any
And then list the ruleset:
#ipfw list
I'm using 7 Sphere PortScan 1.1 to scan and test my snort_inline. The result is here:
Result from tail -f /var/log/snort/snort_inline-fast
Result from tail -f /var/log/snort/snort_inline-full
Yes!! Successful!!
I have actually read it sometimes ago, however tend to forget because of lacking practice on it.
Wednesday, December 06, 2006
Snort Inline
http://snort-inline.sourceforge.net/
This is an article about Snort Inline:
http://en.hakin9.org/attachments/hakin9_6-2006_str22-33_snort_EN.pdf
Today, i'm still testing this snort_inline. I hope i will get a good result from it.
Pantera Web Assessment
Pantera is a powerful web application analysis engine that is used for penetration testing.
If you want to install Pantera, you need to install:
- Python 2.4
- MySQL 5 (Due to the use of triggers)
- pyOpenSSL
You can get more information about Pantera here:
http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project
I've been busy to test it. Maybe i will test it later.
Sguil NSM
Now, i'm doing a research about Sguil network security monitoring. I'm happy using this tool because i think this is the best tool for analyzing the packets. I combined this tool with rules from BleedingEdgeThreats (previously known as BleedingSnort). I'm still doing a lot of research about this for my job. I think as a security analyst, better you try this tool. You can get more information about this from here:
New Windows tool -PWDumpX v1.0
I got this tool from pen-test@securityfocus.com. PWDumpX v1.0 allows a user to retrieve the encrypted password hashes and LSA secrets from a Windows system. This tool written by Reed Arvin. More information about this tools:
http://reedarvin.thearvins.com/tools.html
Tool location: http://reedarvin.thearvins.com/tools/PWDumpX.zip
You need to unzip this tool to any folder in Windows and run it using Command Prompt. This is capture screen from PWDump:
Password for current user:
I think this tool is better than previous pwdump.
Tuesday, December 05, 2006
Shorewall Firewall
At this time, I have more things to read. I have to strengthen my knowledge about network security monitoring and firewall. I'm still doing testing about netfilter and ipfilter firewall. So, i spare my time to test Shorewall in Fedora Linux Core 3.
What is Shorewall?? Shorewall is a high-level tool for configuring Netfilter. It work with the help of the iptables utility an configures Netfilter to match your requirements. More information about it: http://www.shorewall.net/index.htm
I download Shorewall version 3.2 rpm package for Redhat/Fedora. Everthing is there, you just uncomment whatever you want to customize to ensure it work properly. I setup it on IP 10.1.2.32 and I only allow SSH connection from specific PC. I just added one rule in /etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE PORT PORT(S) DEST LIMIT #SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW
ACCEPT net:10.1.2.29 $FW tcp 22
I log it to /var/log/messages and then i'm trying to SSH from 10.1.2.21. I view it's log (tail -f /var/log/messages):
Dec 5 01:21:28 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4919 DF PROTO=TCP SPT=42368 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 5 01:21:37 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4923 DF PROTO=TCP SPT=42368 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
What we can see above, it dropped packets for SSH connection from 10.1.2.21 to 10.1.2.32. And then i tried to ping 10.1.2.32. We can see from this, it also dropped ICMP packet because i configure to dropped it:
Dec 5 02:07:14 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=56851 SEQ=0
Dec 5 02:07:15 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=1 DF PROTO=ICMP TYPE=8 CODE=0 ID=56851 SEQ=1
After that, i run curl --head 10.1.2.32 from IP 10.1.2.21 to test HTTP connection and it also dropped the packet:
Dec 5 02:12:31 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=943 DF PROTO=TCP SPT=36311 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 5 02:12:34 monitoring12 kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:07:e9:f1:9f:85:00:07:e9:f1:a0:85:08:00 src=10.1.2.21 DST=10.1.2.32 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=945 DF PROTO=TCP SPT=36311 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
I edit /etc/shorewall/rules and then modify the rules above with this rules to allow SSH connection from 10.1.2.21:
ACCEPT net:10.1.2.21 $FW tcp 22
After that, i run /etc/init.d/shorewall restart to restart Shorewall with new rules:
Dec 5 01:56:54 monitoring12 shorewall: Compiling...
Dec 5 01:56:54 monitoring12 shorewall: Initializing...
Dec 5 01:56:54 monitoring12 shorewall: Determining Zones...
Dec 5 01:56:54 monitoring12 shorewall: IPv4 Zones: net
Dec 5 01:56:54 monitoring12 shorewall: Firewall Zone: fw
Dec 5 01:56:54 monitoring12 shorewall: Validating interfaces file...
Dec 5 01:56:54 monitoring12 shorewall: Validating hosts file...
Dec 5 01:56:54 monitoring12 shorewall: Validating Policy file...
Dec 5 01:56:54 monitoring12 shorewall: Determining Hosts in Zones...
Dec 5 01:56:54 monitoring12 shorewall: net Zone: eth0:0.0.0.0/0
Dec 5 01:56:55 monitoring12 shorewall: Pre-processing Actions...
Dec 5 01:56:55 monitoring12 shorewall: Pre-processing /usr/share/shorewall/action.Drop...
Dec 5 01:56:55 monitoring12 shorewall: Pre-processing /usr/share/shorewall/action.Reject...
Dec 5 01:56:55 monitoring12 shorewall: Pre-processing /usr/share/shorewall/action.Limit...
Dec 5 01:56:55 monitoring12 shorewall: Deleting user chains...
Dec 5 01:56:55 monitoring12 shorewall: Compiling /etc/shorewall/routestopped ...
Dec 5 01:56:55 monitoring12 shorewall: Compiling Accounting...
Dec 5 01:56:55 monitoring12 shorewall: Creating Interface Chains...
Dec 5 01:56:55 monitoring12 shorewall: Compiling Proxy ARP
Dec 5 01:56:55 monitoring12 shorewall: Compiling NAT...
Dec 5 01:56:55 monitoring12 shorewall: Compiling NETMAP...
Dec 5 01:56:55 monitoring12 shorewall: Compiling Common Rules
Dec 5 01:56:55 monitoring12 shorewall: Compiling IP Forwarding...
Dec 5 01:56:55 monitoring12 shorewall: Compiling IPSEC...
Dec 5 01:56:55 monitoring12 shorewall: Compiling /etc/shorewall/rules...
Dec 5 01:56:55 monitoring12 shorewall: Compiling /etc/shorewall/tunnels...
Dec 5 01:56:55 monitoring12 shorewall: Compiling Actions...
Dec 5 01:56:55 monitoring12 shorewall: Compiling /usr/share/shorewall/action.Drop for Chain Drop...
Dec 5 01:56:55 monitoring12 shorewall: Compiling /usr/share/shorewall/action.Reject for Chain Reject...
Dec 5 01:56:56 monitoring12 shorewall: Compiling /etc/shorewall/policy...
Dec 5 01:56:56 monitoring12 shorewall: Compiling Masquerading/SNAT
Dec 5 01:56:56 monitoring12 shorewall: Compiling /etc/shorewall/tos...
Dec 5 01:56:56 monitoring12 shorewall: Compiling /etc/shorewall/ecn...
Dec 5 01:56:56 monitoring12 shorewall: Compiling Traffic Control Rules...
Dec 5 01:56:56 monitoring12 shorewall: Validating /etc/shorewall/tcdevices...
Dec 5 01:56:56 monitoring12 shorewall: Validating /etc/shorewall/tcclasses...
Dec 5 01:56:56 monitoring12 shorewall: Compiling Rule Activation...
Dec 5 01:56:56 monitoring12 shorewall: Compiling Refresh of Black List...
Dec 5 01:56:56 monitoring12 shorewall: Compiling Refresh of /etc/shorewall/ecn...
Dec 5 01:56:56 monitoring12 shorewall: Validating /etc/shorewall/tcdevices...
Dec 5 01:56:56 monitoring12 shorewall: Validating /etc/shorewall/tcclasses...
Dec 5 01:56:56 monitoring12 shorewall: Shorewall configuration compiled to /var/lib/shorewall/.restart
Dec 5 01:56:56 monitoring12 shorewall: Processing /etc/shorewall/params ...
Dec 5 01:56:56 monitoring12 shorewall: Restarting Shorewall....
Dec 5 01:56:57 monitoring12 shorewall: Initializing...
Dec 5 01:56:57 monitoring12 shorewall: Processing /etc/shorewall/init ...
Dec 5 01:56:57 monitoring12 shorewall: Clearing Traffic Control/QOS
Dec 5 01:56:57 monitoring12 shorewall: Deleting user chains...
Dec 5 01:56:57 monitoring12 shorewall: Processing /etc/shorewall/continue ...
Dec 5 01:56:57 monitoring12 shorewall: WARNING: DISABLE_IPV6=Yes in shorewall.conf but this system does not appear to have ip6tables
Dec 5 01:56:57 monitoring12 shorewall: Enabling Loopback and DNS Lookups
Dec 5 01:56:57 monitoring12 shorewall: Setting up Accounting...
Dec 5 01:56:57 monitoring12 shorewall: Creating Interface Chains...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Proxy ARP...
Dec 5 01:56:57 monitoring12 shorewall: Setting up one-to-one NAT...
Dec 5 01:56:57 monitoring12 shorewall: Setting up SMURF control...
Dec 5 01:56:57 monitoring12 shorewall: Processing /etc/shorewall/initdone ...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Black List...
Dec 5 01:56:57 monitoring12 shorewall: Setting up ARP filtering...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Accept Source Routing...
Dec 5 01:56:57 monitoring12 shorewall: IP Forwarding Enabled
Dec 5 01:56:57 monitoring12 shorewall: Setting up SYN Flood Protection...
Dec 5 01:56:57 monitoring12 shorewall: Setting up IPSEC management...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Rules...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Tunnels...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Actions...
Dec 5 01:56:57 monitoring12 shorewall: Creating action chain Drop
Dec 5 01:56:57 monitoring12 shorewall: Creating action chain Reject
Dec 5 01:56:57 monitoring12 izhar: Shorewall restarted
Dec 5 01:56:57 monitoring12 shorewall: Creating action chain dropBcast
Dec 5 01:56:57 monitoring12 shorewall: Creating action chain dropInvalid
Dec 5 01:56:57 monitoring12 shorewall: Creating action chain dropNotSyn
Dec 5 01:56:57 monitoring12 shorewall: Applying Policies...
Dec 5 01:56:57 monitoring12 shorewall: Setting up Masquerading/SNAT...
Dec 5 01:56:57 monitoring12 shorewall: Setting up TOS...
Dec 5 01:56:57 monitoring12 shorewall: Setting up ECN...
Dec 5 01:56:57 monitoring12 shorewall: Setting up TC Rules...
Dec 5 01:56:57 monitoring12 shorewall: Activating Rules...
Dec 5 01:56:57 monitoring12 shorewall: Processing /etc/shorewall/start ...
Dec 5 01:56:57 monitoring12 shorewall: Processing /etc/shorewall/started ...
Dec 5 01:56:57 monitoring12 shorewall: done.
Dec 5 01:56:57 monitoring12 shorewall: shorewall startup succeeded
An then SSH to IP 10.1.2.32 from 10.1.2.21 and ...it works!!!.:
Dec 5 02:01:01 monitoring12 crond(pam_unix)[7812]: session opened for user root by (uid=0)
Dec 5 02:01:01 monitoring12 crond(pam_unix)[7812]: session closed for user root
Dec 5 02:01:20 monitoring12 sshd(pam_unix)[7816]: session opened for user john by (uid=0)
Dec 5 02:02:03 monitoring12 sshd(pam_unix)[7816]: session closed for user john
Conclusion: My firewall works!!!! Enjoy this firewall for newbies!!