Hi.
I was wondering if someone could help me with the shorewall security issues.
I was a happy user of a Mandrake 8.1, with Bastille firewall running in the background until I've installed the 9.0 edition.
It wouldn't include the bastille software. The shorewall that came with 9.0 had a 'security hole' in it. I use the GRC.com/ShieldsUp to test the firewall vulnerability. Shorewall shows some ports 'closed' but responding to pings.
Bastille passes 'full stealth'.
Well, I eneded up with installing Mandrake 8.1 and 'overwritting' 9.0 over it.
At some point, during the installation I was asked if I wanted to remove Bastille and related components and I said NO.
That saved it from being 'upgraded' to (in my opinion) an inferior shorewall.
I actually had to remove the shorewall later.
Anyway - my question is: can a shorewall be configured so that it will close all ports and pass the ShieldsUp FULL STEALTH?
If not - is there any other firewall included with a download edition of 9.0 or 9.1?
I'm not a Linux guru, just an average user who likes the stability of the system. I'd appreciate any help.

Al

I assume you're talking about ports 113 and 135. These are ident and RPC and you don't really need them open. All you have to do is add the following to /etc/shorewall/rules

DROP net fw tcp 113,135

if the machine is acting as a router as well as a firewall add


DROP net loc tcp 113,135

assuming of course that your local network zone is called loc in the shorewall zones file.

Restart it with /etc/rc.d/init.d/shorewall restart

and your firewall will be as tight as a sharks arse at 40 fathoms.

I use Shorewall on a variety of machines running home and office networks and although it takes a bit of reading it is perfect for tricky firewall scripts.

Hi mormop.
Thank for your advice.
I've tried inserting the lines in the shorewall/rules file but it didn't work.
Can you tell me EXACTLY how and where stick those lines in?
I know - it's a file etc/shorewall/rules.
I open it with Kwrite and I see a bunch of # lines with dots.
I know that every single character counts and it's case-sensitive.
I'm not a Linux guru but I'm willing to learn. Tell me what the deal is with those # signs and the dots (they appear when I use the tab key).
This is what I did so far: I'd edit the 'rules' file, save it and restart the shorewall. Then I probe the port with 'ShieldsUp' and it's still 'closed'
I want it to be 'stealth'.
What am I doing wrong?
This is how the end of my shorewall/rules file looks like:
############################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Where and how should I put those lines in?
Thanks
AL

Can you tell me EXACTLY how and where stick those lines in?
I can't as I'm not familiar with Shorewall at all. I do know it has some documentation, so you could start looking for clues there.
If you think the Linux - Networking forum could yield more answers, just say so and I'll move this thread overthere, no prob.

I want it to be 'stealth'.
Please see http://www.linuxquestions.org/questi...134#post420134

I have had a similar experience running Mandrake 9.1.
I tried editing the "rules" file (in etc/shorewall), but it didn't work for me.
Instead, I copied the file "common.def" to the file "common" and edited the "common" file. Pay special attention to the NETBIOS Chatter and AUTH sections of the file. If you with to be "stealth" change the REJECT to DROP in those lines. My NETBIOS chatter section looks like:

# NETBIOS chatter
#
run_iptables -A common -p udp --dport 137:139 -j DROP
run_iptables -A common -p udp --dport 445 -j DROP
run_iptables -A common -p tcp --dport 135 -j DROP

and my AUTH section looks like:

# AUTH -- Silently reject it so that connections don't get delayed.
#
run_iptables -A common -p tcp --dport 113 -j DROP

Hope this helps!

Although the rules file is not directly related to your current question, I can provide an answer to the question about rules, in case you need them for future actions. Add rules after the line
and before the line
For example if you wanted to open port 80 for a web sever, the end of your rules file would look like:

I use shorewall too..
If you open port 80 and ACCEPT then it will appear as OPEN to any requests. Is there a way of stealthing the port although it is open ? For example Norton Personal Firewall for windows stealths all the ports but still you can access the machine as a web server on port 80. Is there such a firewall for linux?

"Full stealth" == "Full security" is a security MYTH and anyone telling you otherwise doesn't relaly understand what they're talking about. "Full stealth" is not the holy grail of security, and responding to pings isn't the end of the world. Also, how in the WORLD are you going to be able to "stealth" a port but still have clients access it?

Look here, with TCP (since it's a stateful protocol) a request is sent from the client, to the server. The client patiently waits for the server to either answer back and start a negotiation, or to send back an ICMP unreachable signal that means the service is not running. Where so-called "stealth" mode comes in is that you can have your firewall simply discard incoming client packets to certain ports. The client will continue to wait patiently for a response (since there coule be some lag time) and eventually the client's connection attempt will time-out and the client gives up. This is considered "good" security since people scanning you did not get any kind of response back that might let them enumerate your OS and guess potential expliots that might work on it. Note that setting your firewall to "reject" or "return" a connection attempt rather than "drop" or "block" will result in the client being notified that you're not taking anything from them so they can tear down their connection and stop wasting resources waiting for something that will never happen. This is the "polite" way to respond.

Potentially you could configure your firewall to just drop all inbound connections--period. You can also configure your firewall not to respond to ICMP pings. This will make it very difficult (but not impossible!) to detect casually. It will also break some expected behavior of the Internet, such as route discovery. ICMP is the troubleshooting and maintenance protocol of the Internet and if you don't allow it, you're breaking functionality and being "rude". There are many ICMP codes that are usually blocked, but it is polite to return some of them (search any of the security mailing list archives for ICMP + firewall + rule, check SecurityFocus.com).

By the way, getting back to dropping packets and why Shorewall rejects 113 and 135 rather than dropping them, it has to do with services that rely on those ports but don't use them directly. Many times IRC and some other types of service issue an IDENT challenge to your IP address to reverse verify you. Now they usually don't require the IDENT response, but they will wait to let you on their service until they have received a response back or timed-out. If it takes 60 seconds for the IDENT response to time-out, then you're waiting around until it finishes. This is what will happen if you "drop" on port 113 instead of "reject". That's why most firewalls are configured by default to reject port 113/TCP.

As for port 135, I can only assume that some stupid Microsoft protocols rely on being able to contact the RPC DCOM mapper and won't continue their operation until they have a response. If you "drop" then the service will wait a long time to do anything, just like the IRC example above. I disagree that you would want to be "polite" to MS RPC requests from outside your network. Anything on the external interface should be dropped IMHO. Now on your INTERNAL interface, if you're running MS boxes but now allowing MS services outside your LAN, then yes you would want to "reject" port 135 on your internal interface.

Now the last point is that in order to provide some type of service (such as the ability to view web sites on your machines) you need to send the data from your machine to people trying to look at it. The only way you can know that people are trying to look at data is if they request it (unless you're really good at guessing!), so there has to be a method they can request data and if you want them to see it you'll have to send it to them some how, won't you? All the primative scanners do is simply pretend to be someone trying to look at your website, or send you e-mail, or download from your FTP site, etc... When your server responds back saying "how can I help you" (basically) then the scanner found you. There is no possible way you can ever hide a server from a scanner, because you can at the very least use a piece of software by hand to scan (use a web browser to type in random URLs for instance). In truth it's much more simple than that. There are even ways to detect services that you have configured not to respond to connection attempts, so in reality it's much more easy for a scanner to find you than it is for a legitimate client to find you. In short, you can NEVER "full stealth" your webserver and still let people see it (well, this isn't taking into account using ACLs with the IPs of everyone who you want to view your site, but we're talking in practical terms).

I hope that clears things up.