I have set my default rule to log info. I am seeing lots of probes on TCP port 22 and UDP port 1434. Does it make sense to put in specific rules to just drop these on the floor? I have mapped my SSH to a different port number. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:> I have set my default rule to log info. I am seeing lots of probes on > TCP port 22 and UDP port 1434. Does it make sense to put in specific > rules to just drop these on the floor? I have mapped my SSH to a > different port number.Configuring port-specific DROP rules is an option. I personally use another option for reducing log pollution: /etc/shorewall/shorewall.conf: BLACKLIST_LOGLEVEL='''' /etc/shorewall/blacklist: - udp 1024:1033,1434 - tcp 57,1433,1434,2401,2745,3127,3306,3410,48 /etc/shorewall/interfaces: net ${EXT_IF} detect logmartians=1,blacklist Rather than configuring a non-standard port for SSH, I prefer to use the Limit action (see http://www1.shorewall.net/PortKnocking.html#Limit) to control SSH noise; consequently, I don''t blacklist TCP port 22. I also enforce the use of shared keys for SSH authentication. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Robert Moskowitz wrote: >> I have set my default rule to log info. I am seeing lots of probes >> on TCP port 22 and UDP port 1434. Does it make sense to put in >> specific rules to just drop these on the floor? I have mapped my SSH >> to a different port number. > > Configuring port-specific DROP rules is an option. I personally use > another option for reducing log pollution: > > /etc/shorewall/shorewall.conf: > > BLACKLIST_LOGLEVEL='''' > > /etc/shorewall/blacklist: > > - udp 1024:1033,1434 > - tcp 57,1433,1434,2401,2745,3127,3306,3410,48Makes sense. there are a number of ports here that I do not recognize and are not in /etc/services like 57. Is there somewhere to get a mapping?> > /etc/shorewall/interfaces: > > net ${EXT_IF} detect logmartians=1,blacklistIs ${EXT_IF} a system variable in place of the actual external interface names?> > > Rather than configuring a non-standard port for SSH, I prefer to use > the Limit action (see > http://www1.shorewall.net/PortKnocking.html#Limit) to control SSH > noise; consequently, I don''t blacklist TCP port 22. I also enforce the > use of shared keys for SSH authentication.Each to their own. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
oh,,, Tom Eastep wrote:> /etc/shorewall/shorewall.conf: > > BLACKLIST_LOGLEVEL=''''What is the difference between what you have above and what was default in my .conf: BLACKLIST_LOGLEVEL ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Tue, Jan 08, 2008 at 07:38:28AM -0800, Tom Eastep wrote:> Robert Moskowitz wrote: >> I have set my default rule to log info. I am seeing lots of probes on TCP >> port 22 and UDP port 1434. Does it make sense to put in specific rules to >> just drop these on the floor? I have mapped my SSH to a different port >> number. > > Configuring port-specific DROP rules is an option.You can also simply not bother logging rejected connections. It''s not really very interesting to know about all the attacks made on services that you aren''t even running. It''s pretty much all Windows worms anyway (except for the port 22 stuff, which is a botnet running dictionary attacks against ssh servers on every internet-connected host - it''s been around for about five years now, consider it a lesson in why you should not create a user ''guest'' with a password ''guest''). It would be rather more useful to log accepted connections instead of rejected ones. But if you''re inclined to do that, you should run snort instead. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Robert Moskowitz wrote: >> I have set my default rule to log info. I am seeing lots of probes >> on TCP port 22 and UDP port 1434. Does it make sense to put in >> specific rules to just drop these on the floor? I have mapped my SSH >> to a different port number. > > Configuring port-specific DROP rules is an option. I personally use > another option for reducing log pollution: > > /etc/shorewall/blacklist: > > - udp 1024:1033,1434 > - tcp 57,1433,1434,2401,2745,3127,3306,3410,48############################################################################### #ADDRESS/SUBNET PROTOCOL PORT - udp 1024:1033,1434 - tcp 22,57,1433,1434,2401,2745,3127,3306,3410,48 Compiling /etc/shorewall/blacklist... WARNING: The entries in /etc/shorewall/blacklist have been ignored because there are no ''blacklist'' interfaces : /etc/shorewall/blacklist (line 11) now what. And that format that you supplied is not liked by Webmin. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:> oh,,, > > Tom Eastep wrote: >> /etc/shorewall/shorewall.conf: >> >> BLACKLIST_LOGLEVEL='''' > What is the difference between what you have above and what was default > in my .conf: > > BLACKLIST_LOGLEVELNone. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:>> >> BLACKLIST_LOGLEVEL='''' >> >> /etc/shorewall/blacklist: >> >> - udp 1024:1033,1434 >> - tcp 57,1433,1434,2401,2745,3127,3306,3410,48 > Makes sense. there are a number of ports here that I do not recognize > and are not in /etc/services like 57. Is there somewhere to get a mapping? >> /etc/shorewall/interfaces: >> >> net ${EXT_IF} detect logmartians=1,blacklist > Is ${EXT_IF} a system variable in place of the actual external interface > names?See http://www.shorewall.net/configuration_file_basics.htm#Variables. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:> Tom Eastep wrote: >> Robert Moskowitz wrote: >>> I have set my default rule to log info. I am seeing lots of probes >>> on TCP port 22 and UDP port 1434. Does it make sense to put in >>> specific rules to just drop these on the floor? I have mapped my SSH >>> to a different port number. >> Configuring port-specific DROP rules is an option. I personally use >> another option for reducing log pollution: >> >> /etc/shorewall/blacklist: >> >> - udp 1024:1033,1434 >> - tcp 57,1433,1434,2401,2745,3127,3306,3410,48 > ############################################################################### > #ADDRESS/SUBNET PROTOCOL PORT > - udp 1024:1033,1434 > - tcp > 22,57,1433,1434,2401,2745,3127,3306,3410,48 > > > Compiling /etc/shorewall/blacklist... > WARNING: The entries in /etc/shorewall/blacklist have been ignored > because there are no ''blacklist'' interfaces : /etc/shorewall/blacklist > (line 11) > > > now what.I guess you have better add the ''blacklist'' option to your external interface as I showed in my initial post.> > And that format that you supplied is not liked by Webmin.Format of WHAT? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Robert Moskowitz wrote: > >>> >>> BLACKLIST_LOGLEVEL='''' >>> >>> /etc/shorewall/blacklist: >>> >>> - udp 1024:1033,1434 >>> - tcp 57,1433,1434,2401,2745,3127,3306,3410,48 >> Makes sense. there are a number of ports here that I do not recognize >> and are not in /etc/services like 57. Is there somewhere to get a >> mapping? >>> /etc/shorewall/interfaces: >>> >>> net ${EXT_IF} detect logmartians=1,blacklist >> Is ${EXT_IF} a system variable in place of the actual external >> interface names? > > See http://www.shorewall.net/configuration_file_basics.htm#Variables.Well, this is rather wrong per that URL. The format that I was finding was $EXT_IF I then went to http://www.shorewall.net/manpages/shorewall-interfaces.html as I should have, and just added the logmartians to the definition of my public interface and it compiled. Thanks. Learned some more. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:> Tom Eastep wrote: >> Robert Moskowitz wrote: >> >>>> BLACKLIST_LOGLEVEL='''' >>>> >>>> /etc/shorewall/blacklist: >>>> >>>> - udp 1024:1033,1434 >>>> - tcp 57,1433,1434,2401,2745,3127,3306,3410,48 >>> Makes sense. there are a number of ports here that I do not recognize >>> and are not in /etc/services like 57. Is there somewhere to get a >>> mapping? >>>> /etc/shorewall/interfaces: >>>> >>>> net ${EXT_IF} detect logmartians=1,blacklist >>> Is ${EXT_IF} a system variable in place of the actual external >>> interface names? >> See http://www.shorewall.net/configuration_file_basics.htm#Variables. > Well, this is rather wrong per that URL. The format that I was finding > was $EXT_IF >Shorewall accepts both. Apparently Webmin doesn''t.> I then went to > http://www.shorewall.net/manpages/shorewall-interfaces.html as I should > have, and just added the logmartians to the definition of my public > interface and it compiled. > > Thanks. Learned some more.Except that logmartians had nothing to do with your problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Robert Moskowitz wrote: >> Tom Eastep wrote: >>> Robert Moskowitz wrote: >>>> >>>>> /etc/shorewall/interfaces: >>>>> >>>>> net ${EXT_IF} detect logmartians=1,blacklist >>>> Is ${EXT_IF} a system variable in place of the actual external >>>> interface names? >>> See http://www.shorewall.net/configuration_file_basics.htm#Variables. >> Well, this is rather wrong per that URL. The format that I was >> finding was $EXT_IF >> > > Shorewall accepts both. Apparently Webmin doesn''t.All editing right now is via VI, I abcked off Webmin for a bit and will take the format problem there probably today. I wasn''t getting it to compile, and my error might have been other problems in my interface file. Just did not find the ${EXT_IF} format in the URL docs (perhaps just did not dig enough).> >> I then went to >> http://www.shorewall.net/manpages/shorewall-interfaces.html as I >> should have, and just added the logmartians to the definition of my >> public interface and it compiled. >> >> Thanks. Learned some more. > > Except that logmartians had nothing to do with your problem.Knew that, but thought it might be a ''good thing'' to see what martians were coming my way. To get bothered by one that I know about was the pain. Know noise blocks catching interesting noise. But interesting that a redirect is a martian. Going to have to look that up. Martians is an area that I have not followed for years. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Robert Moskowitz wrote:>> Shorewall accepts both. Apparently Webmin doesn''t. > All editing right now is via VI, I abcked off Webmin for a bit and will > take the format problem there probably today. I wasn''t getting it to > compile, and my error might have been other problems in my interface > file. Just did not find the ${EXT_IF} format in the URL docs (perhaps > just did not dig enough).They are called ''Shell Variables'' because, until Shorewall-perl, they were exactly that. Shorewall-shell and all Shorewall versions prior to 4.0 were written entirely in Bourne shell. In those versions, variable expansion is done by the shell itself. Consequently all forms of expansion supported by the shell could be used. Shorewall-perl does it''s own variable expansion (except in the ''params'' file) and only supports $VAR and ${VAR}. The latter is explained at http://www.shorewall.net/Shorewall-perl.html#Incompatibilities. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Wed, Jan 09, 2008 at 07:36:41AM -0500, Robert Moskowitz wrote:> But interesting > that a redirect is a martian. Going to have to look that up. Martians > is an area that I have not followed for years.Martian tests are completely unrelated to the content of the packets. They consider only the IP header itself and only those elements which are relevant to routing decisions; with a normal system and packet this is only the source and destination address fields. The ICMP payload is not examined until after the packet has passed martian tests. Martian tests are not documented anywhere. The only place where the behaviour is defined is the kernel source itself. I posted about this last February; here''s a repost of some of the more relevant bits (archives suck too hard for me to find it): On Fri, Feb 09, 2007 at 06:02:09PM -0500, Brian J. Murrell wrote:> Lately I have been seeing "transient" (I say transient because the > problem will persist for a while and then magically clear itself up some > number of minutes later) situations where my gateway will log: > > Feb 9 17:23:45 gw.ilinx kernel: martian source 66.11.173.224 from 64.86.88.116, on dev eth1 > Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00The message is somewhat obtusely phrased. The kernel has received a packet from 64.86.88.116 to 66.11.173.224 on eth1, and it doesn''t like the source address for whatever reason, so it dropped the packet. ''Martian'' is conceptually a collection of vaguely related objections to the source address, at the time when the routing decision is made (hence AFTER packet transformations in PREROUTING, so you can generate it with sufficiently broken iptables rules). In case it''s of any use, here''s the parts I do understand (2.6.19.1 behaviour, since I had that unpacked here): The error message in question can be reached by two parts of the ipv4 routing code. The first is when fib_validate_source() returns an error, and the second is the following bits of code from ip_route_input_slow(): /* Check for the most weird martians, which can be not detected by fib_lookup. */ if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr)) goto martian_source; ... /* Accept zero addresses only to limited broadcast; * I even do not know to fix it or not. Waiting for complains :-) */ if (ZERONET(saddr)) goto martian_source; (I do not understand this comment, but the tests are all pretty obvious - 0/8, 127/8, anything multicast, and anything in the undefined space above multicast) fib_validate_source() is sadly far harder to understand without going through and figuring out how all the fib_* stuff works, which is quite a lot of intricate, poorly commented code written by insane people. Here''s the sole comment, which hopefully resembles what this function actually does: /* Given (packet source, input interface) and optional (dst, oif, tos): - (main) check, that source is valid i.e. not broadcast or our local address. - figure out what "logical" interface this packet arrived and calculate "specific destination" address. - check, that packet arrived from expected physical interface. */ This code corresponds to the rpfilter option on the interface, but it does some other tests against the routing table even when rpfilter is disabled - I don''t know what to make of that. As far as it makes sense to me (and this may be wrong), the algorithm goes: Swap the source and destination from the packet we''re considering, and look up the result in the routing table. If that doesn''t work, reject if rpfilter is enabled, otherwise accept. If the route we find is not a gateway or direct route, reject (ie, if it''s multicast/blackhole/whatever). If the route we find says to send the packet out the device on which this packet was received OR (something I don''t understand involving multipath routes), then: reject if the scope of this route is ''host'' or ''nowhere'', else accept. If rpfilter is enabled on the interface where the packet arrived, reject. Modify the query (in some way I don''t understand), and try looking it up in the routing table again. If that doesn''t work, accept. If we did find a route this time, and it''s not a gateway or direct route, or its scope is ''host'' or ''nowhere'', reject. Otherwise accept. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace