[SOLVED] Shorewall rejecting allowed traffic for transmission-daemon
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Shorewall rejecting allowed traffic for transmission-daemon
I have the Shorewall firewall running on Ubuntu 10.10 server and the issue I am having is the firewall is blocking traffic from my transmission-daemon even though I have allowed it in the /etc/shorewall/rules.
the rules file has the following lines
Code:
ACCEPT $FW net tcp 60000:60035
ACCEPT net $FW tcp 60000:60035
ACCEPT $FW net udp 51413
ACCEPT net $FW udp 51413
That match the rules in /etc/transmission-daemon/settings.json
as you can see, Shorewall is rejecting packets with source and destination port 51413 on incoming net2fw and outgoing fw2net even though the rules are set to accept. any ideas or suggestions?
good observation. i noticed this as well shortly after posting this and added rules for tcp and it is still doing the same thing. You'll notice that the fw2net traffic is actually udp (lines 2,3,4 in my example) while the net2fw traffic is tcp (first and last). here is the tail of my syslog after adding rules for tcp on port 51413
You're not getting anymore filtered inbound TCP/51413 packets, so you're making progress.
The remaining filtered packets don't match any of your rules, so things are working as expected. Practically speaking, the program is sending packets with destination ports outside the ranges you've written fw2net rules for. Why not try something like this instead:
Code:
ACCEPT $FW net
ACCEPT net $FW udp 51413
ACCEPT net $FW tcp 51413
This way the program can send packets with any destination port it requires, while you're only exposing ports 51413/TCP and 51413/UDP to the Internet. If this works fine (check the log), then you can proceed to tighten the outbound restrictions (if desired). Personally, I don't really see much benefit to limiting outbound packets to destination ports in a specific range, unless you're absolutely sure that nothing outside that range will be required. That said, perhaps restricting outbound packets with destination ports within the privileged range (up to 1024) may give you some peace of mind, in the sense that it limits attack propagation if the program is exploited, while not affecting functionality (assuming that you're not going to be using any other programs beside this one, which would be kinda weird for a desktop computer).
You make very good points. I followed your suggestion about the outbound destination ports and it cleaned up my log file quite nicely. With these adjustments I'm keeping the traffic I want. I do worry that if my system was to become compromised the firewall would not block undesirable or malicious outgoing data, like becoming a bot in a botnet for DDOS attacks for example. Just to paint a better picture this isn't a desktop. It's a firewall/general server for my home and i use the transmission-daemon to start torrent downloads when I'm away from home. Should I change my logging sensitivity and write a script to look for "suspicious traffic" in said log? Is there a better way to do it?
Well, if you restrict the privileged ports (all those below 1025), then at least you'll know the box won't be successfully used as part of a DDoS against typical services (HTTP, SMTP, DNS, FTP, etc.). That is, unless the box is rooted, of course (in which case the host-based firewall doesn't do much good, if any). You could have a log file monitor program be on the lookout for any filtered traffic to such ports, and let it alert you if it spots anything. Actually, since you're looking for something so specific, perhaps just a simple shell script running as a cron job would suffice.
I think your right about the privileged ports, I can't picture someone using a compromised system to send on anything other than typical services like spamming off SMTP/25 or just flooding a remote host with tons of http get requests or something. I've started on the script that i'll run in either hourly or daily cron that will send me an email for 'suspicious' activity. I'm just a little hung up because i'm not great with regex and i need to be very specific, but I did find an awesome tutorial here: http://www.regular-expressions.info/tutorial.html
scripts running as cron jobs is probably one of the most useful tools in existence, i couldn't imagine living without it.
I'd just have any filtered packets with that destination port range use their own LOG prefix. Checking for it in the log wouldn't require any regular expressions at all. For example, with iptables it could be done like:
Code:
iptables -A OUTPUT -p TCP -o eth0 --dport ! 1024:65535 -m state --state NEW -j LOG --log-prefix "PRIV_PORT_REJECT: "
iptables -A OUTPUT -p TCP -o eth0 --dport ! 1024:65535 -m state --state NEW -j REJECT
iptables -A OUTPUT -p UDP -o eth0 --dport ! 1024:65535 -m state --state NEW -j LOG --log-prefix "PRIV_PORT_REJECT: "
iptables -A OUTPUT -p UDP -o eth0 --dport ! 1024:65535 -m state --state NEW -j REJECT
...in which case you'd just need to check the log for the string PRIV_PORT_REJECT, and raise an alert if it's found. I'm sure the same thing can be done with Shorewall, given that it's an iptables front end. BTW: The use of the NEW state match is important, otherwise you might end up filtering outbound packets which are part of your clients' connections to your general services.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
