Firewall Logging -How to

How to do things, solutions, recipes, tutorials
Post Reply
Message
Author
Mic67

Firewall Logging -How to

#1 Post by Mic67 »

By default in Puppy the firewall logging is not enabled
To enable it AFTER using the firewall wizard go to

/etc/rc.d

Then (right -mouse button) click on rc.firewall

choose open as text

Go to # -- Advanced Configuration Options -- #
and change the LOGGING from no to yes within the " "

LOGGING="yes"

Then go to # -- Advanced Firewall Behavior Options -- #



LOG_LIMIT=""
LOG_BURST="60"
LOG_LEVEL="notice"

Within the quotes
you can choose what you like although it may be possible to
getting flooded with the logs but this is what I have choosen
ie. no log limit, as I check the log frequently and empty it.

Then SAVE the changes and close the rc.firewall document.

What might be interesting is - that when you first log on to the net but dont
do anthing check the INPUT log. And see if there is anything there before
surfing, this is usually when the hackers first try to get your machine.
You will see their IP number proceeding the SRC=
example: SRC=211.251.142.65 Source IP address as the source address
of who attempted or did connect to your machine when you first gain
access to the net. My results were as expected :>()

LOG_LIMIT=""
LOG_BURST="60"
LOG_LEVEL="notice"

You will find the log at /var/log in the messages document

But in order to actually begin to log any thing you need to make a firewall rule
for what you want to log. You can google this for an answer...

But I choose to log all the INPUT so the rule is

iptables -I INPUT -j LOG

Now the -I in the above rule inserts the rule at the begining
of the INPUT chain, as the order of rules in IPTABLES is important
,so is using capitals where specified.

To enter the rule to the iptables open rxvt type the rule and enter.

To check the rule as entered in the iptables, in rxvt type
iptables -L -n -v
and enter
this will display the rules and their number in the chain
with detail

Now you can save this by - in rxvt
iptables-save
enter

And check againg the tables by
iptables -L -n -v

One note is that if you leave the text application open with
the logs in it it may not update the log to the most recent when
you look at it, close and them reopen the "message" document, there
are different ways of doing this, try what you like.

If anyone has anything to add or correct please do so.

Also if you use this and get, what you consider
interesting results just after logging in, message back to this thread....

YMMV
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.

Here is a little tutorial on decyphering the meaning of firewall logs.
http://logi.cc/linux/netfilter-log-format.php3

The items are explained in sequence:
Apr 16 00:30:45
megahard kernel: syslog prefix. It is not present if you read log messages from the console.
NF: D(I,Priv)
Enabled with: --log-prefix 'prefix'
An arbitrary, user defined log prefix. Including the spaces.
A trailing space is necessary to keep the prefix separate from the next token; this is a bug in netfilter.

IN=eth1 Interface the packet was received from. Empty value for locally generated packets.

OUT= Interface the packet was sent to. Empty value for locally received packets.

MAC=
00:80:8c:1e:12:60:
00:10:76:00:2f:c2:
08:00 Destination MAC=00:80:8c:1e:12:60,
Source MAC=00:10:76:00:2f:c2,
Type=08:00 (ethernet frame carried an IPv4 datagram)

SRC=211.251.142.65 Source IP address

DST=203.164.4.223 Destination IP address

LEN=60 Total length of IP packet in bytes

TOS=0x00 Type Of Service, "Type" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info below.

PREC=0x00 Type Of Service, "Precedence" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info below.

TTL=44 remaining Time To Live is 44 hops.

ID=31526 Unique ID for this IP datagram, shared by all fragments if fragmented.

CE Presumably the "ECN CE" flag (Congestion Experienced).
This seems to be wrong because according to RFC2481, the CE bit is located in the TOS field. Refer to the IP header info below.

DF "Don't Fragment" flag.

MF "More Fragments following" flag.

FRAG=179 Fragment offset in units of "8-bytes". In this case the byte offset for data in this packet is 179*8=1432 bytes.

OPT (0727..A200) Enabled with: --log-ip-options
IP options. This variable length field is rarely used. Certain IP options, f.e. source routing, are often disallowed by netadmins. Even harmless options like "Record Route" may only be allowed if the transport protocol is ICMP, or not at all.

PROTO=TCP Protocol name or number. Netfilter uses names for TCP, UDP, ICMP, AH and ESP. Other protocols are identified by number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers
SPT=4515 Source port (TCP and UDP). A list of port numbers is in your /etc/services. A complete list is in the file port-numbers

DPT=111 Destination port (TCP and UDP). See SPT above.

SEQ=1168094040 Enabled with: --log-tcp-sequence
Receive Sequence number. By cleverly chosing this number, a cryptographic "cookie" can be implemented while still satisfying TCP protocol requirements. These "SYN-cookies" defeat some types of SYN-flooding DoS attacks and should be enabled on all systems running public TCP servers.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

ACK=0 Same as the Receive Sequence number, but for the other end of the TCP connection.

WINDOW=32120 The TCP Receive Window size. This may be scaled by bit-shifting left by a number of bits specified in the "Window Scale" TCP option. If the host supports ECN, then the TCP Receive Window size will also be controlled by that.

RES=0x03 Reserved bits. The ECN flags "CWR" and "ECNE" will show up in the two least significant bits of this field. Refer to the TCP header info below.
URG Urgent flag. See URGP below.
ACK Acknowledgement flag.
PSH Push flag.
RST RST (Reset) flag.
SYN SYN flag, only exchanged at TCP connection establishment.
FIN FIN flag, only exchanged at TCP disconnection.

URGP=0 The Urgent Pointer allows for urgent, "out of band" data transfer. Unfortunately not all protocol implementations agree, so this facility is hardly ever used.

OPT (020405...300) enabled with: --log-tcp-options

TCP options. This variable length field gets a lot of use. Important options include: Window Scaling, Selective
Acknowledgement and Explicit Congestion Notification. Refer to the TCP header info below.
Unfortunately the rule number in the chain which matched the packet is for architectural reasons not available in netfilter logs. You will have to "cook your own" by using the user-prefix feature.
>>>>>>>>>>>>>>>>>>>>>

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#2 Post by Lobster »

Have created a page on the wiki for this info (have added but not formatted)
http://puppylinux.org/wikka/FireWall
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
craftybytes
Posts: 298
Joined: Fri 17 Nov 2006, 10:32
Location: QLD AUSTRALIA

RE: Firewall Logging -How to

#3 Post by craftybytes »

Puppy users need to be aware that if you change the 'rc.firewall' file for "logging" everything - as puppy has its logs stored in RAM whilst running (unless have full hard drive install) - the 'log' files will grow quite large very quickly when you are on the internet - so you may find that you will start to run out of RAM for running Puppy in normally...

It should be recommended that you only should activate 'log' actions on those INPUTS / OUTPUTS that you really want (or need) to check on and not on unwanted data ...

Because of the RAM 'limitation' that Puppy has, maybe we need to include a "size" limit to LOG files and include a 'flushing' script that monitors these log files and empties them when they reach the nominated limit - any ideas development team .. ?

Google for - IP Tables Packet Filtering HOWTO - to get further info on Iptables ..
3 x boot:- ASROCK VIA 'all-in-one' m/b; AMD Duron 1.8Ghz+; 1.0GB RAM; 20GB hdd (WinXP Pro); 80GB hdd (MEPIS 3.4-3/Puppy v2.15CE Frugal); 1GB USB pendrive (Puppy 2.15CE Frugal); CD/DVDRW; 17" LCD monitor; HSF 56k modem... MEPIS is great.. Puppy ROCKS..

Mic67

#4 Post by Mic67 »

The basic how to of the firewall log was just how to activate it, find the location of where the output of the log was and how to understand the results. By logging all the the activity on the INPUT chain, I didnt get flooded by the logs. Each input produces 2 lines of data at every INPUT. But I can assure you that the WEB Browser cache takes up much more space, much faster....

There are rules to limit the firewall log to so many per minute. Much has to do with what the useage of the log is for. If I did not log ALL of the INPUT I would not have been able to determine the last 3 IP address before I got DOS(ed). If I didnt do that I would not have any idea as to which IP # could be responsible for the Denial of Service Attack.

There are many variables as to the useage and reason for a firewall log. 1st as I suggested when you first log on to the net, check the log as I have and I saw who was trying to connect to my machine on which port, for which there was no reason, other than a possible compromise.

2nd if your machine is using mega CPU cycles, when it ought not, check the log for the IP that is connecting and the port on your machine they are trying or another cause could be a scan of all your ports 0-65535. If the IP # is always the same you can make a rule to that ip address, and block it.

So there are many reasons and uses. I dont always use logging -live CD and no HD. But I am glad I did log all the INPUTS and from the logs I learned who was DOSing.

So this is about how to get the logging started if you want or need to and how to understand the results. But what you are suggesting is a point made in the orginal post.

Say if you only log the rejected connections, that would not help to determine who was hacking you only who tried to.

Many firewall rule scripts limited the amount of logging they do, but if I were to have done that I would not have gotten the answer I was looking for.

This mini-how-to is just a start, for those interested. Since I have started using Puppy, much of my interest has been with Networking Security and Iptables. Iptables can be a very powerful firewall and some servers have upwards of 255 rules, whereas puppy, through the wizard by default creates less than 12 rules. My system varies between 30-122 rules depending.....as I am still and probably always will be in the testing stage.

If you are going to either limit or flush the logs then you probably ought not bother in the first place, whats the point?

Cheers,.

User avatar
craftybytes
Posts: 298
Joined: Fri 17 Nov 2006, 10:32
Location: QLD AUSTRALIA

RE: Firewall Logging -How to

#5 Post by craftybytes »

Didn't mean to knock the points you outlined in your mini-how-to - just to add that as some puppy users have limited ram available that they should be aware that such logs can grow quite big ..

Yes, I agree that it is wise to set up your firewall logging as you suggest if you need to investigate any DOS attacks etc but then, as you have done, re-configure your firewall to block such attacks and set your logging to 'lower' levels ..

Your mini-how-to is very informative and usefull ..
3 x boot:- ASROCK VIA 'all-in-one' m/b; AMD Duron 1.8Ghz+; 1.0GB RAM; 20GB hdd (WinXP Pro); 80GB hdd (MEPIS 3.4-3/Puppy v2.15CE Frugal); 1GB USB pendrive (Puppy 2.15CE Frugal); CD/DVDRW; 17" LCD monitor; HSF 56k modem... MEPIS is great.. Puppy ROCKS..

Mic67

#6 Post by Mic67 »

The point of the space that the FW logs take if using a ram based Puppy is a valid point, abeit from surfing much more is stored than any FW log would. The thing with puppy is that there are many different possible configs. and many trade-offs given how you choose to use the OS. So how many use a ram base OS with no HD? My guess, most dont? Too bad as that is one of the best features of this OS making it the most secure OS there is, that I know of. And when I say no HD I mean no HD connected the the 40 pin ribbon cable AT ALL, and not just there but unmounted.

My opinon is that the best use of Puppy is ram only no HD at all - which seems to be the design characteristic of the base OS. This is the most secure - every boot a fresh OS.

If used in this manner the amount of FW logs are gone at shutdown, unless choosen otherwise. The 2 most basic and important apps. are the CPU load monitor and ram levels. The first things you always ought to glance at.

Like I said this how to is basic and like with every computer and OS -there is always a learning process, but it helps to have a starting point.

"If every thing was logical then logically we ought to have the answer to everthing." Why isnt everything logical?

Mic67

#7 Post by Mic67 »

Humm...if you like a neat way to conviently view the logs in real time there is universal way to do it.

In RXVT type
tail -f /var/log/messages

please note there is a space between tail(space)-f(space)/var/log/messages

press enter

This will show every new entry to the firewall log
provided that this is where the FW sends its logs to as it does in Puppy (versions 2.10 and 2.12 for sure).

Now it will only scrolls back so far and will always jump to the bottom of the screen as the most recent log entry > autoscroll.

The data limit retained in standard mode is not very much I think so it sort of flushes out it self. Now depending on your surfing and what you have choosen to log this data could be moving rather fast.

But if you use a text editor and manually open the "messages" file the complete history of the firewall logs will still be there.

The advantange of using the method in the RXVT window is that it is a live and constantly updating of what you choose to log via the firewall or any other log or file for that matter, provided that you correctly point to it.

This command ought to work for many different things and reasons. The FW logs is a good one.

I didnt want to have any of the logs flushed until I reviewed them. But I have used this method described as above for real time monitoring of the firewall.

Also it is possible to determine what the firewall is doing:
In RXVT type
iptables -L -n -v --line-numbers

And it will show you, as an example "rule de jour" number 10 in my INPUT chain which will look like this:

10 33 49500 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW

There is a legend in a line right after the firewall category that has colums that will show you the defination of each colum.

In the above example:
-10 is the rule number in my INPUT chain (category)
-33 is the total number of packets dropped
-49500 bytes (total dropped from accessing my system)
-DROP is what the action of the rule is suppose to do
-tcp is the protocol of the rule
-the first * represents from anywhere to the IN
-the second * represent to anywhere on the OUT
-0.0.0.0/0 represents the generic source and output destination
-tcp flags:!0x17/0x02 state NEW >represents the firewall interpertation of what the rule actual is, althought this is not how the rule would actually be written.

As that rule would actually be written as:

iptables -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

Now if you were to use this rule to add to your firewall the -A in the rule means that it will append it to the INPUT chain, which means it will go to the bottom of the existing list. And I doubt that it would be effective there as a rule before it may actually accept it. So if you like to try this rule I would change the -A to -I. This change would insert the rule at the top of your existing INPUT chain rule set. Seems to be a good rule. The beauty of puppy is by using it as a LIVE CD where you can change anything and if it creates issues just reboot and you start fresh again.

Written as:

iptables -I INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

Spaces and capitals are important as in Linux they mean 2 different things.

Also the thing about iptables is that what the order of the rules are is very important and makes a difference between what gets filtered and what doesnt. So that if a rule is not in the right order, you will either block your own access to the network or cause the rule to be ineffective. Although once you get the jest of it, it does make sense. And say you added a rule and it blocked your network access, just>
In RXVT type

iptables -L -n -v --line-numbers

and see, by the increase in bytes that is being DROPPED (most likely and INPUT rule) when you try and access the net, it is likely that is the rule that is causing the blocking of the access.

Corrections and comments alway welcomed with a smile;V))

Cheers.

Post Reply