Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What rules would I need in my firewall to pass all traffic coming in and going out ports on 5060 UDP, 1020-1030 UDP, 13456-13463 to my DMZ where my VOIP modem is located. I also want to make sure that my internal network is secure from my firewall? An example please. thanks
1- ideally, the DMZ should be a separate subnet. You should also have firewall rules such that devices on the DMZ can not open connections to the inside devices. The idea of a DMZ is that if the machine(s) out there expose services to the Internet and might get compromised (through that service). If machines on the DMZ get compromised, you do not want these to be able to connect to other machines (on the inside network) to propagate a worm or something similar. This is why you must isolate the DMZ. Beware that the DMZ devices should not be able to INITIATE a connection/session toward the inside machine but must be able to RESPOND to queries coming from those inside machines (you have packets flowing in both directions in each case but the difference is in WHO establishes the session).
2- The problem with H.323 is that it is not a NAT friendly protocol. Have a look at this page for a NAT patch as well as some examples on how to configure NAT and create the filter rule you want: http://max.kellermann.name/projects/netfilter/h323.html
3- I do not use Suse; I can't answer that precisely.
4- NMAP gives you a very good snapshot. You might try Nessus if you wanted to go deeper http://www.nessus.org/. You can also try launching specific attacks to your services. Think that a firewall is one level of protection for weak systems or against misconfiguration but properly patched systems are key.
could you post an iptables rule as an example on how to route traffic from the outside world and vise versa to my device on my DMZ (192.168.3.119) thanks
There are two things here: routing/forwarding and filtering.
The routing/forwarding part will happen naturally as soon as you activate it with
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
It is good practice to give routers the first or last addresses in the subnet they are connected. Let's assume you give your FW the addresses 192.168.3.1 and 192.168.2.1 on the DMZ and inside respectively. Then, all the devices in the DMZ will have to point to 192.168.3.1 as their default gateway and all the devices inside will have to point to 192.168.2.1.
The above will provide you with full communication between inside and DMZ. Now, you need to restrict access to allow only SOME traffic to go through.
Let's say you have an HTTP (Apache) server at 192.168.3.2 that everyone can reach. This server can respond to requests but can not create connections to anyone.
Code:
ipchains -A forward -p tcp --syn -s 192.168.3.2 -j DROP
ipchains -A forward -p tcp -s 192.168.3.2 --sport 80 -j ACCEPT
ipchains -A forward -p tcp -d 192.168.3.2 --dport 80 -j ACCEPT
ipchains -A forward -d 192.168.3.2 - j DROP
ipchains -A forward -s 192.168.3.2 - j DROP
This is a very dirty example that needs to be tuned to your network (if you do that for each individual server, your tables will be long). There is a lot more to think about when setting up a firewall. The linux-sec network may be interesting for general security awareness.
The IPTables HOWTO may be of interest to you for setting up iptables.
You may also get your hands on a good TCP/IP book (like 'TCP/IP illustrated') as all your answer reside in networking knowledge.
When you have a DMZ that i means that the everyone including the internet can communicate with that device correct, but that device cannot communucate with your internal network for security reasons correct?
I quess what I am asking is for a IPTABLES rule that I can use to allow the internet to communicate with this device but allow the internal network to log all activity. That is what I need. I see that you are using IPCHAINS and that is slighty different because it is older correct? thanks
What rules would I add to iptables to allow all traffic comming from the internet through to the VOIP phone and vice versa. I want to be able to track the traffic for this VOIP device through logging. How can this be done?
Last edited by metallica1973; 09-16-2005 at 04:26 PM.
Yes, I used ipchains instead of iptables. The difference is minimal for this example. Just replace the word 'forward' with 'FORWARD'.
To clarify the explanation about the DMZ, you got it right: anyone can use the service in the DMZ but the devices in the DMZ should not be allowed to connect to your inside network. This is of course an ideal case... you can not always prevent DMZ -> inside connections in a given budget. Ideally, DMZ devices should be prevented from opening ANY connections that do not pertain the service they offer. This is to prevent an attacker from using the DMZ machine as a launch pad. There are a lot of notions under this but the bottom line is simple: a DMZ host should not be able to create connections for services it is not supposed to use.
As for your voip gateway, I think I was not clear enough: H.323 changes ports on the fly and those ports are very difficult to track down by a firewall. You can NOT achieve proper security with static rules. This is why you need to install a special module and follow the configurations of the module as explained here .
In your case, this will translate into adapting the following lines:
Code:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 1720 -j ACCEPT
into
Code:
iptables -A INPUT -d 192.168.3.2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -d 192.168.3.2 -p tcp --dport 1720 -j ACCEPT
Issues specific to the H.323 module should be addressed with their support lists (I do not use that module personally).
Ideally, for your clients/mates to use that service, there should be a way to contact that service univoquely so it is a good idea to have a fixed point of presence.
If you can't obtain a fixed IP address from your ISP for this server, you can use Port Address Translation (PAT aka NAT or Masquerading) and use your Internet connection's IP address. The module I pointed you to offers Tracking and NAT fixups for H.323.
If your IP address is dynamic, then you have somewhat of a problem: how are other going to reliably point to the server without first asking you the current server address ? There is a solution to this which is to use a dynamic DNS service like DynDNS.
What DynDNS (and other such providers) offer you is a DNS (Domain Name Server) address, i.e. a FIXED NAME that reliably points to your server's address. You will have to run an automatic script to have your IP address updated on the DynDNS server. This is explained on DynDNS' web site.
At this stage, your questions are barely Linux related anymore but general Networking oriented. I am afraid you picked a highly complex protocol for a start and you will lose your hairs trying to figure whether you hit a bug or a configuration problem. Given the overall complexity, I strongly suggest that you try first setting up something simple like an HTTP server... you will make your teeth on setting up a DMZ and NAT with that simple protocol. Use IP addresses for a start, then jump to DNS and DynDNS. This is the best ramp up path you can find.
Lingo is my VOIP phone service. They use TAS (Transparent address sharing). The name of my VOIP modem is Mediatrix 2102. it does not use the h323 protocol!
Last edited by metallica1973; 11-21-2005 at 04:46 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Voip DMZ
HELP!
