[cobalt-users] RE: Raq3 Mysterious Death & Backup Mystery

[Chae <chae@xxxxxxxxxxxx>]

Hi Yah,

Thanks to everyone's replies and sticking with me during my umpteen lengthy 
emails :)

Dave Thurman Replied:

"I am no expert in the firewall logs, but a quick google tells some 
stories. backup-server-ip:20 is calling on port 20, isn't this a udp port 
for FTP??"

Been doing a lot of reading up on this and have seen various ways to 
overcome the issue...for example:

/sbin/ipchains -A input -i eth0 -p TCP --dport 20:21 -j ACCEPT
/sbin/ipchains -A output -i eth0 -p TCP --dport 20 -j ACCEPT

or

/sbin/ipchains -A input -d -i eth0 -p tcp --dport ftp -j ACCEPT
/sbin/ipchains -A input -d -i eth0 -p tcp --dport ftp-data -j ACCEPT

But my problem was that the server was doing the backup's in active mode 
instead of passive mode, passive would connect via tcp which meant I 
wouldn't have the issue that I'm having. I did ask the question a while 
back about how I can make the server FTP to the backup server in passive 
mode or if I could modify the raqbackup.sh to allow the server to FTP in 
passive mode, no replies though.

Then I read that someone else way back had a similiar problem - about page 
40 in one of my many Google searches and they had a ruleset very similiar 
to mine (rc.firewall)

/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 21 -d 0.0.0.0/0.0.0.0 1024:65535 
-i eth0 ! -y -p tcp -j ACCEPT
/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 20 -d 0.0.0.0/0.0.0.0 1024:65535 
-i eth0 -p tcp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 21 -d 0.0.0.0/0.0.0.0 
1024:65535 -i eth0 ! -y -p tcp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 20 -d 0.0.0.0/0.0.0.0 
1024:65535 -i eth0 -p tcp -j ACCEPT

All they did to rectify the problem was to add the following rules in:

/sbin/ipchains -A input -s 0.0.0.0/0.0.0.0 20 -d 0.0.0.0/0.0.0.0 1024:65535 
-i eth0 -p udp -j ACCEPT
/sbin/ipchains -A output -s 0.0.0.0/0.0.0.0 20 -d 0.0.0.0/0.0.0.0 
1024:65535 -i eth0 -p udp -j ACCEPT

So not being the firewall expert I opted to try the above first of all - 
first time I ran raqbackup this morning viola all files transferred first 
time, so we'll see if it does it again tonight on the cron job. But I still 
don't get why it would transfer with no problems and then have several days 
where there would be nothing but problems??

Now does anyone know any better or know why I shouldn't use the udp rules 
for port 20?

"Looks like the firewall is blocking yourself?? Are you entered into the 
ignore files for yourself??"

host.allow has both server IP and Backup server IP, portsentry.ignore has 
both IP's, and the fact the the server services died a death and wouldn't 
let anyone access anything does confirm that the chains had locked everyone 
out including me :)

"It's early, well really early and I am probably speaking out of turn but I 
think you are blocking yourself. Also on an earlier email you show a 
transfer starting in ASCII for the .tar.gz files. If I am not mistaken, 
they should be in binary."

Do you mean this part of the script log file:

250 CWD command successful.
200 PORT command successful.
150 Opening ASCII mode data connection for file list.

I think it's only stating ASCII mode so that the backup script can give me 
a listing of what's been transferred to the backup server via the email - I 
could be wrong though.

Gerald replied...

"looks like you need to have your high-ports open, 2000? Can you try and 
telnet to port 2000 and see what happens"

High ports are open all the way from 1024 to 65535, I've also posted in the 
past where IPChains has dropped packets on the FTP transfer at Port 4219

Dave Asked...

"Isn't that port part of the SSL and worm?? Or is that 2002"

Port 2002

Thanks to everyone again and fingers crossed this'll have sorted it out? 
Surely I can't be the only one using a RaQ3 with raqbackup.sh and having 
the FTP Backup transfer problem with IPChains??? - You never know - my mum 
always said I was one in a million (hee hee)

Regards

Chae