LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Shorewall rejecting allowed traffic for transmission-daemon (http://www.linuxquestions.org/questions/linux-security-4/shorewall-rejecting-allowed-traffic-for-transmission-daemon-882159/)

RyanRahl 05-22-2011 10:35 PM

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

Code:

"peer-port": 51413,
"peer-port-random-high": 60035,
"peer-port-random-low": 60000,

yet my syslog gives me this:

Code:

May 22 18:15:46 sleppery kernel: [ 4374.583353] Shorewall:net2fw:DROP:IN=eth1 OUT= MAC=00:30:48:71:1d:1f:00:22:2d:c9:d4:fb:08:00 SRC=129.241.75.171 DST=74.94.*.* LEN=60 TOS=0x00 PREC=0x20 TTL=48 ID=57853 DF PROTO=TCP SPT=58320 DPT=51413 WINDOW=11680 RES=0x00 SYN URGP=0
May 22 18:15:47 sleppery kernel: [ 4375.596589] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=94.236.155.247 LEN=95 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=17176 LEN=75
May 22 18:15:47 sleppery kernel: [ 4375.596704] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=68.14.72.15 LEN=95 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=47712 LEN=75
May 22 18:15:47 sleppery kernel: [ 4375.596778] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=149.7.96.246 LEN=95 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=1063 LEN=75
May 22 18:15:47 sleppery kernel: [ 4375.646765] Shorewall:net2fw:DROP:IN=eth1 OUT= MAC=00:30:48:71:1d:1f:00:22:2d:c9:d4:fb:08:00 SRC=188.40.51.2 DST=74.94.*.* LEN=60 TOS=0x00 PREC=0x20 TTL=47 ID=19185 DF PROTO=TCP SPT=43218 DPT=51413 WINDOW=5840 RES=0x00 SYN URGP=0

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?

win32sux 05-23-2011 12:49 AM

DISCLAIMER: I'm not familiar with Shorewall.

Quote:

Originally Posted by RyanRahl (Post 4364094)
as you can see, Shorewall is rejecting packets with source and destination port 51413 on incoming net2fw

It makes sense, because the relevant rules are for UDP while the filtered packets are TCP.

Quote:

and outgoing fw2net even though the rules are set to accept. any ideas or suggestions?
Assuming the rules stand for destination ports (as opposed to source ports), the behavior seems normal as there is no match.

RyanRahl 05-23-2011 01:04 AM

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

Code:

May 22 21:55:17 sleppery kernel: [17546.003187] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=190.66.161.232 LEN=95 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=25492 LEN=75
May 22 21:55:17 sleppery kernel: [17546.003262] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=89.74.15.194 LEN=95 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=8974 LEN=75
May 22 21:55:20 sleppery dhcpd: DHCPREQUEST for 10.1.10.116 from 00:26:37:55:88:5c via eth0
May 22 21:55:20 sleppery dhcpd: DHCPACK on 10.1.10.116 to 00:26:37:55:88:5c via eth0
May 22 21:55:23 sleppery kernel: [17552.380603] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=173.63.94.48 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=65115 LEN=111
May 22 21:55:28 sleppery kernel: [17557.216594] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=92.235.231.92 LEN=134 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=40287 LEN=114
May 22 21:55:28 sleppery kernel: [17557.216727] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=61.178.152.187 LEN=134 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=26501 LEN=114
May 22 21:55:28 sleppery kernel: [17557.216798] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=92.7.165.135 LEN=134 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=27722 LEN=114
May 22 21:55:34 sleppery kernel: [17562.840606] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=77.127.140.181 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=22926 LEN=111
May 22 21:55:40 sleppery kernel: [17568.748106] Shorewall:fw2net:REJECT:IN= OUT=eth1 SRC=74.94.*.* DST=173.63.94.48 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51413 DPT=65115 LEN=111

these are all outgoing udp, im sure there are incoming tcp but this was just a quick 'cat syslog | tail' for examples sake

these are the new rules. is it ok/proper to have rules on the same port for tcp and udp?

Code:


ACCEPT          $FW            net    tcp    60000:60035    #Transmission Connect
ACCEPT          net            $FW    tcp    60000:60035
ACCEPT          $FW            net    udp    51413          # transmission peer port
ACCEPT          net            $FW    udp    51413
ACCEPT          $FW            net    tcp    51413                     
ACCEPT          net            $FW    tcp    51413


win32sux 05-23-2011 02:31 AM

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).

RyanRahl 05-23-2011 12:00 PM

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?

win32sux 05-23-2011 02:06 PM

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.

RyanRahl 05-23-2011 02:27 PM

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.

Thanks for all your help.

win32sux 05-23-2011 03:05 PM

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.


All times are GMT -5. The time now is 09:04 PM.