# Grab yesterdays log file, give it a useful name, and change to the working directory.


cp /var/log/messages.1 /root/logcheck/full_firewall.log

cd /root/logcheck


# Resets are an indication of port scans or communication errors

# which make them "interesting". Dump them all in the same file

# so that scans across multiple IP's can be tracked. Don't 

# remove them from the log yet as we want to see them associated

# with each host as well. 


grep ' R ' firewall.log > resets.txt


# The first traffic pattern I noticed in this log was Web server

# traffic so I first dump it to its own file and then removed it 

# from the working log file. Note the [: ] which tells grep to

# match on the character string when it ends with a colon or a 

# space character (match '12.33.246.2.80:' or '12.33.247.2.80 ').

# I could not match on just 12.33.247.2.80, because the log also

# contains traffic to 12.33.247.2.8080, thus I need to ensure I

# included the space or colon on the end of the string.


grep '12.33.247.2.80[: ]' firewall.log > web_server1.txt

grep -v '12.33.247.2.80[: ]' firewall.log > trace1.txt


# Next pattern I found was DNS so I parse that out. Notice I

# broke up DNS based on transport. This is because TCP DNS is a

# little more interesting as it could be zone transfer attempts or

# queries that had large answers. Also note I did not tile this to

# a single server. All DNS goes into the same file. If you want a 

# per server breakdown, use a format similar to the Web server 

# example above.


grep udp trace1.txt | grep '\.53[: ]' > dns_udp.txt

grep tcp trace1.txt | grep '\.53[: ]' > dns_tcp.txt

grep -v '\.53[: ]' trace1.txt > trace2.txt


# Next pattern found is TCP/4040. Per the Neohapsis services file, 

# this is CIPHERim traffic so parse that out. 


grep '12.33.247.2.4040' trace2.txt > CIPHERim_server.txt

grep -v '12.33.247.2.4040' trace2.txt > trace3.txt


# Next pattern found was SMTP. I decided to look only at the initial

# SYN packet going to the server rather than all traffic. I also 

# decided to not limit the target IP as being our server. This will

# permit me to put all SMTP traffic in one file. The only thing bad 

# about parsing the data this way is that people probing TCP/25 on

# on non-SMTP servers will get mixed into this file. This will make 

# it harder to ID those port scans. If this was a true firewall log 

# you could fix that problem by doing a secondary grep on "drop"

# or what ever keyword your firewall uses to say someone hit port 25

# on an IP that is not permitted to communicate on that port.


grep '\.25: ' trace3.txt | grep ' S ' > smtp.txt

grep -v '\.25:[: ]' trace3.txt > trace4.txt


# Next pattern found was traffic to our proxy server. We've decided to

# save packets in all directions but to limit the save to only traffic

# to and from the legitimate proxy. This way probes to other IP's on 

# this port number don't get parsed out so we can catch them further down.


grep '12.33.247.2.8080' trace4.txt > proxy.txt

grep -v '12.33.247.2.8080' trace4.txt > trace5.txt


# Next pattern is inbound SSH to our SSH server. Save these off.


grep '12.33.247.11.22' trace5.txt > ssh_server1.txt

grep -v '12.33.247.11.22' trace5.txt > trace6.txt


# Looks like we have another SSH server accessible from the Internet.


grep '12.33.247.10.22' trace6.txt > ssh_server2.txt

grep -v '12.33.247.10.22' trace6.txt > trace7.txt


# We also have SSH between internal systems as well. Let's put

# that in its own file.


grep '\.22[: ]' trace7.txt > internal_ssh.txt

grep -v '\.22[: ]' trace7.txt > trace8.txt


# Looks like we have a second Web server. Save this data off in a similar 

# fashion to the last one except we don't have proxy traffic to worry about.


grep '12.33.247.4.80' trace8.txt > web_server2.txt

grep -v '12.33.247.4.80' trace8.txt > trace9.txt


# Next pattern is RIP routng updates. Note RIP uses a source and destination

# port of 123 UDP/520 so we don't need to match multiple patterns


grep '\.520: ' trace9.txt > rip_routing.txt

grep -v '\.520: ' trace9.txt > trace10.txt


# Looks like NTP traffic to sync time is used as well. Let's save this

# to its own file.


grep '\.123: ' trace10.txt > ntp.txt

grep -v '\.123: ' trace10.txt > trace11.txt


# Also found SSL traffic. Let's dump that to a file. If we know only

# one system should be using SSL we can tie it to a single IP address.


grep '12.33.247.8.443' trace11.txt > ssl.txt

grep -v '12.33.247.8.443' trace11.txt > trace12.txt


# Also found Big Brother used for system monitoring. Let's put that in

# it's own file.


grep '12.33.247.4.1984' trace12.txt > big-brother.txt

grep -v '12.33.247.4.1984' trace12.txt > trace13.txt


# Looks like we have another type of proxy on the wire as well. Let's 

# put that into its own file.


grep '\.3307[: ]' trace13.txt > op-session-proxy.txt

grep -v '\.3307[: ]' trace13.txt > trace14.txt


# Looks like yet another Web server. Save this one off as well.


grep '12.33.247.10.80' trace14.txt > web_server3.txt

grep -v '12.33.247.10.80' trace14.txt > trace15.txt


# ICMP unreachables are interesting as it indicates someone is trying to

# get to something they should not or the resource is gone. Let's put

# them into their own file so they are easier to review. With this log

# file we can just look for "unreachable" but for your firewall you may 

# need to grep for "icmp" and then pipe it though another grep that flags

# type 3 and 11 packets only. Don't want to mix in echo-requests or any 

# other type of ICMP packets.


grep unreachable trace15.txt > icmp-unreachables.txt

grep -v unreachable trace15.txt > trace16.txt


# Found some RADIUS traffic to parse out.


grep '12.33.247.11.1812' trace16.txt > radius.txt

grep -v '12.33.247.11.1812' trace16.txt > trace17.txt


# Let's say at this point we think we are done. Remember back on the first

# line we extracted all the reset packets? Well before we create our file

# with unexpected traffic patterns we need to clean these resets out of the 

# working file.


grep -v ' R ' trace17.txt > trace18.txt


# Now we just rename the last working file as it will contain all the stuff

# we did not expect to see.


mv trace18.txt interesting_stuff.txt


# If you are writing a new script, do not add in the next line till you 

# know it works properly as it will make troubleshooting what is broken

# a real pain. Our final line cleans up all those temporary work files

# that get left behind.


rm -f trace*.txt