56k dial up on laptop 802.11G ?

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

Why not?

This is the definition as to what I condider a FW. I don't like to type so I find what I need to find and I cut and paste.

A firewall protects networked computers from intentional hostile intrusion that could compromise confidentiality or result in data corruption or denial of service. It may be a hardware device or a software program running on a secure host computer. In either case, it must have at least two network interfaces, one for the network it is intended to protect, and one for the network it is exposed to. A firewall sits at the junction point or gateway between the two networks, usually a private network and a public network such as the Internet. The earliest firewalls were simply routers. The term firewall comes from the fact that by segmenting a network into different physical subnetworks, they limited the damage that could spread from one subnet to another just like firedoors or firewalls.

Both solutions can use a packet filter so in someway they do set similar types of rules and make similar types of decisions based on the rules implemented.

And I agree to disagree here about NAT. NAT is not FW software.

By comparing the way NAT functions between two networks, and the way packet screening methods function between two networks, you can see that NAT does not adhere to the firewall definition. NAT does not control access between the networks. Some may argue that NAT does control access because you cannot "see" the internal network. NAT does this not by using rules or filters, however, but through concealment. It hides the network from outside users.

This is where I think a packet filtering solution or packet filtering NAT router falls short. And again I don't like to type.

Packet filtering firewalls allow a direct connection to be made between the two endpoints. Although this type of packet screening is configured to allow or deny traffic between two networks, the client/server model is never broken.

Packet filtering firewalls are fast and typically have no impact on network performance, but it's usually an all-or-nothing approach. If ports are open, they are open to all traffic passing through that port, which in effect leaves a security hole in your network.

Defining rules and filters on a packet filtering firewall can be a complex task. The network administrator must have a good understanding of services and protocols to be able to translate the organization's security requirements and needs into an accurate list of allow and deny rules or filters. In some cases, the task of configuring rules or filters may become so complicated that implementation is impossible. Lengthy access rules or filters can have a negative impact on network performance and be prone to error. As the number of rules or filters increases, so does the amount of time it takes the firewall to make comparison decisions and the chance that an inaccurate rule or filter will be added.

The accuracy of rules or filters on packet filtering firewalls can be very difficult to test. Even if the rules and filters seem simple and straightforward, verifying the correctness of a rule through testing can be a time-consuming process. Sometimes testing results can be misleading and inaccurate.

Packet filtering firewalls are prone to certain types of attacks. Since packet inspection goes no deeper than the packet header information, this method of packet screening is easier to circumvent and cannot protect against attacks directed at the application level. There are three common exploits to which packet filtering firewalls are susceptible. These are IP spoofing, buffer overruns, and ICMP tunneling. IP spoofing is sending your data and faking a source address that the firewall will trust. Buffer overruns typically occur when data sizes inside a buffer exceed what was allotted. ICMP tunneling allows a hacker to insert data into a legitimate ICMP packet.

Packet filtering firewalls do not perform user authentication. Again, this method of packet screening looks at information contained in the packet header and bases decisions on that information alone.

And I consider the FW appliance to out class the packet filtering NAT router with SPI, because the FW appliance's architecture resembles the packet filtering router and dual-homed Gateway architectures and is able to look at a deeper level along with other things like actually breaking the client/server model between two end points, providing services etc.

However, I got nothing against NAT routers. They are a good first line of defense, until you start doing high risk things like port forwarding.

There is something to be said about book and practical knowledge I use them both and I have been doing so since 1971 when I first entered the computer industry.

BTW, Linux is not the greatest thing since *Air, Water and Fire*. ;-)

Duane :)

Well, that depends on whether you subscribe to my definition of a firewall. The way I understand the moving target definition, a firewall is literally anything that defends your network against external attack. It could be a guard dog that's trained to sniff hostile packets and bark when they appear. Whatever works.

Agreed, by your definition that's correct. However, I don't subscribe to your definition of a firewall, which describes how a firewall operates, without recognizing what a firewall does. It's a rather fine distinction and subject to considerable creativity in interpretation. However, I don't see any reason you couldn't be more specific in the type of firewall by adding the appropriate qualifier. NAT firewall SPI firewall packet filter firewall bastion host firewall dual bastion host with DMZ firewall proxy server firewall barking guard dog sniffer firewall Depending upon whom you ask, all or some of these are considered "true" firewalls.

That's what I was going to say. If you can't "see", "access", or "hack" my LAN, it must have some kind of firewall protecting it. How it does the job is irrelevant. It's still a firewall.

Actually, there's another problem. If an NAT firewall is not a real firewall, what is it? To the best of my knowledge, there's no trade name or function definition for NAT other than "NAT firewall". Did I miss (or forget) one?

Incidentally, please cite the source if you're going to quote, borrow, plagiarize, or paraphrase. I've seen far too many partial quotes taken out of context.

Absolute baloney. There's nothing in a firewall that connects anything. It's the router function that provides the end to end connection. The firewall doesn't connect anything. There are purists that will proclaim that NAT is an abomination because it breaks the end to end connection definition required for "real" TCP/IP networking. I don't subscribe to this exception, but you won't have much trouble finding people that agree.

Right. Now, how does this differ *in* *FUNCTION* with an NAT firewall? As far as I can determine, they serve exactly the same purpose. Again, it really depends on whether you subscribe to my functional definition. Apparently you do not.

I'll happily discuss the relative merits of various firewall architectures if you want. However, that's not the current issue. It's whether an NAT firewall is considered a "real" firewall and whether the WRT54G is a "real" firewall. Floyd and I say they are and you say they're not.

There's other ways of breaking NAT firewalls. Spoofing source addresses that appear to be coming from inside the firewall are a good start. Automatic port forwarding, as in Universal Plug-n-Play is another fundamental security problem. Yeah, they're not the greatest but it doesn't take much to make them secure enough for home use.

Well, I did battle with my first computah in about 1965 with the IBM

1620. I then graduated to the 7090 and 1140. When IBM wouldn't hire me as a customer engineer, I switched to radio and didn't get back into computahs until about 1976 with various timeshare services. The first PC was an Apple ][, Apple III, TRS-80 (various models), Vic-20, assorted S100 kludges, and finally, in 1981, I bought the first IBM PC to be sold out the door at the Santa Clara Computerland. In 1983, I celebrated getting fired from a job by declaring myself a consultant simultaneously in RF and computers, which I've been doing through today. There were a bunch of diversions in there, but they have little to do with RF or computers.

What makes you think I'm a Linux fanatic? My forte is SCO Unix OpenServer 5, ODT 3.2v4.2, and Xenix. I are not a programmist. I'm doing Linux because it's a good fit for most of my customers, because I'm greedy and can get it free, and because SCO did some really politically incorrect things. If you dive into comp.unix.sco.misc, you'll find quite a bit of my postings. I didn't even bother with alternative firmware for the WRT54G until Floyd convinced me it was worth my time trying and learning.

There you go about where I got it from and are you a FW .

That's some pretty bold statements up above there. Below is where I got my information. Read it and tear it a part if you can. It's the same information I have gotten from the firewallers in the FW NG.

And I'll stick by my guns as to what it's talking about.

Duane :)

If the 54g can stop outbound by using iptables a packet filter and is using SPI, then it's a moot point. And it comes close to a FW appliance and meets the FW definition but is not a FW appliance.

I got to go.

Duane :)

No problem. I hate long postings, but methinks dumping the entire IPTables config might give you a clue of what's inside the box. This is from Sveasoft Alchemy. I think the stock Linksys firmware is similar. I've tweaked the format a bit to shorten the listing and deal with line wrap. I also deleted a few lines that might constitute a security problem for me. It's not Cisco IOS, but it's good enough for me.

The "chain OUTPUT" is what controls output blocking by port, service, or IP address. Something like: iptables -A OUTPUT -o portname -p tcp -dport 113 -j REJECT will block IDENT from being sent by a client machine. There's no blocked output ports in this example from my router.

If I want to block outgoing traffic from a specific machine: iptables -A FORWARD -p ALL -i portname -s 192.168.111.15 -j DROP

If I wanna block it by MAC address: iptables -A FORWARD -p ALL -i portname -m mac \\ --mac-source xx:xx:xx:xx:xx:xx -j DROP

If I want to block all port 25 traffic so that infected zombies don't spray spam garbage all over the internet: # allow outgoing SMTP traffic to one mail server: iptables -A FORWARD -p TCP -i devicename \\ -d xxx.xxx.xxx.xxx --dport 25 -j ACCEPT # block other outgoing SMTP traffic iptables -A FORWARD -p TCP -i devicename -d 0/0 --dport 25 -j DROP

So, are you now a believer that I can control outgoing traffic without installing ZoneAlarm on every client or do I have to give you a login on my WRT54 so you can see for yourself?

dpt:wwwlogaccept tcp -- anywhere anywhere tcp dpt:ssh

flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460

match:0 relate:0

(...advgrp 2->9...)

(...grp 2->9...)

TRIGGER type:out match:5200 relate:5198-5199

TRIGGER type:out match:5200 relate:5198-5199

I believe you may also use a shotgun as a firewall if the network is implementing RFC 2549.

David.

Okay, you don't know what it does or how it does it.

Why are you making statements about what it will or won't do, complete with proclaimations about whether it really is this or that?

You've made just a "whole lot" of statements about something you don't know a whole lot about.

I don't need to ask people who are *guessing*. I've got the source code for the WRT54G, and I know what it is doing.

And now here you are pretending to know Linux internals, claiming that some Linux firewalls are "real" while others are not.

(Unless you go back to a 2.2 kernel, they are *all* using the exact same software. Your statements are based on what you "briefly looked at", not on facts.)

You should not have said much, but did. Stick with what you

*know* and don't worry if that is impressive or not.

You keep saying things that are *abjectly false*, and even when presented with proof positive, you simply scroll down a few paragraphs and say the exact same, *utterly* *stupid*, things.

They are in fact running some of the best firewall software available in the industry today.

1) *You* don't know that. 2) Does that make any difference? 3) What does the WG FW appliance cost?

Please *stop* posting bullshit. That is simply a false generalization.

First you are implying that routers *with* NAT have no other firewall software. That is *ridiculous* on its face.

An "appliance" is intended to be simple. But many routers are intended to provide virtually any functionality known.

Are you trying to be funny, or just doing it by accident?

Lets hope you are!

I would suggest that you *not* engage in technical discussions about firewalls and routers without doing a great deal more research.

Actually, the "other poster" forced you to finally admit that the WRT54G is all of that. You were telling people it was none of that, and refused to accept otherwise when told otherwise.

Silly statement. The /iftables/ program is not the firewall software itself, but is merely a way to configure, control and list the kernel /netfilter/ facilities.

That is what NAT is defined as. Inclusion of NAT of course does

*not* mean there is no other firewall functionality available.

Wrong. First, NAT is obviously exactly *that* in a limited form. Second, you continue to claim it is a dichotomy, where if it does that it can't do something else and you advise others to ignore all other "traffic flow" functionality.

That it does NAT is significant, *if* one needs NAT. SPI is significant, *if* one needs SPI. The two are not related in a user's priority list, even if they are tied at the hip within the source code that implements them.

But your continued suggestion that including NAT necessarily excludes other firewall functionality is absurd and not true in any circumstance.

So why is it not a "FW appliance"? It fits all the requirements...

Except of course that it runs Linux and has software and functionality that Duane Arnold doesn't understand... :-)

It certainly looks as if much of what you post is colored with the fear that Linux might be just exactly that.

You might be right too.

Iptables is a packet filter that can stop inbound and outbound. With the 54G NAT router using SPI and IPtables, It is a hardware device that fits the definition of a network firewall. I think that I mentioned that to the other poster.

If iptables was not in the mix, then no I would not consider the 54g using NAT and SPI to be a device that's a network FW.

As far as NAT is concerned, it's mapping technology or a translator that maps an IP from one network the outside network to another IP inside another network. And it allows the sharing of single public IP by multiple IP(s)/machines on a LAN. It doesn't control traffic flow by using filtering rules to control the traffic, therefore, it doesn't fit the definition of a FW software.

Duane :)

You do realize that TCP/IP does is not implemented with a 7 layer OSI model?

What makes you say that it doesn't operate at the "Application Gateway level of the OSI model"? And where do you get this business about the client/server modem and trust zones?

None of that is correct.

You are saying that it *does* fit the exact definition you have of a "FW appliance". (Once we throw out your invalid assumptions about what is or is not being done in equipment and software that you admit to not knowing anything about.)

It is just another, *better*, OS. That's all. I'd recommend highly that you start learning unix systems, whether it is Linux or one of the BSD's or Solaris or whatever. It might help you avoid some of these off the wall statements about firewalls that you've been making!

You seem to have nothing left but ad hominem...

Who does that make "little"?

If we can get Duane Arnold to stop making assumptions about what a firewall is or is not, and then stop making assumptions about what iptables is or is not, we could make progress. It seems petty slow going though...

Lets start off by noting *again* that iptables fits *all* of the requirements you outlined in the past. Your false generalizations taken from other sources that were *not* discussing iptables have no significance and are confusing you.

Lets look at your definitions:

Note that this and the beginning sentence in your description of a "FW appliance" are virtually the same.

The above is the part that is different.

That is the part which is virtually identical in the description of a router using packet filtering.

And here is the different part.

So lets skip the similar parts, and examine what these differences are!

A router with filtering:

"doesn't operate at the Application Gateway level of the OSI model. It doesn't break the client/server model; it doesn't have un-trusted and trusted zones."

A "FW appliance":

"operates at the Application Gateway level of the OSI model, breaks the client/server model, and has un-trusted and trusted zones."

First, there is no "Application Gateway level" in the OSI model. You are confused. An "application gateway" is a type of firewall, which consist of a proxy server that does indeed break the "client/server model" in that it breaks connections into two segments, placing itself in the middle, and allows only traffic which matches the rules it applies.

Second, in the identical parts of your descriptions you say that they *both* (which is correct) operate up through the Application Layer. They you deny that for one and not for the other. In fact Stateful Packet Inspection (SPI) does work all the way up through the Application Layer.

Linux systems, of which the WRT54G is an example, implement multilayer firewalls. Your insistence that if it provides routing then it doesn't do "true" firewall functions, is *still*

*wrong*.

The WRT54G, for example, provides for proxies, port forwarding, and a DMZ, all with dynamic packet filtering rules. It has all of the functionality you require for a "FW appliance".

snipped-for-privacy@apaflo.com (Floyd L. Davidson) wrote in news: snipped-for-privacy@barrow.com:

The other poster didn't force me to do anything.

Like I said, I did't pay too much attention to what you were talking about.

It's just a packet filter.

It must be your own interpretation of it.

It's not and it's just your opinion and nothing else.

SPI is the only software there that controls traffic and is defined as FW software.

What are you talking about here?

Duane :)

snipped-for-privacy@apaflo.com (Floyd L. Davidson) wrote in news: snipped-for-privacy@barrow.com:

That's because the router with it's packet filter works at level 3 and level 4 of the OSI model. And if the router is using SPI, then SPI examines the packets between the network layer of the OSI model to the Application Layer of the OSI model to validate that the connection is valid and that protocols are behaving as expected, it doesn't operate at the Application Gateway level of the OSI model. It doesn't break the client/server model; it doesn't have un-trusted and trusted zones.

Where as the FW appliance works at level 3 and 4 of the OSI model, examines the packets between the network layer of the OSI model to the Application Layer of the OSI model to validate that the connection is valid and that protocols are behaving as expected, operates at the Application Gateway level of the OSI model, breaks the client/server model, and has un-trusted and trusted zones.

Duane :)

If this post shows twice, you have my apology.

That's because the router with it's packet filter works at level 3 and level 4 of the OSI model. And if the router is using SPI, then SPI examines the packets between the network layer of the OSI model to the Application Layer of the OSI model to validate that the connection is valid and that protocols are behaving as expected, it doesn't operate at the Application Gateway level of the OSI model. It doesn't break the client/server model; it doesn't have un-trusted and trusted zones.

Where as the FW appliance works at level 3 and 4 of the OSI model, examines the packets between the network layer of the OSI model to the Application Layer of the OSI model to validate that the connection is valid and that protocols are behaving as expected, operates at the Application Gateway level of the OSI model, breaks the client/server model, and has un-trusted and trusted zones.

Duane :)

Linux is just another O/S, it's just another program written by fallible Human Beings, just another fly in the ointment and you're a little man. ;-)

Duane :)

I tired of talking to you as you don't know what you're talking about.

Duane :)