Printable View
We are about to have someone do some external pen testing. i know its this week but my boss wants me to monitor activity on the firewall and syslogs and such. he wants me to discover the activity and come to him with it. I am obvioulsy still in traning on this stuff and would really appreciate anyones advice on what i should be looking for and where i can find this info? where are sys logs typicaly located?
Control Panel-> Administrative Services - > Event Viewer. If you mean those,Quote:
where are sys logs typicaly located?
the firewall logs can be usualy found in the firewall folder, and the firewall action history can also be usualy viewd from the firewall itself !
What kind of firewalls are you using?
I really only would call myself really proficient with the PIX. But it's not that hard to do.
Rather than type out the instructions, you can look it up here.
As far as what you should be looking for...look for ip/port/ping scans coming in from the outside. Honestly, if you know what addresses you have that should be talking, and what direction they should be talking, you should identify it pretty easily.
Common ports that people will try to exploit include (but are not limited to) 21, 22, 23, 25, 80, 110, 135, 136, 137 ,138, 139, 443, and 445,. I also see traffic directed at 5190 (AIM port) and 8080 (commonly used by a bunch of stuff). Another trick they might use is sourcing their port from a diffrent service. So if you see say....an rlogin connection attempted on the smtp port, something is amiss.
Thank you guys. it is a pix.
I know where event view is and how to view those logs i guess i just dont knwo what i am looking at. but mor eon the lines of the firewall i dotn knwo what to lopok for and dont knwo where the sys logs get stored so i can look at them. I access the firewall through a GUI via HTTPS and the IP.
What firewall do you use Jason? We can probably give you a more specific answer if we know which one you're using.
/edit -- PIX, not familiar with that one, but ThreadKiller has the right advice. Watch for those log events he described in the PIX's log. Also, make sure you're blocking all incoming traffic from the outside, except for trusted sources, of course.
You won't find much network security related in the event log (correct me if I'm wrong guys) because it pertains to logging errors within the computer, but you do need to make sure security auditing is active. That will log failed password attempts and other important events.
Actually AngelicKnight you can log every single packet that passes through the pix. I export mine to a slackware 8.0 box where cron jobs run scripts against those logs and migrate it off-box to a machine in my office. Then more scripts parse that info against the Snort logs for interesting traffic. If something really weird is in there, I get an E-mail.
Knowing what you're looking for though, that is the trick of it.
i think you should e listening for conections in uncommon hours.....tcp conections to ports that aren't used by your compani....the load of the network...versus THE RAL LOAD OF THE NETWORK(what services are been used...stuff like that...)also unsuccesesfull logins...form inside the fariweall as from outside.....if you need specific help....em mail me.....faith_in_death ARROBA hotmail DOT com
we have webtrands but i dont know how it works
Do you mean Webtrends Firewall Suite? If so, it's good for preparing reports on your firewall activity, but that is after the fact. You need something more 'real time'. Do you have any intrusion detection systems installed (e.g. snort)?
Cheers:
if i where you...i'll isntall some sniffer on the ipnputs....etherals is just great...but if you don't configure it well...you'll get tons of garbage.....also..check treh proxy for options to monitoring....
FID: If it were me "attacking" someone, I wouldn't necessarily do it off hours. I like to do it during peak traffic (1st hr of work, lunch, last hr of work). It's easier to hide in a crowd.
Ah, you're right but most of the time even easier to do it in evenings and weekends while the system admins are at home asleep and not watching their logs!Quote:
Originally posted here by jonathans_daddy
FID: If it were me "attacking" someone, I wouldn't necessarily do it off hours. I like to do it during peak traffic (1st hr of work, lunch, last hr of work). It's easier to hide in a crowd.
Take it from someone who has performed pen tests...watch your stuff from 9pm to 4am.
Also, I would have some cron (or Win scheduler) job that is dumping the event logs out of the system and onto a more secure/protected system every hour...or maybe every 15-30 mins. That way, when the pen tester is successfull and covers their tracks you will have some logs to review.
Good luck and make sure you have tons of disk space for all the logs and sniffed traffic.
i reccomend setting up a full blown network sniffer that sniffs everything. etheral is great. Then after the attac‚‹ you can sift through the packets.
Yes firewall suite. I know very little about it...can you tell me some basics on how i can use it? at the moment it seems to crash when trying to run reports...Quote:
Originally posted here by faith_in_death
if i where you...i'll isntall some sniffer on the ipnputs....etherals is just great...but if you don't configure it well...you'll get tons of garbage.....also..check treh proxy for options to monitoring....
we are working on getting IDS but dont have it implimented as of yet. we cannot use anything free as a finacial institution...(i dont get that).
We are no doing syslogging that i know of i am setting up a server today with Kiwi. any thing i need to look for or worry about when setting it up?
All Firewall suite will do for you is analyze your firewall logs and produce 'pretty' reports for management to look at. Again, this will only report on what 'has happened', not what is happening.Quote:
Originally posted here by Jason1977
Yes firewall suite. I know very little about it...can you tell me some basics on how i can use it? at the moment it seems to crash when trying to run reports...
I read into this, that he (your boss) wants you to tell him that the pen testing is going on and you caught it (again real time). Correct me if I am wrong on this.Quote:
he wants me to discover the activity and come to him with it
Without a reliable IDS in place, I believe the only resources you have to turn to are your 'real-time' firewall logs (If you have those), your syslogs & event logs. Given this you are going to have to watch VERY closely. Look at what's currently going on and use that as your baseline. Armed with this information, then look at what appears to be out of the norm for your environment (see previous suggestions on ports & protocols to watch).
Not sure I can give you much more advice, an IDS would definitely make this a lot easier. ;)
Good Luck.
I may have not presented the info correclty. what he wants is for me to catch it but not nessisarily when it happens. just that i saw it after the fact is fine with him for now. we are getting IDS 4th quarter this year. but for now i am to be analyzing the logs on a daily basis. I dont under stand a thing when i look at all those pretty graphs in webtrends lol and i dont know that it is even workingQuote:
Originally posted here by DjM
All Firewall suite will do for you is analyze your firewall logs and produce 'pretty' reports for management to look at. Again, this will only report on what 'has happened', not what is happening.
I read into this, that he (your boss) wants you to tell him that the pen testing is going on and you caught it (again real time). Correct me if I am wrong on this.
Without a reliable IDS in place, I believe the only resources you have to turn to are your 'real-time' firewall logs (If you have those), your syslogs & event logs. Given this you are going to have to watch VERY closely. Look at what's currently going on and use that as your baseline. Armed with this information, then look at what appears to be out of the norm for your environment (see previous suggestions on ports & protocols to watch).
Not sure I can give you much more advice, an IDS would definitely make this a lot easier. ;)
Good Luck.
Ok...let's go back to basics
Can you see your firewall logs? Not pretty graphs...raw data?
Assuming you can, you know what your internal network adresses are right? 10.x.x.x, 172.16.x.x, or 192.168.x.x most likely. Anything else is going to be from outside your network.
So in the Pix logs there will be source and destination addresses if you're logging everything. The source address will be indicated by s=x.x.x.x and the destination will be indicated by d= x.x.x.x. Look for addresses that come from a source address outside your network with a destination address inside your network. Now....not everything that is sourced/destined that way will be an attack. When your user sends a web request to google, there will be an entry from that machine to google. Then there will be an entry from google to that machine. I'm simplifing some, but it's to demonstrate a two-way communiciation process.
Look for addresses sourced from outside your network that do not have an initial request coming from inside your network (as in the google example above). Also, if someone is brute force pen testing they're not likely to be sneaky. So you will probably see thousands of packets from one --maybe a few-- outside adressess trying to get to every machine in your network. There will be all sorts of destination ports (also in the pix logs) as they try different ways to get in. See my previous post in this thread for what ports should raise alarm bells.
That should get you started.
OK, let me check my Webtrends to see if there is anything there that might help you (I don't use it to report on inbound activity much) There is one report I run that reports on all traffic (inbound) that triggered a firewall rule. This may be a little help to you, look under the "General Firewall Activity" tab. Create a report in there and look under the "Content" tab, there should be something in there about "Triggering Firewall rules" (or something like that).Quote:
Originally posted here by Jason1977
I may have not presented the info correclty. what he wants is for me to catch it but not nessisarily when it happens. just that i saw it after the fact is fine with him for now. we are getting IDS 4th quarter this year. but for now i am to be analyzing the logs on a daily basis. I dont under stand a thing when i look at all those pretty graphs in webtrends lol and i dont know that it is even working
I'll get back to you if I find anything else.
Cheers:
ok, i have some raw data now since i started a syslog server.
here is snipit of data frmo my log. if you can tell me some what how to understand it? I get the concept of the incoming and outgoing 2 way communication. what about when it says deny? why is that? what are the "local warning"s
Time Priority Hostname Message
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:39: %PIX-5-111008: User 'enable_15' executed the 'logging host inside 172.16.8.101' command.
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:39: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...network_on.gif
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2975 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src outside:139.131.205.19/80 dst inside:208.243.37.132/58900 by access-group "inbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src outside:139.131.205.19/80 dst inside:208.243.37.132/58902 by access-group "inbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src outside:139.131.205.19/80 dst inside:208.243.37.132/58897 by access-group "inbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src outside:139.131.205.19/80 dst inside:208.243.37.132/58896 by access-group "inbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2974 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:40: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2976 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:41: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2976 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...op_nursery.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...top_ffotos.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...s/top_shop.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...op_network.gif
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:41: %PIX-4-106023: Deny tcp src outside:63.236.98.43/80 dst inside:208.243.37.132/58623 by access-group "inbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...s/top_cust.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:41: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_assets/images/nexp2.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-111001: Begin configuration: 172.16.1.252 writing to memory
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2976 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...ges/nnewp2.gif
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2977 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...s/top_home.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...ges/nbaby2.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...es/nchild2.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse.../norderff2.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...s/nshopgg2.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_assets/images/nexp.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_assets/images/nnewp.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_assets/images/nbaby.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.16.11.77 Accessed URL 198.65.101.249:http://www.hardrockhotel.com/
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.16.11.77 Accessed URL 198.65.101.249:http://www.hardrockhotel.com/home.php
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...n_am_bover.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse..._pbb_bover.gif
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2977 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...n_bh_bover.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...es/wn_vb_b.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...es/wn_am_b.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/gf_asse...es/wn_bh_b.gif
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/images/...4V5V5C7G_5.jpg
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src outside:139.131.205.19/80 dst inside:208.243.37.132/58878 by access-group "inbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.12.28 Accessed URL 216.239.39.147:http://www.google.com/search?hl=en&l...rk&btnG=Search
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/images/...4V5V5C7G_6.jpg
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2977 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Warning 172.16.1.1 Aug 04 2004 13:18:45: %PIX-4-106023: Deny tcp src inside:172.16.9.6/2978 dst outside:67.19.52.212/8080 by access-group "outbound"
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/images/...4V5V5C7G_3.jpg
Local4.Notice 172.16.1.1 Aug 04 2004 13:18:45: %PIX-5-304001: 172.18.32.54 Accessed URL 63.73.227.39:http://www.growingfamily.com/images/...4V5V5C7G_4.jpg
DJM, does Firewall suite give that kind of raw data? i dont see a syslog server in firewall suit? do you?
Ok....first, sorry I was wrong about the s= and d=. I'm a little addled today and was thinking about router ACL's rather than PIX syslog's when I wrote that.
In a nutshell though what you have there is allowed traffic to the URL that is listed (growing family dot com) and denied traffic (via your Outbound group lists) to mugglenet. I looked it up, it's a Harry Potter Fan site. the /8080 you see is the destination port.
The only thing interesting there is the denied inbound traffic from the 139.x.x.x address by your Inbound list. A quick http:// request to that address timed out on me twice. You might want to look that one up.
What I don't see are massive ping sweeps, snmp walks, ssh attempts, etc that would indicate a full-blown attack is underway. So with what you have there, just find out what that 139 address is.
Glad you got the syslogger working.
edit: Forgot to explain this: The 'warnings' and 'notices' are simply a level of logging that you have turned on. There are eight logging levels, debug through emergency. Warning is 4, noticification is 5. The local part is a name for that logging facility. So all your info is going to start with someithing like local4 warning. It's just telling you the facility and the logging level.
Jason1977 I had this among the long list of my bookmarks it was written in 2001 I thought it would give you a head start on Ids's.
FAQ: Network Intrusion Detection Systems
I thought the more you read about it the easier it will be on you and other people when the Ids is implemented.Quote:
This FAQ answers simple questions related to detecting intruders who attack systems through the network, especially how such intrusions can be detected
http://www.robertgraham.com/pubs/net...detection.html
Jasom,
One of the best ways to prepare yourself is to run nessus or something similar against the network you are monitoring. Then you go through all of the available data that your existing systems capture and identify the reported activity associated with your own run. If you can't detect the actitivity, then you need to either identify or enable additional logging. Just make sure that you either have the authority, or specific permission to do this. You could ask your boss for an OK, he should at least appreciate your approach. And of course, make sure your making a run from OUTSIDE your network. ;)
Also, if you know, or if you can find out what tools the people performing the test will be using.... well you might be able to put yourself into pretty good shape. ;) If you know the company just check thier website, they may list the spcific tools and methodologies that they use when performing this service.
Good Luck!