Now, is there a way of fixing this in the meantime until the next release? Other than the cron method? I'm not too familiar with this, but my limited understanding tells me that the filesystem is read only, so I can't simply modify a startup script, or something like that. Unless, perhaps, I created a startup script on jffs?
If not, it's not a big deal. I just like to be sure I have minimized any attack vectors.
Or, you can always remove rule from iptables INPUT chain by rule number from terminal session.
Assuming that both those lines appear always on top of list (check with iptables -L -n), enter:
iptables -D INPUT 1
Do it twice to remove one line a time.
I would not put these commands in script because there is no garantee that they would appear on first place in INPUT chain always (or they would?).
So you'll have to do it manually after each reboot.
[quote="olmari"]We can't know who did what back then and with whose credentials... All the same it is [i]taken off[/i] already, so what's the fuzz anymore?[/quote]
The fuzz is because this is in the v24-sp1 (07/27/0 vpn build on the website, I just flashed with it and i saw the rules.
Unless they were left over in the nvram from a previous build I had installed.
I'll save the current settings and i'll re-set the router to see if they show up again. I had the v24 vpn build before, could have been i didnt notice them, but i doubt it.
We can't know who did what back then and with whose credentials... All the same it is taken off already, so what's the fuzz anymore?
Fuzz? So... Hardcoded IPs first seen in the TRAC at 18/04/2007. "for a customer..." Question: Who need a non-removable, hardcodded rule? If It's real, how and why can be found this (customer-specific) modification in the main codebase? No comment lines around the rules...