Ports getting hammered?

I no very little about firewalls. My setup:

Cable access

I recently installed ZoneAlarm and it is blocking attempts at port access.

I thought that having a physical firewall, like the SMC, stopped that at the router?

Of course manually opened ports are going to be probed. Are those the ports in question? Does the router have logging what model SMC router is this?

Duane :)

These were pings from WAN. Both computers are behind the SMC.

I did have "Virtual Server" settings, in the SMC Firewall, with service ports 6881-6991 "enabled". I just unchecked/disabled them. I think I had them that way a long time ago for online gaming.

Would that make a difference?

No log for the SMC Barricade 4port router.

ZA has a log file but they are not the ports I had open on the router; I don't think.

I know next to nothing about this. Just wondering if I should be concerned. Thanks

If you have closed the ports and ZA is not responding, then your problems are solved. If the router doesn't have SPI, then probes can come past the NAT router and I have had that happen on a Linksys I owned that didn't have SPI, which BlackIce I was using at the time blocked the probes.

Duane :)

Thanks for all the help Duane! :)

Something on your machine is attempting to connect out over the port most commonly used for IMAP, a mail protocol.

Probably some spyware calling home.

Your ZA is blocking it, but it's there, and operating.

It may be successfully connecting out on other ports.

Your SMC is likely not configured to block any outbound connections.

-Russ.

How is that possible? The log clearly indicates unsolicited inbound packets are being dropped. Please explain to me how any PFW or any FW solution knows that dubious outbound traffic is be sent from a machine and the it's going to make some decision to start blocking outbound, because something is phoning home? If the malware running on the machine solicited the traffic from the remote IP, the PFW is not stopping anything.

Duane :)

Hey, you'll have to forgive my writting as I have not had my first cup of java.

Duane :)

Are you sure that you read that right? It looks to me like an inbound request, not outbound.

Looks like it is not configured to block inbound UDP either. Even the old Linksys BEF series from 6 or 7 years ago blocked UDP by default. The SMC is either poorly configured or it is a real bottom of the food chain model if it allows unsolicited UDP traffic to pass through.

SHRED wrote on Mon, 02 Jan 2006 09:33:57 -0800:

Are you sure you didn't run BitTorrent for a while? If so, that's the likely reason - your current IP is being listed somewhere in a BT tracker, and those connection attempts you're seeing are other BT clients trying to connect to your IP to download files that were being shared. If you didn't run BT, then you managed to pick a port range that includes ports common to BT clients, and your public IP has changed to one that was recently used by someone running BT to share files.

Dan

Yes I have, in the past.

Ok, first of all my apologies for reading that log very badly. I read it as outbound 143 for some reason when it's clearly inbound UDP 1689. I'll mumble something about coffee now...

UDP 1689 could be anything, a custom peice of malware, whatever. Officially it belongs to

Why inbound UDP is being seen by ZA as routed to his private IP and not dropped at the firewall, points to either broken sessions being used to send traffic back in, or a forward/DMZ rule of some sort on the firewall. It could also be the result of something calling home and fessing up the local private IP to the remote side, but I'm not sure how that ends up as the destination IP after the traffic returns.

Now, to your particular question about outbound traffic, some PFWs and all good hardware firewalls are capable of blocking outbound traffic using one or more of the following methods, even when the local machine is either initiating or soliciting the traffic:

1. it's not on the list of allowed outbound ports/protocols
2. it's on the list of blocked outbound ports/protocols
3. it's not on the list of allowed destinations
4. it's on the list of blocked destinations
5. it contains traffic that can be identified as problematic based on signature (deep inspection)
6. the behaviour of the traffic can be identified as nefarious (metrics, threholds, or profiling)
7. combinations of the above methods

All of these methods relate to the arresting of the "phoning home" behavior you're referring to, and form an important part of a fully implemented security strategy in my opinion. Ignoring or accepting all outbound session traffic as valid is simply bad security and easily leads to serious and complete compromise scenarios.

-Russ.

Not to be smart here but my Watchguard is not just going to start blocking outbound from some machine that it has determined that outbound traffic is dubious in some nature - automatically. Maybe some of the higher end models can do it but I don't have one of those. The only PFW solution that I know about that will stop outbound on its own based on some kind of traffic analysis of protocols being broken is Blackice in conjunction with using IPsec running on the machine. That traffic that was being blocked outbound just happened to be the query by the XP O/S to the MS site for time sync that the XP O/S was having trouble at the time, which I told BI to accept the traffic and forget about it.

I am aware of ZA and have used it. And I know that ZA is not stopping outbound on its own unless some rules are being set to stop it. It's not just going to start blocking outbound on its own and many of them cannot do it.

Duane :)

Well to be honest I'm not fully up on most software firewalls as I don't believe in them as a genre. I run one sometimes to support clients that in fact does inspect traffic for nefarious content and can utilize most of the techniques I noticed including recognizing signatures of outbound traffic. It's the FortiClient which is the FortiGate's IPSec client. That's what my comments were based on.

If your Watchguard can't stop outbound traffic... is it really useful? Would not the Windows XP firewall do exactly the same work?

As far as the appliance-based approach, the FortiGate firewall line in fact uses all the methods I mentioned and more to stop outbound traffic, no matter who solicits or initiates it, and it can't be compromised by the malware itself. Which is what makes that approach superior to a software based firewall approach.

-Russ.

My WG can stop inbound or outbound by setting rules by port, protocol and IP WAN or LAN IP(s). What it can't do is start doing some kind of protocol analysis to see if protocols are being broken only a IDS application in system can do that. Now if the FW solution host based or otherwise has an IDS element to it, then more power to it.

I am not going to be depending upon any solution appliance, host based or otherwise to be making some kind of decision as to when it's going to stop inbound or outbound based on some algorithm it maybe using on its own that has been predetermined by some programmer. BTW I am a programmer that's what I do for a living is write programs. If I set rules for a FW host based, appliance or otherwise to do something to filter packets inbound or outbound, then it had better well do it.

I am the one who is the determining factor by reviewing logs for traffic patterns, what's dubious or not dubious in nature and where traffic is being sent to or coming from.

The buck stops with me and not some program in the determination as to what is happening.. I may use tools to help me make that determination. But the buck stops with me and no where else.

Duane :) .

My PFW has an IPS built in, supporting around 1300 attacks. So, it can recognize and stop nefarious traffic that is going over allowed ports, protocols and IPs.

On the appliance, the entire set of attacks can be fully customized, one by one. They can be enabled or disabled, they can be set to drop the bad packets, kill the session, or send a reset to one or both ends. Smart people review their logs and the default configurations to decide what they want to let through and what they don't. Some data types are exempted from scanning, some are not. Some are subjected to deeper or different scans than others.

You are taking the position that you don't want to see or know about these things, becuase your tools cannot inspect the data going over the permitted ports and protocols. All your programming skill in the world will not save you from in-band attacks when zero-day exploits hit the wire for products you use. Until the vendors release patches, you're open. In the other direction, nefarious software installed by nefarious means or rouge users on your machines are free to communicate out over common ports such as 80 without impediment, in plain view of your logs.

I trust people that do this for a living to help me with such things while the software vendors tell us that the vulnerability is theoretical only. I gain visibility into the data streams and types going through my firewalls, be they common ports or not.

I temper that with a dose of reality and the ability to read the logs and modify the configuration as need be, based on what really is and is not allowed over the wire by the firewall rules and the data types traversing them.

-Russ.

Look, I am a home user with some professional expertise. I know how to protect my setup. And I'll dare say that I would know what to do protect a small business too and do it well.

For the moment, my machine is setting behind BlackIce and IPsec on the machine while on the road. And while at home, the machines are setting behind that WG. I have learned a lot from the Top Guns in the NG and in a couple other NG(s) on how to protect my setup along with other things I have learned on my own, like going to the O/S where I should go and configure the O/S and solutions such as IIS for better protection. I got it covered and I know how to look.

A rouge user is never going to get on my machines. I know how to go look for such things, if it ever does happen and I do look from time to time with the proper tools, I'll take care of it. The FW appliance knows the difference between FTP coming down port 80 as opposed to HTTP coming down port 80 so it is protocol aware. And so is BlackIce along with IPsec that's implemented on this laptop I am using.

I learned long ago not to trust anything or anyone and Human Beings are fallible to say the least about it.

OK, if that's what you do that's what you do.

I know what I am doing and I can take care of myself --- count on it. :)

Duane :)