running commands in scripts

[Zelandakh]

If I try to run ipchains logged on as me

[username@linux username]$

I get an error that I don't have permission.

If I run it as root

[root@linux username]#

I get the command not found error (path problem?)


When I am on as root I can type each line from the script manually and everything works fine, but in a script it fails when I type

. scriptname

with loads of errors.

What is my obvious mistake and how do I cure it?

 

[GoldenEternity]

The first problem (command not found as root) is probably because you su'd to root without using the - or -l switch. The sbin directories are generally not in normal user's paths, so when you su you'll need to create a new login session in order to obtain the path settings normally configured for root.

The second problem... well, I think I'd have to see the script, or at least some of the errors.

 

[MrTom]

try adding a

PATH=/sbin:/bin:/usr/sbin:/usr/bin

in the script.

 

[Zelandakh]

Extract from script: IP address on the Net has been changed!!

#!/bin/sh
PATH=/usr/sbin:$PATH

/sbin/ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0

If I manually type in /sbin/ipchains and its parameters as root it works fine.
If I do it as a normal user I get permission denied.
If I let the script run exactly, it fails but it says exactly the same stuff that I type manually.

I have got around the problem by manually typing the script out in full. This is a pain in the ain so I want to get it sorted even though we only reboot the server once a year.

 

[GoldenEternity]

If thats the entire content of the script, then your path setting is a waste of time. You're calling ipchains with the full path name, so $PATH isn't an issue. If you wanted to call it without specifying the path, then you'd need to change the path declaration to:

PATH=/sbin

ipchains needs to be run as root, since you are making changes to the way that the kernel handles input. If you try to execute this script as a normal user, expect errors.

You could set this script suid root, but I would advise against it. Generally, this command would be run during system boot, so placing it in rc.local should do the job.

 

[marsd]

ipchains-restore
ipchains-save
These two programs are timesavers.
ipchains-save > /etc/firewall(or whatever)
run locate ipchains-restore, so you know the full
path, and then add the line:
ipchains-restore < /etc/firewall
to boot.local, or whatever your distro uses.
better safe than sorry.

 

[mbr]

Hi,

I still do not know exactly what the problem is..

Is &quot;Extract from script: IP address on the Net has been changed!!&quot; a error-message that you get or a comment by you?

And what is the script you run by &quot;. scriptname&quot; (dot space scriptname) - are you sure you run the script you think you are starting? (maybe a PATH-problem?)

mbr

 

[Zelandakh]

Here is the situation:

This is my live firewall and I need to keep hackers out (that's the general idea!). It works for most things but I need to modify the settings to allow:

Net to see my IIS (works already)
Incoming and outgoing SMTP on port 25 (works already)
Webcache on port 8080 (works already)
All internal IP addresses can surf (works already)

MSN Messenger (fails)
Netmeeting (fails)

Full script named S99firewall which runs as the last script was as follows:

#!/bin/sh
PATH=/usr/sbin:$PATH

#add in FTP masquerading
# Needed to initially load modules
#
depmod -a

# Supports the proper masquerading of FTP file transfers using the PORT method
modprobe ip_masq_ftp

#if we don't know where it goes then it goes to the internet
THIS=<my real Net IP>
route add default gw <my real Net router>

#switch on kernel routing services
echo 1 > /proc/sys/net/ipv4/ip_forward

#flush out all rules
ipchains -F input
ipchains -F forward

#set defaults
ipchains -P forward ACCEPT
ipchains -P input ACCEPT
ipchains -P output ACCEPT

#allow all internal IP addresses through the Firewall
ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0
ipchains -A forward -j DENY

ipchains -A input -j DENY -p tcp -i eth1 -d $THIS 0:24
ipchains -A input -j DENY -p udp -i eth1 -d $THIS 0:24
#allows incoming SMTP on port 25
ipchains -A input -j DENY -p tcp -i eth1 -d $THIS 26:52
ipchains -A input -j DENY -p udp -i eth1 -d $THIS 26:52
ipchains -A input -j DENY -p tcp -i eth1 -d $THIS 52:79
ipchains -A input -j DENY -p udp -i eth1 -d $THIS 52:79
#allows incoming html for IIS on port 80
ipchains -A input -j DENY -p tcp -i eth1 -d $THIS 81:1024
ipchains -A input -j DENY -p udp -i eth1 -d $THIS 81:1024
#drop stray X traffic
ipchains -A input -j DENY -p tcp -i eth1 -d $THIS 6000:6010
ipchains -A input -j DENY -p udp -i eth1 -d $THIS 6000:6010


I added the /sbin/ to each call as it works when you type it manually. Now this script justs fails dismally when I boot and I have to type in in manually. If I type:

. S99firewall

I get command not found errors and usage incorrect errors. Where do I go from here? Anyone good with IPChains?

 

[Zelandakh]

The script sits in /etc/rc.d/rc3.d and I can vi it quite happily.

. S99firewall as a user gets permission denied. The same thing as root runs some of the script and stops the firewall working until I type each line manually... Hence I don't actually want to retry it!!!

 

[mbr]

Hi again,

you probably did not key in the following lines:

THIS=<my real Net IP>
route add default gw <my real Net router>

, which certainly give you errors when executed by the script.

Itshould not be necessary to add a default route via your fw-script, that should be handled when setting up the connection.

To use the ip-address of your external interface, use something like:

ADR=$( ifconfig hme0 | grep inet | cut -d ' ' -f2 )

, where hme0 has to be replaces by your interface-name.

HTH
mbr

 

[Zelandakh]

This script was written by a Linux pro and worked at the last reboot (over a year ago).

The only thing that has changed is that it was shut down dirty and I had to run fsck once it came back up.

Anyone got any ideas on how I can open the right ports to run MSN (which WAS working) and Netmeeting? I'm rather in the dark on this project...

 

[GoldenEternity]

Well, one thing I noticed is that you set your forward policy to accept, and then reset it to deny... Maybe you should change the policy, and that'd eliminate the need for the second line. That shouldn't be your problem though.

Try putting some markers in the script (with echo) to try to track down where the script goes awry.

 

[Zelandakh]

If it runs at startup, is there any difference to running it as su by doing . S99firewall ?

If I can do it exactly the same, then I can copy and paste the results, but as it stops the firewall working until I retype line by line, I only want to do it if it is beneficial.

Beginning to wish I had just told them the firewall could not be modified...

 

[Zelandakh]

oops. Since the above, someone has used our server to hack into NASA...

Anyone good with ipchains? Need to solve this problem fairly rapidly!

 

[GoldenEternity]

In that case, there may be no problem with the script. If your server has been compromised, then acting wiggy is to be expected. You need to reinstall, patch, harden, and then bring the system back on the net.

 

[marsd]

This was a badly written firewall script in my opinion.
The security is very loose and the configuration is static.
If new services are added they are automagically allowed
access from hostile hosts even if that was not the intent.
A better idea would be to amend the policy to deny all input
and allow connects on a per service basis.

You need to run some proactive defense too..At the least have some snapshot netstat/lsof : cronjobs running. Better to get something like portsentry and set up a secure loghost
and net monitoring station, or honeypot.
Configure your syslogd (man syslog.conf) to extreme(debug)
levels for critical processes and services. Run a
&quot;logtip&quot; script to prune your logfiles so they don't become
unmanageable.
Install tripwire on all your hosts and harden the distribution at install time; you would have had at least a little warning. Use tcpwrappers to wrap inetd driven daemons, in addition to your packet filter.

Leave the first section of the script intact and amend the rules.
quickly:
mailserver=&quot;mailaddress&quot;
webserver=&quot;webserver address&quot;
proxy=&quot;proxy address&quot;
additional host addresses=&quot;addresses&quot;
ftpserver=&quot;ftpserver ip&quot;
rules:
ipchains -P input DENY
ipchains -P output ACCEPT
ipchains -P forward DENY

ipchains -A forward -j MASQ -s 192.168.0.0/24 -j ACCEPT

ipchains -A -s 0/0 -d $mailserver 25 -j ACCEPT
ipchains -A -s 0/0 -d $webserver 80 -j ACCEPT
#cache in
ipchains -A -s 192.168.0.0/24 -d $proxy 8080 -p tcp -j ACCEPT
#ftp
ipchains -A -s 0/0 -d $ftpserver 20:21 -p tcp -j ACCEPT -l
ipchains -A -s 0/0 -d $ftpserver 20:21 -p udp -j ACCEPT -l
#allow return connects
#may need to be modified for env.
ipchains -A -s 0/0 -d 0/0 1024:3500 -p tcp -j ACCEPT -l
ipchains -A -s 0/0 -d 0/0 1024:3500 -p udp -j ACCEPT -l
#same for high port connects
ipchains -A -s 0/0 -d 0/0 45000:65000 -p tcp -j ACCEPT -l
ipchains -A -s 0/0 -d 0/0 45000:65000 -p udp -j ACCEPT -l

This is not perfect and some things won't work at first,
but you will be better off with this type of idea.
If you have been cracked save your config, reformat and
reinstall.
You might even want to think about the 2.4.x kernels with iptables and have an expert come in with that, it is stateful and seems pretty secure, if more complicated.

 

[marsd]

oops, all the rules except the forward should be input
rules, too big a hurry.

bye.

 

[GoldenEternity]

Portsentry wouldn't be much use with a default deny policy.

Honeypots have become the security word du jour, but for most sites they wouldn't be as useful as a good old fashioned IDS. Especially if you don't have an extra IP to give to the honeypot or your admins don't have any spare time to build and maintain a secure yet exploitable system.

But on the whole, marsd's comments are pretty right-on.

 

[mbr]

Hi Zelandakh,

first of all I have to beg your pardon for being absolutely confused about that &quot;THIS=<>&quot;-thing in your script. I was in a hurry, about to leave the office to join the LinuxDay in Stuttgart/Germany, so i had better written nothing than nonsense.

I think it is commonly agreed within these forums, that someone may fail or forget some vital aspect when answering to a post, but you certainly can expect that a person who answers uses the <BRAIN>-Tag before posting. This is not only because of a possible damage to your system as a result of a wrong advice. So once again sorry for that.

For now i'm not sure if your problem has been solved by the meanwhile given answers. If you still search for the problem in your script, include a &quot;set -x&quot; - statement at the beginning, to see each command printed out before it is executed. That way you can definitely see which line of your script produces the error.

If the system has been compromised, it's necessary to reinstall and harden as advised by the others already.

yours,
mbr

 

[Zelandakh]

Wow. Thanks to all so far for your help.

I am hoping to get an expert in shortly to reinstall and harden everything. In the meantime, I will be implementing the script as written up by marsd above.

The THIS command is a set variable so I don't have to retype my live IP Address on every line. It looks like my current script allows everything internal to go to the firewall, but only certain stuff in from outside hence the use of the -i eth1 switch. But I am not 100% sure of that.

Now I just have to find a Linux expert who knows ipchains or other package, security, can reinstall a server with minimal downtime, works in London, is available pretty immediately and has low costs.

Easy...