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.
Yikes, very good stuff to know about network security. After I have tightened the input and output rules for each of my internal servers, should I start looking into the modsecurity and snort programs you mentioned earlier to be set up on the internal machines as opposed to the firewall itself?
Yikes, very good stuff to know about network security. After I have tightened the input and output rules for each of my internal servers, should I start looking into the modsecurity and snort programs you mentioned earlier to be set up on the internal machines as opposed to the firewall itself?
Actually, I highly recommend that you install Snort on a dedicated box — but yeah, it sounds to me like you're headed in the right direction. Please don't hesitate to post an update on what your firewall rules look like on both your dedicated firewall as well as your servers when you've progressed, so that we may provide you with some feedback and stuff. It's always good to have another set of eyes with these sort of things.
So things are starting to come together for me as I read through the iptables documentation you recommended, and as they do I had a few semantic questions for you.
1) In reading, it suggests adding Snort to each of the machines on your network, would this include the firewall?
2) It also recommends using a web proxy such as Squid when planning for the implementation of your webserver. I know you recommended Modsecurity, are their pros/cons to either approach? And what does this entail as far as hardware, etc?
3) One other recommendation is to use a program like Tripwire as a last line of defense to spot if any configuration files have changed over time. Do you recommend this as well, and would this also be installed on all machines including the firewall?
1) In reading, it suggests adding Snort to each of the machines on your network, would this include the firewall?
Yeah, if you interpreted what he wrote as a suggestion (I didn't), there's no reason why it would only be limited to the servers. Once again, though, I recommend you don't do this. Any time you add new network functionality on a box, you're increasing the risk of it being compromised. Plus, if you've got Snort properly installed on a dedicated box on the LAN (by means of port mirroring, for example), it'll have access to each server's traffic anyway.
Quote:
2) It also recommends using a web proxy such as Squid when planning for the implementation of your webserver. I know you recommended Modsecurity, are their pros/cons to either approach? And what does this entail as far as hardware, etc?
They are completely different tools, so comparing them wouldn't make much sense. Squid will help reduce the load on your servers (and speed up the service to clients), while ModSecurity will provide your HTTP server with application-layer inspection.
Quote:
3) One other recommendation is to use a program like Tripwire as a last line of defense to spot if any configuration files have changed over time. Do you recommend this as well, and would this also be installed on all machines including the firewall?
Yes, the importance of being able to know when things change unexpectedly cannot be overstated. I like (and currently use) Tripwire, but keep in mind that there are better maintained alternatives such as AIDE (which is a Tripwire fork) available. You might also be interested in something more advanced, such as Samhain, which complements the traditional passive approach with an active one, and allows for centralized administration. Of course, there's also tons of other HIDS out there for you to choose from, so by no means should you feel limited to these examples. There's also several tools which are a good idea to run periodically, such as Rootkit Hunter and Tiger, for example.
Thanks, do you have any references you would point too for snort and snort-inline setup, I was particularly interested in both IDS and IPS functionality. As for modsecurity, should I just look at their documentation pages - -http://www.modsecurity.org/documentation/faq.html#d0e224 - or do you recommend other resources as well?
Also, I had not really asked about it yet, but do you have any recommendations for application level firewalls for a mail server (would a nameserver need one as well)?
Thanks, do you have any references you would point too for snort and snort-inline setup, I was particularly interested in both IDS and IPS functionality. As for modsecurity, should I just look at their documentation pages - -http://www.modsecurity.org/documentation/faq.html#d0e224 - or do you recommend other resources as well?
Also, I had not really asked about it yet, but do you have any recommendations for application level firewalls for a mail server (would a nameserver need one as well)?
I had a book lying around called Snort for Dummies which IIRC was a pretty neat introduction to Snort. If you do a search for Snort on amazon.com it apparently still shows up, along with a lot of other Snort books. Regarding ModSecurity, I'm hoping others will chime in here soon and share their thoughts, as all I can really say is that there's a couple books with good ratings available on amazon.com. As for application-layer filtering for your other services, you might be able to get a generic proxy firewall such as Zorp GPL to do what you want (I don't know of a more specific solution).
After the backslash in each instance there is an option -m in the first case and -j in the second. Because of how it displayed I can't quite see how it is formatted. Is there a space between the \ and -m or -j, or is there no space and they should be written \-m \-j? Thanks, sorry for the basic question, just going over my work.
Ok, I believe I answered the question above. I tried both ways and \-m and \-j did not produce errors.
However, on a more serious note I believe I have set up my internal nameserver's firewall ruleset correctly, but it still can't get out to the ubuntu update servers.
Here is the error I am getting when I try to get out:
The backslashes are only there to escape the newline character. If you're writing the command down on a single line, then you don't need the backslash. As for spaces, you need just one space between each of the options, although in most cases having more than one won't cause any errors.
Regarding the failure to resolve addresses, you'd typically start troubleshooting this sort of thing by temporarily enabling logging in the relevant chains and then studying what the filtered packets look like. Usually, doing so will allow you to see what's wrong pretty quickly. For example, to see if the problem is in the dedicated firewall's FORWARD chain, you could do a:
Code:
iptables -A FORWARD -j LOG --log-prefix "FORWARD DROP: "
...and then watch the log file when you try to update the server again.
When you're done doing your test, you can delete that log rule with a -D option:
That said, this 192.168.21.27 IP looks new to me, did you change it? In a previous post the IP seemed to be 192.168.21.47, which would perfectly explain why it's not working now. This should also be quite evident in the log file.
Ok, I did not see any FORWARD DROP messages within the firewall log messages. Should I then precede to do the same thing on the internal machine to double check if the problem lies there?
I double checked my network configuration and the firewall script ip addresses and the ip assigned to the internal machine are the same.
I will post back shortly to report what I see in the internal machines records.
Just ran a similar command in the output rules of the internal machines iptables:
Code:
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "
Unfortunately there was no log event here either when the error message appeared. I checked iptables and it looks like no packets were dropped on output either.
Code:
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
170 22859 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 120 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 443,80 state NEW
92 6698 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 state NEW
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `OUTPUT DROP: '
I noticed my time is off on this internal machine, so I tried to run ntpdate to synchronize it manually and received this error as well:
Code:
Name server cannot be used, exiting20 Mar 09:42:43 ntpdate[1172]: name server cannot be used, reason: Temporary failure in name resolution
Do you have any ideas on where to look next? Thanks again.
Ahh good idea, always jumping ahead. I just checked and it looks like I had configured it to the ip address of the lan side of the firewall 192.168.21.1
Probably basic question but this likely won't be able to pass along the firewall's nameservers, correct?
And hah that was it, yup I definitely jump ahead a little too much. I am able to get out now.
Ahh good idea, always jumping ahead. I just checked and it looks like I had configured it to the ip address of the lan side of the firewall 192.168.21.1
That's what I suspected.
That would work if you had something like Dnsmasq running on the firewall's LAN side.
Quote:
Probably basic question but this likely won't be able to pass along the firewall's nameservers, correct?
Not sure I understand the question, could you rephrase it please? FWIW, you'd basically just need to set the same nameserver IPs which you've got set on your firewall. In other words, the ones which typically belong to your ISP.
EDIT: Oh, okay, I see you've got things under control now. Cool!
BTW, specifiying the IP of your ISP's DNS servers in your iptables rules could be part of your rule-tightening first steps. In other words, instead of having something like:
Code:
$IPT -A FORWARD -p UDP -i $LAN_IFACE -o $WAN_IFACE --dport 53 \
-m state --state NEW -j ACCEPT
...you could have something like:
Code:
$IPT -A FORWARD -p UDP -i $LAN_IFACE -o $WAN_IFACE --dport 53 \
-d $ISP_DNS_SERVER_1 -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p UDP -i $LAN_IFACE -o $WAN_IFACE --dport 53 \
-d $ISP_DNS_SERVER_2 -m state --state NEW -j ACCEPT
$IPT -A FORWARD -p UDP -i $LAN_IFACE -o $WAN_IFACE --dport 53 \
-d $ISP_DNS_SERVER_3 -m state --state NEW -j ACCEPT
Or install Dnsmasq and eliminate the need to have any FORWARD rules for outbound DNS lookups.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
