LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: April 7th, 2014
Linux Advisory Watch: April 4th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
( Logs ) - Now that I have IP Masquerading up, I'm getting all sorts of weird notices and errors in the SYSLOG log files. How do I read the IPTABLES/IPCHAINS/IPFWADM firewall errors?

7.20. ( Logs ) - Now that I have IP Masquerading up, I'm getting all sorts of weird notices and errors in the SYSLOG log files. How do I read the IPTABLES/IPCHAINS/IPFWADM firewall errors?

There is probably a few common things that you are going to see:

  • MASQ: Failed TCP Checksum error: You might see this error when a packet coming from the Internet gets corrupt in the data section of the packet but the rest of it "seems" ok. When the Linux box receives this packet, it will calculate the CRC of the packet and determine that its corrupt. On most machines running OSes like Microsoft Windows, they just silently drop the packets but Linux IP MASQ reports it. If you get a LOT of them over your PPP link, first follow the FAQ entry above for "(Performance) - Masq seems is slow".

    If the (Performance) FAQ tips don't help and you run PPP over dialup or PPPoE, you might try adding the line "-vj" (disabled VanJacobson header compression) to your /etc/ppp/options file and restart the PPPd connection.

  • Firewall hits: Because you are on the Internet with a decent firewall, you will be surprised with the number of users trying to penetrate your Linux box! So what do all these firewall logs mean?

    More so, if they are filling your logs, see the next FAQ entry on thoughts how to reduce all these log entries.

  • The following details are from the TrinityOS - Section 10 documentation I also wrote:

        With the use of various firewall rulesets, a given ruleset can either 
        DENY (silently drop) or REJECT traffic (sends back a ICMP error).  If 
        firewall logging is enabled, the errors will show up in the SYSLOG
        "messages" file found at:
    
            Redhat: 	/var/log
            Slackware:	/var/adm
    
        If you take a look at one of these firewall logs, you would see something 
        like:
    
        ---------------------------------------------------------------------
        IPTABLES:
        ---------
        Feb 23 07:37:01 Roadrunner kernel: IPTABLES IN=eth0 OUT= 
          MAC=00:50:da:2e:e5:fb:00:03:47:73:c9:d2:08:00 SRC=12.75.147.174 
          DST=100.200.0.212 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=39034 DF PROTO=TCP 
          SPT=4313 DPT=23 WINDOW=32120 RES=0x00 SYN URGP=0
    
     
        IPCHAINS:
        ---------
        Feb 23 07:37:01 Roadrunner kernel: input REJECT eth0 PROTO=6 
          12.75.147.174:1633 100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64
    
    
        IPFWADM:
        --------
        Feb 23 07:37:01 Roadrunner kernel: IP fw-in rej eth0 TCP 12.75.147.174:1633 
          100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64
    
        ---------------------------------------------------------------------
    
    There is a LOT of information in just this one line of SYSLOG.  Lets break
    out this example.  You should refer back to the original firewall hit as you 
    read this.  
    
    --------------
    
        1. ===================================================================
    
    	- This packet firewall "hit" occurred on "Feb 23 07:37:01"
    
        2. ===================================================================
    
    	- This packet was logged on the "RoadRunner" computer via the kernel
    
        3. ===================================================================
    
    	- IPTABLES: the SYSLOG prepend string is "iptables" for information purposes
    
        - IPCHAINS: the packet was stopped on the INPUT chain
    
        - IPFWADM:  the packet was an IP packet
    
        4. ===================================================================
    
        - IPTABLES: the packet came IN on interface "eth0"
    
        - IPCHAINS: the packet was REJECTED (vs. dropped or accepted)
    
        - IPFWADM:  the packet was stopped on INPUT (vs. "fw-out" for OUT or 
           "fw-fwd" for FORWARD)
    
        5. ===================================================================
    
        - IPTABLES: the packet had NO output interface
    
        - IPCHAINS: the packet came in on the "eth0" interface
    
        - IPFWADM:  the packet was REJECTED "rej" (vs. "deny" or "accept")
    
        6. ===================================================================
    
        - IPTABLES: this display's the MAC address of the source and destination
                    Ethetnet MAC address (only relivant for Ethernet networks)
    
        - IPCHAINS: the packet was IP protocol 6 or TCP
    		        * If you don't know that protocol 6 is for TCP, look at 
                      your /etc/protocols file to see what other protocol numbers
                      are used for.
    
        - IPFWADM:  the packet on the "eth0" interface 
    
        7. ===================================================================
    
        - IPTABLES: the packet's source IP address was 12.75.147.174
    
    	- IPCHAINS: the packet's source IP address was 12.75.147.174
    
        - IPFWADM:  the packet was a "TCP" packet 
    
        8. ===================================================================
    
    	- IPTABLES: the packet's destination IP address was 100.200.0.212
    
        - IPCHAINS: the packet's source PORT was 1633 
    
        - IPFWADM:  the packet's source IP address was 12.75.147.174
    
        9. ===================================================================
    
        - IPTABLES: the packet's length was 44 bytes
    
    	- IPCHAINS: the packet's destination IP address was 100.200.0.212
    
        - IPFWADM:  the packet's source PORT was 1633
    
        10. ===================================================================
    
        - IPTABLES: the packet's TOS markings (type of service which basically
                    means class of service) was 0x00 or zero.
    
        - IPCHAINS: the packet's destination PORT was 23 (telnet)
    		        * If you don't know that port 23 is for TELNETing, look at 
                      your /etc/services file to see what other ports are used 
                      for.
    
        - IPFWADM:  the packet's destination IP address was 100.200.0.212 
    
        11. ===================================================================
    
        - IPTABLES: the packet's precedense markings (class of service) was 
                    0x00 or zero.
    
        - IPCHAINS: the packet's length was 44 bytes
    
        - IPFWADM:  the packet's destination PORT was 23 (telnet)
    		        * If you don't know that port 23 is for TELNETing, look at 
                      your /etc/services file to see what other ports are used 
                      for.
    
        12. ==================================================================
    
        - IPTABLES: the packet's TTL or Time to Live was 64 or 64 router hops
    		        * Every router hop over the Internet will subtract (1) from 
                      this number.  Usually, packets will start with a number of 
                      255 (depends on the operating system) and if that number 
                      ever reaches (0), it means that realistically, the packet 
                      was lost in a network loop and should be deleted. 
    
        - IPCHAINS: the packet's TOS markings (type of service which basically
                    means class of service) was 0x00 or zero.
    		        * divide this by 4 to get the Type of Service (presidence) 
    
        - IPFWADM:  the packet was 44 bytes long
    
        13. ==================================================================
    
    	- IPTABLES: the packet had various TCP flags set such as SYN, SYN+ACK,
                    etc. (shown in HEX)
    
        - IPCHAINS: the packet had various TCP flags set (shown in hex)
    
        - IPFWADM:  the packet's TOS markings (type of service which basically
                    means class of service) was 0x00 or zero.
    
        14. ==================================================================
    
    	- IPTABLES: the packet's "don't fragment" or DF bit was set from the 
                    source computer
    
        - IPCHAINS: the packet had a fragmentation offset of 40 (shown in HEX)
    
    		        --Don't worry if you don't understand this.. 
    		        * A value that started with "0x2..." or "0x3..." means the 
                      "More Fragments" bit was set so more fragmented packets 
                      will be coming in to complete this one BIG packet.
    		        * A value which started with "0x4..." or "0x5..." means that 
                      the "Don't Fragment" bit was set  
    		        * Any other values are the Fragment offset (divided by 8) to 
                      be later used to recombine into the original LARGE packet
    
    	- IPFWADM:  the packet had various TCP flags set such as SYN, SYN+ACK,
                    etc. (shown in HEX)
    
        15. ==================================================================
    
    	- IPTABLES: the packet was a TCP packet
    
        - IPCHAINS: the packet's TTL or Time to Live was 64 or 64 router hops
    		        * Every router hop over the Internet will subtract (1) from 
                      this number.  Usually, packets will start with a number of 
                      255 (depends on the operating system) and if that number 
                      ever reaches (0), it means that realistically, the packet 
                      was lost in a network loop and should be deleted. 
    
        - IPFWADM:  the packet had a fragmentation offset of 40 (shown in HEX)
    
    		        --Don't worry if you don't understand this.. 
    		        * A value that started with "0x2..." or "0x3..." means the 
                      "More Fragments" bit was set so more fragmented packets 
                      will be coming in to complete this one BIG packet.
    		        * A value which started with "0x4..." or "0x5..." means that 
                      the "Don't Fragment" bit was set  
    		        * Any other values are the Fragment offset (divided by 8) to 
                      be later used to recombine into the original LARGE packet
    
        16. ==================================================================
    
        - IPTABLES: the packet's soure PORT was 4313
    
        - IPCHAINS: 
    
        - IPFWADM:  the packet's TTL or Time to Live was 64 or 64 router hops
    		        * Every router hop over the Internet will subtract (1) from 
                      this number.  Usually, packets will start with a number of 
                      255 (depends on the operating system) and if that number 
                      ever reaches (0), it means that realistically, the packet 
                      was lost in a network loop and should be deleted. 
    
        17. ==================================================================
    
        - IPTABLES: the packet's destination PORT was 23 (telnet)
    		        * If you don't know that port 23 is for TELNETing, look at 
                      your /etc/services file to see what other ports are used 
                      for.
    
        - IPCHAINS:
    
        - IPFWADM: 
    
        18. ==================================================================
    
        - IPTABLES: the packet's TCP window (sliding or selective TCP ack)
                    was 32120 bytes
    
        - IPCHAINS:
    
        - IPFWADM:
    
        19. ==================================================================
    
        - IPTABLES: the packet's TCP reserved bits were 0x00 (HEX) - unused
    
        - IPCHAINS:
    
        - IPFWADM:
    
        20. ==================================================================
    
        - IPTABLES: the packet's TCP header SYN bit was set
                    * IPTABLES displays all the TCP header bits by name and not
                      by a HEX dump
    
        - IPCHAINS:
    
        - IPFWADM:
    
        21. ==================================================================
    
        - IPTABLES: the packet's TCP header URGENT bit was set - rarely used
    
        - IPCHAINS:
    
        - IPFWADM:

    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Heartbleed: Security experts reality-check the 3 most hysterical fears
Open source trounces proprietary software for code defects, Coverity analysis finds
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.