Disable FTP_alg script.

[podkaracz]

So i contacted asus about how to completly disable ftp alg and i got response from asus poland that they will contact headquarters and reply back. So my question is how to apply those scripts to work like firewall-start scripts work for merlin users?


I want to add those 2 because from what ive seen it disables ftp_alg

modprobe -r nf_nat_ftp
modprobe -r nf_conntrack_ftp

 

[QasusAnon]

Like you said @ColinTaylor was the one that first suggested using those two lines:

modprobe -r nf_nat_ftp
modprobe -r nf_conntrack_ftp

to /jffs/scripts/firewall-start in Merlin Firmware

Are you saying that you are NOT using Merlin firmware, and are using Stock ASUS firmware?

The question I would like to have answered is how do you test for the effect(iveness) if those two lines regardless of firmware version you use?

>> I.e. would you need a way to appear to be on the WAN side and try to probe your own IP address, for example?

>>> I guess what I'm saying is like so many vulnerabilities that are discovered by cybersecurity experts, usually they are accompanied by a proof of concept, and a suggested mitigation method.

 

[KevTech]

So i contacted asus about how to completly disable ftp alg and i got response from asus poland that they will contact headquarters and reply back. Its taking long and as i thought asus poland is not too smart so either they wont reply or it will take forever. So my question is how to apply those scripts to work like firewall-start scripts work for merlin users?


I want to add those 2 because from what ive seen it disables ftp_alg

modprobe -r nf_nat_ftp
modprobe -r nf_conntrack_ftp

Are you wanting to use scripts with official firmware?
If so you can not do that.
If you are talking about Merlin firmware then this thread is in the wrong forum.

 

[podkaracz]

So i contacted asus about how to completly disable ftp alg and i got response from asus poland that they will contact headquarters and reply back. So my question is how to apply those scripts to work like firewall-start scripts work for merlin users?


I want to add those 2 because from what ive seen it disables ftp_alg

modprobe -r nf_nat_ftp
modprobe -r nf_conntrack_ftp

Ok so after 14 days since i wrote about this around start of february i have response from asus with the right commands. Asus Poland is helpful but it takes them long to respond. Update on my previous post.
They advised: nvram set vts_ftpport=0

So is changing this port to 0 actually eliminates problem?

 

[juched]

You cannot set it to 0 via the UI. Lots going on right on around NAT slipstream issues, so while it is nice the rest can be turned off the best solution I could think of was to change the default port.

 

[podkaracz]

You cannot set it to 0 via the UI. Lots going on right on around NAT slipstream issues, so while it is nice the rest can be turned off the best solution I could think of was to change the default port.

I mean 3 posts in this threads other than mine suggest what i saw on all forums on the internet ever.
a) people dont read what op says and write something on topic mentioned in title
b) they read but they dont understand what they read

So to clarify:

Im using stock Asus firmware ( latest beta with dnspooq fixes).

I saw someone posting a command that is supposed to disable ftp_alg line in nat passthrough tab but at the same time that person pointed out it works only on merlin firmware so i created this thread to ask about possibility of same action on stock.

Then i got response from Asus stating that nvram set vts_ftpport=0 is the answer to my problem and once i did it ftp_alg port changed to 0 and its visible in gui and i reached back here to ask what do you think about this change and if it really disables that service since it seems like it just changed port and not disabled it.

 

[matthew johnson]

Did you make a script that you run?

 

[juched]

To be honest I read through this thread a few times before replying initially. I read it because I have been turning off all ALG items for a few months now due to security issues. What I was trying to add was that FTP is unfortunately the only one without a disable pull down. So your question and answer is appreciated. Setting something to use port 0 is common for Linux services to disable since port 0 is not a valid port to open. I am not sure how to test and probably only Asus can really confirm how to test. So, we either trust them or find other details to validate this. I have not found anything else online yet to validate.
Thanks to your post though I have gone in and run the command and nvram commit to set the port to 0 and will see what comes from that.

 

[Wallace_n_Gromit]

~
Thanks to your post though I have gone in and run the command and nvram commit to set the port to 0 and will see what comes from that.

I am running Merlin firmware and have set my ALG for my FTP to a random one between 1-65535 not including the default port 21. The GUI doesn't allow 0.

In a SSH session when I type:

nvram get vts_ftpport

I see "xxxxx" << the random FTP port I selected on the Merlin GUI.

nvram set vts_ftpport=0

nvram get vts_ftpport

I see "0" << the FTP port I selected.

The problem I see with that solution that after you reboot the router, won't it revert back to the random FTP port selected in the Merlin GUI between 1-65536?

To have the new FTP setting survive a reboot wouldn't you need to add the command to a script like /jffs/scripts/services-stop:

nvram set vts_ftpport=0
nvram commit

NOTE: Actually thinking more about this. The chronological order of events. This would not work since the Merlin ALG GUI would still want to set the FTP port to a random one set by the user?

The event to change the FTP ALG port to =0 would have to occur after the GUI sets the port.

2nd NOTE: Actually thinking more(r) about this and reading the OP I guess the 2 commands ["nvram commit" optional?] listed above would be added to the "/jffs/scripts/firewall-start" script at the SSH session?

The first 2 Screenshots below show the GUI after "nvram set vts_ftpport=0" then after a reboot. the FTP ALG port reverts back to my user set FTP ALG port "xxxx1" set up originally at the Merlin GUI.
The 3rd screenshot shows the results after typing at the command prompt in ssh then rebooting:

nvram set vts_ftpport=0
nvram commit

The change did stick this time, though not sure if "nvram commit's" are a good policy to utilize.

 

[bsdsource]

The change did stick this time, though not sure if "nvram commit's" are a good policy to utilize.

Wallace, you have a lot to learn about nvram and how the webui interface works. nvram stores most configuration settings and will populate the webui with those settings. Using the nvram commands from the console is no different that what the webui is using in the background when saving webui settings.

nvram commit is a very common command used from the console after an nvram setting has been changed. If one changes an nvram setting an nvram commit command is always neccessary for the setting change to remain persistent after a router reboot. For instance I'm unable to change the HTTPS webui port number 8443 from the webui. So I access the console via SSH or telnet and issue the following commands to change my HTTPS port:

nvram set https_lanport=64000
nvram commit

Now my HTTPS port in the webui shows 64000 shows instead of 8443. I was not aware of the NAT Slipstreaming attack & vulnerability issues. Thanks podkaracz.

 

[Wallace_n_Gromit]

Wallace, you have a lot to learn about nvram ~

nvram commit is a very common command used from the console after an nvram setting has been changed. ~

I am very glad you responded to my post @bsdsource. I took time to ponder and think about what I typed and why I would express that idea about [nvram commit]. I actually have a very limited understanding of such features AND I see that you are completely correct.

My understanding of such things is somewhat limited to warnings about methods to overclock my older/original RT-AC68U about 1 1/2 years ago when I first discovered this forum. Many methods were offered, but some had the caveat that if you mistakenly OVER-overclocked your router that you could end up with a BRICK that would be very difficult to reverse since the NVRAM would not be able to revert in case of a bad commit or even worse [nvram set asuscfecommit=1] << Don't do it unless you KNOW what you're doing .

[Release] Asuswrt-Merlin 384.13 is now available

No it simply means that the PC in question has SMBv1 enabled. They probably just opened Windows Explorer and browsed the network. OK, but Windows Explorer open for 6-8 hours? Does not compute. I understand Windows can be aggressive with network traffic (I have a story about Windows 2000...) but...

www.snbforums.com

Ironclad's method allowed me to experiment with increasingly higher overclocks, that when the router eventually failed to boot, it was a simple process to revert back to default clock speeds.

As a metaphor, [nvram commit] is nothing more than a tool in a carpenter's toolbox. Yes, a hammer can do harm if you miss the nailhead and hit your thumb; a novice will more likely hit their thumb and more often than a craftsman but it is not the fault of the hammer/[nvram commit]

I don't think I will be making such an amateurish statement about [nvram commit] again, (especially since I have SO SO MANY other commands to be amateurishly paranoid about!)