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.
The iptables on one of our systems got completely wiped. I've got all other required services working again now, but can't seem to figure out how to get it to allow the system to be contacted via its hostname. I've googled the issue to death and tried a few different ports that were suggested, but none seem to do it. This is a red had 5.1 machine.
Code:
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 137 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 138 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 139 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 389 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 945 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 948 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 949 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 952 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 43698 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 54480 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 982 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 985 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20048 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 42895 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53401 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 44624 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 40655 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5805 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5905 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 6005 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
When you say hostname resolutions do you mean via "host", "nslookup" and "dig"?
Is this server the nameserver? If so is it running BIND or something else?
For BIND 9.x you should open both udp and tcp for port 53 (inbound). udp is used for initial connection but tcp is used as a fall back for data that is too large to be sent via udp (e.g. DNSSEC information).
You might want to examine your name server configuration (named.conf for BIND) to see if you have any special setups like views that require multiple and separate rules for different alias IPs used.
Output should NOT be restricted to 53. There is a well known exploit that relies on being able to predict the inbound and outbound ports. In the old days one set both to 53 but to thwart that attack one is is supposed to make the outbound random so it can't be predicted.
When you say hostname resolutions do you mean via "host", "nslookup" and "dig"?
Is this server the nameserver? If so is it running BIND or something else?
For BIND 9.x you should open both udp and tcp for port 53 (inbound). udp is used for initial connection but tcp is used as a fall back for data that is too large to be sent via udp (e.g. DNSSEC information).
You might want to examine your name server configuration (named.conf for BIND) to see if you have any special setups like views that require multiple and separate rules for different alias IPs used.
Output should NOT be restricted to 53. There is a well known exploit that relies on being able to predict the inbound and outbound ports. In the old days one set both to 53 but to thwart that attack one is is supposed to make the outbound random so it can't be predicted.
When I say hostname resolution I mean pinging from another machine using the hostname rather than the IP (also when trying to access shares on windows systems). With iptables disabled I can access the machine using either the IP address or the Hostname, but with iptables enabled, I am only able to access it using the IP address.
No, this is not the nameserver and no changes have been made to the nameserver.
The ONLY change that occurred was the iptables on this machine being wiped.
This machine is not accessible from outside the local network. Additionally, it is a testing and development environment only. Quite honestly I'm considering just leaving iptables disabled for the time being until this is sorted.
When I say hostname resolution I mean pinging from another machine using the hostname rather than the IP (also when trying to access shares on windows systems). With iptables disabled I can access the machine using either the IP address or the Hostname, but with iptables enabled, I am only able to access it using the IP address.
Ping is never going to work as you do not have an INPUT rule to allow ping.
Now to your hostname issue, what or how are you accessing the device when the firewall is enabled?
Is the other machine able to resolve the hostname of this device to an IP Address with the firewall started?
Quote:
No, this is not the nameserver and no changes have been made to the nameserver.
The ONLY change that occurred was the iptables on this machine being wiped.
Ping is never going to work as you do not have an INPUT rule to allow ping.
Now to your hostname issue, what or how are you accessing the device when the firewall is enabled?
Is the other machine able to resolve the hostname of this device to an IP Address with the firewall started?
This is where backups come in real handy.
Yes, ping does work. I already stated that it CAN be accessed by IP address.
I can both PING (from windows cmd and linux terminal) and ACCESS SHARES (windows explorer) by using the IP Address. The ONLY thing that does not work is using the hostname.
We specifically do not back up this system because it is a testing and development machine only. This machine is only meant to be used for training and testing new database changes.
right now I can ping or type into the windows explorer address bar 192.168.0.6 and access the machine as expected.
If I disable iptables I can get the same result by typing "ebonhawk" instead of the IP Address.
All I want to know is what I need to add to the iptables to allow this to work with the iptables enabled.
Yes, ping does work. I already stated that it CAN be accessed by IP address.
When you say you can "ping and access the machine" are you talking from another device to the LINUX box or are you talking from the LINUX box to other devices? This really does matter when it comes to the firewall.
Quote:
I can both PING (from windows cmd and linux terminal) and ACCESS SHARES (windows explorer) by using the IP Address. The ONLY thing that does not work is using the hostname.
Again you have to be clear on which direction you are talking about. Are you trying to get to other devices using their host names or are you trying to get to the LINUX box from other devices using the host name of the LINUX box?
Quote:
We specifically do not back up this system because it is a testing and development machine only. This machine is only meant to be used for training and testing new database changes.
right now I can ping or type into the windows explorer address bar 192.168.0.6 and access the machine as expected.
If I disable iptables I can get the same result by typing "ebonhawk" instead of the IP Address.
All I want to know is what I need to add to the iptables to allow this to work with the iptables enabled.
OK you are talking web. Is the web server setup to know how to handle request that come in using "ebonhawk" and not the ip address?
I'm gonna start asking you if you are sure that you dns server is working (ps ax) and if is it configured right? Because it's not firewall problem cause you have all policy ACCEPT (iptables -L -n -v )...
The fact that you cannot access the machine using its name, but you can access it using the ip address has nothing to do with the way iptables is configured on the machine you're trying to access. The problem obviously resides in the way the DNS server is configured and perhaps the way iptables is configured on the dns server. If the machine isn't a DNS server, then you should delete the lines in the iptables giving access on port udp 53 to the INPUT chain.
If you added a line on /etc/hosts or in the hosts file (system32\drivers or something like that) in Windows such as "192.168.1.1 machinename" on the computer you're using to access your linux server, you'd see that it would work. Which proves that it's independent of the way iptables is configured on your linux machine. I think you're slighly confused about how dns works.
Please explain how the iptables are not to blame when:
1) That was the ONLY change.
2) It works when iptables is disabled
You cannot tell me that iptables is not the problem when simply disabling iptables fixes it.
I have stated these facts already but everyone here seems to be ignoring them and looking for something else to blame.
I am not going to muck around changing other configurations that I know for a fact are not to blame because they have not changed and disabling iptables clearly solves the problem.
I understand, but you also said that the following:
Quote:
No, this is not the nameserver and no changes have been made to the nameserver.
And so if this is not the the dns server, it wouldn't make sense that changing anything in the iptables would make it work, really, while it DOES work using the ip. I don't know, maybe you're using NETBIOS (for which you'd need ports 137, 138 UDP and 139 TCP)?
By the way, you're saying that ping does work with those rules? Again, it doesn't make any sense. You're either showing use rules on a different server, or you're using another firewall on top if it and these rules don't apply or something is really broken
Sorry, ping does work because you're giving access to icmp - it's the first rule. It seems both lazydog and I missed it I had to scroll up a little bit
By the way, you're saying that you're tyipng a non-fqdn. Try typing the fqn, such as host1.domain.com, instead of just 'host1'.
Sorry, ping does work because you're giving access to icmp - it's the first rule. It seems both lazydog and I missed it I had to scroll up a little bit
Yeah I missed that one too.
Another finding is ports 137 and 138 should be on UDP not TCP
OP:
If after you make these changes and it still doesn't work try removing
Code:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
and see if you still are not able to connect. In order to figure out what is wrong we need to first know which rule is blocking your connection.
We specifically do not back up this system because it is a testing and development machine only. This machine is only meant to be used for training and testing new database changes.
I realize this is off-topic, but I have to point out that, IMO, "development" machines are the production machines for development, and should be backed up.
I won this argument at one site after one of the development machines crashed and the dev team spent two months recreating "under development" code that had not yet been released to production, and therefore was not backed up.
I realize this is off-topic, but I have to point out that, IMO, "development" machines are the production machines for development, and should be backed up.
I won this argument at one site after one of the development machines crashed and the dev team spent two months recreating "under development" code that had not yet been released to production, and therefore was not backed up.
Of course the machine where the source code is should be backed up. These developers were dutifully checking things out of the repository each day and checking them back in at end of day right? RIGHT?
We back up developer home directories but do NOT backup development copies of data and apps because we can (and frequently do) recreate them via refresh procedures from Production. If the developer has decided to violate policies (and common sense) by squirling away their own "copies" of source code then they deserve what happens.
At one job I made it a habit to regularly purge developer home directories of old copies of code and configuration files because they kept re-introducing issues that had previously been resolved by NOT checking out and using the most recent SCCS repository info for code on which they were working.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
