Re: Firewall Eval.
Do you have any logging facilities? What kind of logging do you want to see?
Do you want to see portscans, and take defensive action? portsentry
Do you want to see connections to firewall ports (not forwarded ports) ippl
Do you want to have the highlights of your logs emailed to you? logcheck
What are you doing with packets that are destined for blocked ports (ie everything but 22 and forwarded ports) I'm dropping them. -j DROP (-j DENY for ipchains)
Your drawing wasn't clear where .34 and .62 are. It appears that they are private systems sitting in your LAN that have IP addresses forwarded to them. You may have some big problems, but there isn't enough information there to determine that.
Where is your LAN? I see 'servers', but not 'workstations'.
If you haven't done so, you may consider setting up a DMZ, a demilitarized zone.
This is allows you to have internet servers (mail, web, etc) exist on the internet (protected by your firewall), yet outside of your network. Then there is strict access control between your real LAN and the DMZ. If a server is cracked, your internal LAN and your other production servers that don't need to be seen from the internet are safer. (Note: safeR)
Without having a DMZ, you have your web servers and other visible internet servers inside your lan. If one of them is cracked, your whole lan is too, unless you implement strict internal security (which is often more difficult than perimeter security).
Here's an example of "a friend of mine"'s network:
Internet <--> firewall <-- lan (note one way out)
\ production servers, workstations
\
\<--> DMZ <--> web server (note out or in)
email server
Now let's zoom in:
DMZ <-- firewall <-- LAN
Allowed ports:
80
drop everything else
Thus on this friends network, the lan can connect to the web server. In fact, you can restrict it such that the lan can connect only to a specific server on port 80, and nothing else. And nothing on the DMZ can connect to the LAN, except what's needed to return packets from webserver:80 back to the lan.
In the event that the web server is cracked, an attacker might probe around and see he or she only has access to other servers in the DMZ. A port scan of the lan will reveal NO ACCESS (or very limited access).
Without the DMZ, let's say your webserver is cracked. Now your firewall is worthless, because it happily forwards along traffic on port 80. When an attacker looks outside of the web server, lo and behold, there are many servers available. Your network may or may not be owned, depending on your internal security measures.
Make sure to protect your firewall against the DMZ as well, as it is an untrusted zone. It wouldn't be any good to have your web server cracked, then from the DMZ have your firewall cracked, then from the firewall, have your network owned!
Cory
On Thu, Mar 22, 2001 at 08:12:49PM -0800, Phill Kenoyer wrote:
> Thanks to the help from this list (and the docs back online for iptables) I have my firewall built.
>
> I just want to ask how my setup rates with the rest of the people on the list. Here is the map:
>
> Internet <-> router <----> firewall <----> servers
> x.x.x.32/27 10.0.0.0/24
>
> x.x.x.34 <-> 10.0.0.34
> ...
> .62 <-> 10.0.0.62
>
> I have a T1 with a /27 address range. I have put all my server on a 10.0.0.0/24. I'm using the firewall system to forward selected ports to the servers. I also have the firewall blocking ports in and out, like netbios.
>
> Is there anything else that I should be looking at or have missed?
>
> --
> _ | _
> (_()(|('.|)('||.|()|`|(
>
>
> --
> To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: