Need to disable/remove all firewalls...nothing seems to work

Hello, everyone.

I need to turn off all firewalls/iptables inside my Linux. I need to do this so I can run a streaming server which uses specifically port 8000 and 8001. I have tried all the commands offered in this forum and others, and nothing works. No matter what I do, I get the same error message in the server to the effect that I need to disable my firewall.

I run RedHat 9 with kernel 2.4.20-8. I am trying to run SHOUTcast. I am on a large university LAN, but I know for a fact that it is NOT behind a firewall. I have tested the broadcast server using both Mac and Windows, and I can broadcast just fine over those machines.

Here is what I have tried so far. I have even tried them in combinations, redundantly, if you will:

(1) In the Services setting dialog, i have unchecked IP Tables and stopped the service, followed by a restart.

(2) When that didn't work, I went to terminal command line, and entered the following, from info posted in this forum:

# chkconfig --level 35 iptables off
# service iptables stop

(3) That didn't work, so I tried a port forwarding sequence, as given on the SHOUTcast forums:

# iptables -A FORWARD -o eth0 -p tcp --dport 8000 -j ACCEPT -d $IP
# iptables -A FORWARD -o eth0 -p tcp --dport 8001 -j ACCEPT -d $IP
# iptables -A FORWARD -o eth0 -p upd --dport 8000 -j ACCEPT -d $IP
# iptables -A FORWARD -o eth0 -p upd --dport 8001 -j ACCEPT -d $IP

for $IP, I substituted my IP address, thus: $xxx.xxx.xxx.xxx

I used eth0 because my LAN card is on that configuration.

(4) That didn't work, so I tried a flush and remove-from-boot sequence, also according to a post at the SHOUTcast forums:

# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -F
# iptables -t nat -F
# iptables -X
# iptables -t nat -X
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

I also tried ppp0 instead of eth0 on the last line, just in case. But I know ppp won't work here cuz my LAN card is on eth, not ppp (not DSL).

That's four different approaches, all of them failing. Is there something I am doing wrong in each of these? Is there yet another way to turn off these firewalls, even uninstalling them completely if necessary?

I need to get these ports open ASAP. Please remember that I am running RH 9 with kernel 2.4.20-8.

I hope you can help me, and thank you in advance.

As an addendum to the above post:

I have, of course, set "Security Level" to "No Firewall".

Also, I was wondering if the problem could be a poor Internet connection, but that is not the case. All Web, streaming audio clients, and e-mail work great, very fast, in fact.

And, after each of the above options, I tried running the streaming server both before AND after a restart.

I've run out of options at the moment... Anyone who can help?

If you are turning off iptables (service iptables stop) and it still isn't working, then the problem is somewhere else. Most likely an application mis-configuration or something similar. I'm assuming here that you are using a stand alone system and not somekind of LAN with multiple machines that you are trying to forward ports to, right?

I've never run that application, but if it's a server the accepts incoming connections, use the netstat -pantu command to verify that it is actively listening for incoming traffic.

Originally posted by Capt_Caveman If you are turning off iptables (service iptables stop) and it still isn't working, then the problem is somewhere else. Most likely an application mis-configuration or something similar. I'm assuming here that you are using a stand alone system and not somekind of LAN with multiple machines that you are trying to forward ports to, right?

That's right. This is a stand-alone computer on a large LAN. I don't think networking is the problem here. I can broadcast just fine on both Mac and Windows, so this must be a Linux internal problem.

I agree that the problem is somewhere in my configurations, possibly not in iptables.

I've never run that application, but if it's a server the accepts incoming connections, use the netstat -pantu command to verify that it is actively listening for incoming traffic.

I am trying to use the server as a relay from my primary server, which is on a Mac at another location. The Linux server connects just fine to the Mac server. But the Mac server is also within the university LAN system. The problem is that SHOUTcast, and all listeners, cannot "see" the Linux computer "through the Internet" (that's the language the SHOUTcast server uses.) It then goes on to advise disabling "Firewalls/NAT/File Sharing/IP cache".

This application is basically the same as for Mac and Windows, so the messages would be the same.

That said, I'll try the "netstat" command you recommend and I'll let you know what happens.

Thanks!

I think you'll probably have better luck forwarding the shoutcast traffic directly from the linux machine to the mac, rather than trying to use one shoutcast server as a "proxy" for the mac server. Although if the documentation says it supports that exact type of setup, then I could be wrong (but that is a fairly abnormal configuration for most server applications).

Originally posted by Capt_Caveman I think you'll probably have better luck forwarding the shoutcast traffic directly from the linux machine to the mac, rather than trying to use one shoutcast server as a "proxy" for the mac server. Although if the documentation says it supports that exact type of setup, then I could be wrong (but that is a fairly abnormal configuration for most server applications).

Thanks for the observation.

But actually, the SHOUTcast server does allow for relays. This is a streaming server, designed to behave in a way that is analogous to a conventional radio transmitter. In the configuration file, you can specify the IP address of the server you want to relay. The relaying server will receive the stream and retransmit it under its own IP. By doing this, we can "cluster" servers and increase our listening audience by using several Internet connections for one broadcast--exactly like a conventional radio network. I've run several relays in this fashion before.

I cannot use the Linux machine at this point as my primary server, because my "source"--or "production"--software is on the Mac.

I am using Linux rather than Windows because of all the recent security problems we have had here with Windows. Basically, I'm tired of fighting off all those worms that keep attacking Windows! Besides, I like UNIX (I've used Mac for years).

So, I'm committed to getting this relay to work on the Linux. I'm already using the Linux machine successfully for less tricky, personal needs.

OK. Well in that case, use the netstat command to see if the server is up and listening for connections. Using nmap to scan from a remote system will probably be advisable as well. Have you modified the shoutcast configuration files in order to allow relaying?

//Moderator note: This is sounding more like a networking issue rather than a linux - Security one. Moving thread to Linux - Networking.

The server has been configured to allow relaying--I've checked and rechecked. As I noted earlier, the Linux server DOES connect to the Mac server. But it won't go beyond that. I don't know, the problem may be in the configuration of the network, now that I think about that.

I'll try the commands you suggest to test the connections and then get back to you.

Thanks for your time and effort!

By the way, I sent the same query to the SHOUTcast forums, and I'm still waiting for a useful answer from someone there, too. Actually, this forum is already a lot more helpful than SHOUTcast.

I did netstat -pantu, and here's what it showed, related to the server I want to use:

tcp 0 0 xxx.xxx.xxx.xxx:42091 xxx.xxx.xxx.xxx:8000 ESTABLISHED 5207/sc_serv
tcp 0 0 xxx.xxx.xxx.xxx:32826 xxx.xxx.xxx.xxx:8000 ESTABLISHED 4554/xmms

I replaced my IP numbers with xxx's for privacy. The IPs on the left are the Linux, the ones on the right are for the Mac.

You can see sc_serv has established a connection with the computer it should relay.

Just so you can see what the shoutcast server looks like, I've included a copy below:

*******************************************************************************
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc. All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
*******************************************************************************

Event log:
<05/10/04@17:40:27> [SHOUTcast] DNAS/Linux v1.9.4 (Mar 17 2004) starting up...
<05/10/04@17:40:27> [main] pid: 5207
<05/10/04@17:40:27> [main] loaded config from sc_serv.conf
<05/10/04@17:40:27> [main] initializing (usermax:50 portbase:8000)...
<05/10/04@17:40:27> [main] No ban file found (sc_serv.ban)
<05/10/04@17:40:27> [main] No rip file found (sc_serv.rip)
<05/10/04@17:40:27> [main] relay thread starting
<05/10/04@17:40:27> [source] creating relay socket
<05/10/04@17:40:27> [main] opening client socket
<05/10/04@17:40:27> [main] Client Stream thread [0] starting
<05/10/04@17:40:27> [main] client main thread starting
<05/10/04@17:40:27> [source] relay host gave success (ICY 200 OK)
<05/10/04@17:40:27> [source] relay from XXX.XXX.XXX.XXX established.
<05/10/04@17:40:27> [source] icy-name:RADIO MACONDO: Pura Salsa, Puro Son...El Canal Salsero de ORSRADIO! ; icy-genre:World Latin Salsa
<05/10/04@17:40:27> [source] icy-pub:1 ; icy-br:96 ; icy-url:http://homepage.mac.com/jslmg/radiomacondo/english.htm
<05/10/04@17:40:27> [source] icy-irc:N/A ; icy-icq:N/A ; icy-aim:N/A
<05/10/04@17:40:38> [yp_add] yp.shoutcast.com gave error (nak)
<05/10/04@17:40:38> [yp_add] yp.shoutcast.com gave extended error (Cannot see your station/computer (IP: XXX.XXX.XXX.XXX:8000) from the Internet, disable Internet Sharing/NAT/firewall/ISP cache (Connection timed out))

Once again, I've replaced the IPs with XXX's. The first IP is the Mac's, while the second is the Linux (the one yp.shoutcast.com can't see). You can also see that the relay has been configured correctly, as the info is reflected in the server init messages.

I'm going to test the connection Linux is on using a Windows PC. If I can establish a connection with Shoutcast through Windows, I'll know for certain that the problem is in Linux, not on the network. I tested another connection IP on the same LAN and gateway address, but not this specific one.

There have been some changes on the LAN since the latest worm attack, last week. That's why I wonder if the network configuration somehow has changed. This test will be a longshot, but it's worth a try.

You know, there's little point moving your server to Linux for "security" if you're going to turn the firewall off. It might not be vulnerable to the same mass-worms that Windows is, but there are plenty of vulnerability scanners out there that that can activate an exploit and rootkit that are just as deadly.

Your netstat output shows that you've opened up two connections to remote machines on port 8000, but your machine is not listening for incoming connections on port 8000 (even though that's what the software says it's doing). Actually, according to the output from netstat your machine is not listening on any ports, which is pretty much impossible for a default install of Linux, especially Red Hat. There should be a ton of ports listening by default.

What's the output (while supposedly running shoutcast) of
iptables -L (I think that's it, to list?)
netstat -anF inet

You shouldn't be trying to masquerade with iptables if you only have one NIC, there's nothing to masquerade from.

Last, as a note for any aspiring programmers... If you get to a networking error condition in your program that indicates no connectivity, don't tell the user to disable all their security features and all their other software! That's just down-right lazy. Instead, the user should be given the exact resources that your program needs available and some helpful tips on how they might verify that those resources are available, and if not some specific things they could do to correct it. The shoutcast programmers should be beaten with shoes for telling users to disable their firewall and all their other file sharing software. That's the worst cop-out error message I've ever seen.

Originally posted by chort Your netstat output shows that you've opened up two connections to remote machines on port 8000, but your machine is not listening for incoming connections on port 8000 (even though that's what the software says it's doing). Actually, according to the output from netstat your machine is not listening on any ports, which is pretty much impossible for a default install of Linux, especially Red Hat. There should be a ton of ports listening by default.

Actually, you misunderstood my previous post. I DID have a long list of connections in netstat. I simply cut the rest out of the message to save space, leaving only those that were immediately relevant to the server. For clarity, I'm putting the entire list in this message, below.

What's the output (while supposedly running shoutcast) of iptables -L (I think that's it, to list?) netstat -anF inet

These look like they could possibly be useful commands. I'll try them and let you know what I get.

About the issue of disabling or taking out iptables: I really would rather use some sort of port opening sequence, rather than disabling the iptables. I hope someone here can help me with that.

But here's a point: How prevalent IS hacking in the Linux world? Surely I stand far fewer risks in Linux than in Windows. What are the comparative odds between the two systems?

Back to my problem at hand: Please refer to my post again if you need to review what I've already done. I'm also interested in whether there were any errors in what I tried.

You know, so very often it's some minor detail that keeps us from running these commands or sequences successfully. Most of the sequences were run on other distros, for example Suse. Could that be a factor here? Perhaps I need some sequences that are tried and true to RedHat 9 and this particular kernel.

I just want to thank everyone for taking the time to help me--you're all very professional and thorough about this.

The complete netstat data is below. Hope this clarifies everything. As usual, I've replaced the "sensitive" IPs with xxx's. Now that I've done it, I notice how important the other data is. The very first listing shows sc_serv (shoutcast server) listening on port 8000:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 5318/sc_serv
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 3668/
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 3787/xinetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 3649/
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 3999/X
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3773/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 3863/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3824/
tcp 0 0 xxx.xxx.xxx.xxx:42272 xxx.xxx.xxx.xxx:8000 ESTABLISHED 5318/sc_serv
tcp 0 0 xxx.xxx.xxx.xxx:32826 xxx.xxx.xxx.xxx:8000 ESTABLISHED 4554/xmms
udp 0 0 0.0.0.0:32768 0.0.0.0:* 3668/
udp 0 0 0.0.0.0:32775 0.0.0.0:* 4554/xmms
udp 0 0 0.0.0.0:876 0.0.0.0:* 3668/
udp 0 0 0.0.0.0:111 0.0.0.0:* 3649/
udp 0 0 0.0.0.0:631 0.0.0.0:* 3863/cupsd
udp 0 0 xxx.xxx.xxx.xxx:123 0.0.0.0:* 3804/
udp 0 0 127.0.0.1:123 0.0.0.0:* 3804/
udp 0 0 0.0.0.0:123 0.0.0.0:* 3804/

I just ran iptables -L, per Chort's suggestion. Here's what it shows, fully:

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Keep in mind that I've already stopped iptables services. Is there anything here that helps???
Looks like it just shows iptable rules.

I also tried netstat -anF inet. I just got a usage manual, no output stats. What exactly was the command I should enter there to get output info?

Should I try "netstat -l"? That shows all listening ports.

Last, as a note for any aspiring programmers... If you get to a networking error condition in your program that indicates no connectivity, don't tell the user to disable all their security features and all their other software! That's just down-right lazy. Instead, the user should be given the exact resources that your program needs available and some helpful tips on how they might verify that those resources are available, and if not some specific things they could do to correct it. The shoutcast programmers should be beaten with shoes for telling users to disable their firewall and all their other file sharing software. That's the worst cop-out error message I've ever seen.

I hope I'm not over-posting here, and this will be my last until I have more statistics or a reply from someone, but I just wanted to comment on this.

Yes, Chort. The folks at SHOUTcast are notoriously UNhelpful, and that's the root of their software's problems, I think. What they offer is a link to some extremely outdated HOWTO's on ipchains and firewall management. These actually refer to kernel 2.0.xxx, and nothing more recent!

Nobody at SHOUTcast has yet answered my query about the firewall issue, either, except one chap who was an expert on Windows networking, but knew nothing of Linux. I keep asking, WHO at SHOUTcast wrote the code for their Linux version? Why can't that person answer me?

Chort, would you allow me to post your comment as above at the SHOUTcast forums? Someone there should be made aware of how programmers like you feel and should be made to account for it. I would not put any personal info about you, of course, unless you wanted me to. I would like to say that it came from a "programmer" at LinuxQuestions forum though.