iptables & multiport

[Basher52]

I tried to use multiport to allow some ports in the fw-script, but it seems
that it cant handle portranges

I found this thru google:
http://www.netfilter.org/documentation/ ... -base.html
(find Andreas Ferber's input)

It says that this is not supported in the original version unless u patch multiport.
so what can i do?
this is what im trying to do:

_____________
iptables -t filter -A INPUT -s xx.xx.xx.xx -p tcp -m multiport --dport 35000:35200,glftpd -j GLFTPD_2
iptables -t filter -A GLFTPD_2 -j ACCEPT
_____________

I had some other code where the ports where on a different "line" than all the IP's, but that seemed to allow all icmp-requests to get thru this perticular rule, even tho it shouldnt

Does anyone got a nice answer to this?

/B52

PS. Using RH9

[Void Main]

Upgrade RH to Fedora and install shorewall. :)

[Basher52]

so...it all depends on Fedora...k...
but shorewall?? whats that???

[Void Main]

Maybe I missed something. Is this related to your previous thread on the subject?:

viewtopic.php?t=770

I know there were were talking about ip_conntrack_ftp and ip_nat_ftp kernel modules and the port= problem with the older kernel/iptables. Forgive me if this is a different issue.

EDIT: I just read the piece in the link you included in your message. Even fedora does not include that module. I believe the only thing the referenced mport module gives you over multiport is the ability to do a range. If you use "multiport" as you are in your example you need to list the ports individually. In either case I believe you are limited to 15 total ports. That means that even if you could do a range with multiport then you would not be able to do 35000:35200 because that would be 186 ports more than the limit of 15 according to my calculations. At least that is the way I read it.

[Basher52]

well.. i did this this by doing all the IP's repeateadly(sp) by dubbling all the IP-rows in 2(two)rows thereby doubling the IP's...if you get the picture(?)

i saw this "patch" at this place and just wondered... should i apply it?
to Fedora or Redhat)...it doesnt matter, cuz i think my installationg is going bad anyways...???

B52

[Void Main]

Installation is going bad? I've never seen one do that, what's it look like? :) I take that back, I have seen Windows installations go bad, never anything else though. I'm sorry, I guess that doesn't help at all does it? :)

[Basher52]

i keep getting 'Segmenation fault' in someplaces nowadays and in places that i do know has worked, and if i have got this right... its the same as M$ GPF...or?

and as i have no idea how to fix it, i just reinstall it all

[Void Main]

Heh heh. Well next time you get one maybe you could post some info about it here and we might be able to help you out. Of course a segmentation fault should never happen and usually means a problem with how the program was written. A segmentation fault happens when the program tries to use memory that has not been allocated to it. It usually/always is the result of lack of error and range checking by the program. Even if the program is misconfigured it should not produce a segmentation fault because if it had been coded properly it would have detected that the config problem and exited gracefully with a message indicating what the problem is. More often than not it is just a mistake in the program by the programmer.

[Basher52]

well...i havent reinstall or anything yet so i can give you some data about it... but the problem is that the error is ONLY 'Segmentaion fault' no other data can be found near the problem.

eg. when i try to use glupdate, a bin that should update the directories that glftpd uses, i get 'Segmentation fault'
If u need some other data for this problem, lemme know

[Void Main]

To properly figure out the problem I would need the source code and the core file and run it through the debugger. But you might be able to get an indication of what caused the problem by viewing the text within the core file by:

"strings core | more"

Of course it probably didn't generate a core file because core file generation is turned off by default in Red Hat. You can turn it on, then make the program crash again which should produce a core file in the current directory. To turn on core file generation do:

$ ulimit -c 100000

Which would mean the core file that is generated can be up to 100MB but no larger. The default is 0. Make sure you run the command that crashes in the same shell that you execute the above command in.

You could also do a system call trace by prepending "strace" in front of your command. That is very useful for finding out exactly what the program was trying to do when it crashed:

$ strace command

I usually redirect the output to a file and then view it using VIM as it highlights all the messages properly in different colors:

$ strace command > command.txt 2>command.trace
$ vim command.trace

or

$ strace command > command.trace 2>&1
$ vim command.trace

[Basher52]

k...i did all you said, but since i aint no C programmer this wont tell me nothing
can i give you the outputs somehow?

[Void Main]

If you ain't no programmer probably the best thing to do would be to contact the programmer who wrote the program and tell him it's broken. He might be interested in the core file. How big is the core file and how big is the trace file? If you could make them available somewhere I could take a look at them. If they aren't too big you could upload them for me to take a look at:

ftp://voidmain.is-a-geek.net/uploads/

Make sure you upload them in binary. Note, after you upload it you will not be able to see it on my server.

And BTW, if you were running Shorewall as your firewall to allow active/passive FTP for your glftpd your rules might look like this:

Code: Select all

#ACTION      SOURCE            DEST                 PROTO   DEST        SOURCE     ORIGINAL
DNAT         net               dmz:192.168.10.2     tcp     ftp
DNAT         net               dmz:192.168.10.2     udp     ftp
DNAT         net               dmz:192.168.10.2     tcp     ftp-data
DNAT         net               dmz:192.168.10.2     udp     ftp-data
DNAT         net               dmz:192.168.10.2     tcp     35000:35200 -          $NET_IP
ACCEPT:info  dmz:192.168.10.2  net                  tcp     20


The above assumes you have your FTP server in your DMZ and it's off-net IP address is 192.168.10.2. If you don't have a DMZ and it's just on your internal network you would just change the "dmz" to "loc" above. But underneath, shorewall just uses iptables. It just makes life easier and more logical for my little pea brain.

[Basher52]

thx.
Ive ULd 3 files, the source, strings and trace
but they disappeared from the upload directory so i have no idea if its OK

B52

[Void Main]

Yep, as I suspected. I was able to get it to segfault by not giving it the parameters it was expecting and it tried to access a parameter beyond what I had passed it (trying to access unallocated memory). The specific line where I got it to segfault is line 92:

Code: Select all

        strncpy(nambuf, argv[arg], sizeof(nambuf));


Now, not being familiar with this code or the program it is written for it would be best to contact the author of the program and have him fix it. But I suspect that the program works as long as it is used as it is expected to be used and that the /etc/glftpd.conf file is good and proper params are passed etc. However, it should not segfault as I said before, it should properly check for errors and gracefully exit when it encounters one along with a little inforation on what the problem is.

Now, if you want me to actually debug it further and try and figure out exactly what the problem is I'll need a copy of your glftpd.conf file, the location that the glftpd.conf file is installed on your system, the permissions of the file, the exact command line you used when running glupdate that caused the segfault and any other information you might think is helpful. But again, it would be much easier for me if you contacted the original author and tell him it's broke. :)

EDIT: Actually looking at your trace file I see you ran the program like this:

Code: Select all

./glupdate -r /etc/glftpd.conf


And that is not correct. You did the same thing I did to make it crash. You need another parameter on the end of that command line, the actual directory name that you want to update. I suspect something like:

./glupdate -r /etc/glftpd.conf /var/ftp/somedir

However, that doesn't work for me either, it just exits and when I look at the source I see why. "argc" will be 4 with the above command line which is exactly the syntax it expects according to the help if you just type "./glupdate" by itself to get the help:

Code: Select all

$ ./glupdate
 
glFtpD DIRLOG update utility v2.2
 
Usage: ./glupdate [-r /pathto/glftpd.conf] <full directory path>


Problem is:

Code: Select all

        if (argc < 2 || argc > 3) {
                printf("\n\
glFtpD DIRLOG update utility v2.2\n\n\
Usage: %s [-r /pathto/glftpd.conf] <full directory path>\n\n",argv[0]);
        exit(0);
        }


tells the program to exit if argc is greater than 3. Last time I checked 4 is greater than 3. This program is um... not good.

Maybe try just this:
./glupdate /var/ftp/somedir

Or whatever the directory is that you want to update (I don't really know what this program is supposed to do)....

But I hate to tell you to run it at all for fear it might screw up your system after seeing the little code I saw.

At any rate, reinstalling your operating system would have no effect on this one. :)

[Basher52]

well... i thought so too when i looked at my parameters i sent the program
i didnt realize that the second parameter was needed even f it says so, right in my face...lol

anyhow, i thought it would read the glftpd.conf and get those directories from that file, instead of me having to give all the dirs and subdirs as they will be very "dynamic" and since the doc of the program says that it aint recursive

thx anyways man, and contacting the author wont help, i think, since what i wnat the program to do is way beyond its capabilities

again...thx Void